Post Syndicated from The Atlantic original https://www.youtube.com/shorts/VRTKDBeSOzc
Pablo Torre on the Gambling Boom That Could Break Sports
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=7XYpenjgxZw
Introducing Cluster insights: Unified monitoring dashboard for Amazon OpenSearch Service clusters
Post Syndicated from Siddhant Gupta original https://aws.amazon.com/blogs/big-data/introducing-cluster-insights-unified-monitoring-dashboard-for-amazon-opensearch-service-clusters/
Amazon OpenSearch Service clusters offer a wealth of operational metrics accessible through CloudWatch and the Amazon OpenSearch Service console to support effective performance monitoring and alert creation. Yet, pinpointing resiliency and performance challenges within your cluster can prove daunting. The process of identifying resource-intensive queries or understanding performance degradation trends can be time-consuming.
To address these challenges, we launched Cluster insights, which presents a unified dashboard delivering curated insights along with actionable mitigation steps. The dashboard displays detailed metrics at the node, index, and shard levels, coupled with a concise summary of security and resiliency best practices to uphold peak resiliency and availability.
This blog will guide you through setting up and using Cluster Insights, including key features and metrics. By the conclusion, you’ll understand how to use Cluster insights to recognize and address performance and resiliency issues within your OpenSearch Service clusters.
Getting Started with Cluster insights
Cluster insights is available at no additional cost to OpenSearch Service users running OpenSearch version 2.17 or later. Accessing Cluster insights requires admin-level permissions for your OpenSearch domain. Cluster insights is available only through the OpenSearch UI. OpenSearch UI offers support to multiple data sources, zero downtime upgrades for your dashboard experience, and curated workspaces for effective team collaborations. You first need to associate a data source (your clusters) with an OpenSearch UI application. Detailed steps are described in the user guide. Your OpenSearch UI console experience will look like following screenshots.
To access Cluster insights using the OpenSearch UI application:
- In the Amazon OpenSearch Service console, navigate to OpenSearch UI (Dashboards) and choose the Application URL to access your OpenSearch UI application.

- OpenSearch UI application, choose the settings icon at the left-bottom corner, then choose Data administration.

- On the Data administration overview page, or under Manage data in the left navigation, select Cluster insights.

Cluster insights overview
The Cluster insights – Overview acts as a landing page to show health and insights for all connected OpenSearch domains. It is organized into five sections:

- Current cluster status – Displays cluster health status (Green, Yellow, and Red) in a donut chart.
- Insights trend – Tracks issue patterns over the past 30 days, helping you identify emerging problems and track resolution progress. This trend analysis becomes particularly valuable when monitoring the impact of operational changes or troubleshooting recurring issues.
- Current open insights – Shows the count and severity breakdown of currently active insights across your clusters.
- OpenSearch service clusters – Lists all domains with their vital statistics such as health status, insights count, nodes, shards, and active queries.
- Top insights by severity – Prioritizes issues that need immediate attention. Each insight comes with a clear description and specific recommendations, transforming complex monitoring data into actionable tasks. This prioritized view helps teams can focus on critical issues first, whether they’re addressing shard size problems, disk space issues, or performance bottlenecks.
Together, these sections provide a comprehensive view of your OpenSearch Service infrastructure so you can assess cluster health, identify trends, and take action on critical issues from a single dashboard.
Cluster health
When you choose a specific cluster from the OpenSearch domains on the Cluster insights – Overview page, you will see cluster-specific details including health status, active insights, and performance metrics. The overview section displays cluster health along with essential metrics including count of shards, nodes, indices, and a total document size. You can also review the configuration best practices followed by domain across resiliency and security areas.
The lower section contains a table of actionable insights that presents a detailed view of current issues. This table mirrors the insights from the landing page but focuses specifically on issues affecting the selected cluster. You can observe high-severity issues such as low disk space and shard count problems, as well as medium-severity concerns that may impact cluster performance.
Each insight entry serves as an interactive element – selecting any issue reveals an in-depth analysis complete with root cause identification and specific remediation steps. The table includes important metadata such as generation timestamps, severity levels, recommendation counts, and current status, so users can prioritize and address issues effectively.

Insight details
Every insight offers detailed analysis and actionable recommendations. Take the Shard Count insight as an example: selecting it reveals a comprehensive breakdown of the issue. You’ll see that your OpenSearch cluster has breached the number of shards allowed on the nodes based on its JVM heap size, along with a detailed list of affected resources.

The detailed view includes a resource map that precisely identifies each impacted node and index, displaying critical information such as node IDs, shard counts, and the indices contributing to the issue.
The recommendations are organized into two levels: cluster-level recommendations address overall architecture improvements, such as scaling your cluster or adjusting global shard allocation settings. Index-level recommendations provide specific actions for individual indices—for example, you might see suggestions to move idle shards to UltraWarm storage. These are shards without any search or indexing operations for the last 10 days and are at least 5 days old, making them ideal candidates for warm storage to reduce the active shard count. All of this guidance is available directly within the Cluster insights interface, eliminating the need to switch between different tools or consoles.
Node, Index, Shard, and Query view
Next to cluster health, you can review Node, Index, Shard, and Query details for a specific cluster. These views present critical metrics such as resource (CPU, memory, disk) utilization, search and index latency.
Node view
The Node view tab provides a comprehensive view of individual node performance across your cluster. This table displays critical metrics for each node including heat score indicating overall node health, resource utilization (CPU, memory, disk), search and indexing latency and rates, along with quick links to view top N shards and queries running on each node.
This view helps you identify nodes experiencing high resource utilization or performance degradation. You can drill deeper into each node by clicking on the node ID to view detailed time-based metrics showing resource usage trends over time. Additionally, you can click the top N shards link to navigate directly to the Shard View, automatically filtered to show only the shards running on the selected node, allowing you to pinpoint which specific shards are contributing to performance issues.

Index view
The Index view tab shows performance metrics aggregated at the index level. For each index, you can monitor document count and storage size, search latency and rate, indexing latency and rate, and access top N queries affecting the index. This perspective is valuable for understanding which indices are driving cluster load and identifying optimization opportunities at the index configuration level.

Shard view
The Shard view tab offers the most granular view of cluster performance by displaying metrics for individual shards. Each row shows shard ID and its assigned node, index association and resource pressure metrics (CPU, memory), along with search and indexing latency per shard. This detailed view enables you to pinpoint specific shards causing performance issues, identify shard placement imbalances, and take targeted remediation actions.

Query view
The Query view on the Cluster insights page solves presents live dashboards that break down execution stats, CPU and memory usage, and completion progress for every query. This helps monitor which queries are driving the biggest resource consumption (the Top-N queries). With intuitive donut charts and scoreboards showing distribution by node, index, and user, this interface helps operators to quickly pinpoint performance bottlenecks and heavy workloads, supporting targeted optimization and confident scaling decisions.

Query insights
In addition to Cluster insights, you can also get Query insights to view the exact queries running and latencies across Expand, Query, and Fetch phases that provides valuable insights for search developers to further fine-tune their queries.

Conclusion
Cluster insights transforms OpenSearch Service cluster management from reactive troubleshooting to proactive optimization. By providing unified dashboards with heat score, and best practices across stability, resiliency, and security pillars, it offers visibility into your search infrastructure at the account level.
The actionable recommendations and step-by-step remediation guidance help users of all experience levels effectively resolve complex issues like shard imbalances and resource bottlenecks.
The integration with Query insights delivers real-time visibility into resource consumption patterns so that teams can identify and optimize performance-critical queries through detailed profiling and latency analysis.
For more information, see the AWS OpenSearch Service User Guide for additional details.
About the authors
Introducing VPC encryption controls: Enforce encryption in transit within and across VPCs in a Region
Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region/
Today, we’re announcing virtual private cloud (VPC) encryption controls, a new capability of Amazon Virtual Private Cloud (Amazon VPC) that helps you audit and enforce encryption in transit for all traffic within and across VPCs in a Region.
Organizations across financial services, healthcare, government, and retail face significant operational complexity in maintaining encryption compliance across their cloud infrastructure. Traditional approaches require piecing together multiple solutions and managing complex public key infrastructure (PKI), while manually tracking encryption across different network paths using spreadsheets—a process prone to human error that becomes increasingly challenging as infrastructure scales.
Although AWS Nitro based instances automatically encrypt traffic at the hardware layer without affecting performance, organizations need simple mechanisms to extend these capabilities across their entire VPC infrastructure. This is particularly important for demonstrating compliance with regulatory frameworks such as Health Insurance Portability and Accountability (HIPAA), Payment Card Industry Data Security Standard (PCI DSS), and Federal Risk and Authorization Management Program (FedRAMP), which require proof of end-to-end encryption across environments. Organizations need centralized visibility and control over their encryption status, without having to manage performance trade-offs or complex key management systems.
VPC encryption controls address these challenges by providing two operational modes: monitor and enforce. In monitor mode, you can audit the encryption status of your traffic flows and identify resources that allow plaintext traffic. The feature adds a new encryption-status field to VPC flow logs, giving you visibility into whether traffic is encrypted using Nitro hardware encryption, application-layer encryption (TLS), or both.
After you’ve identified resources that need modification, you can take steps to implement encryption. AWS services, such as Network Load Balancer, Application Load Balancer, and AWS Fargate tasks, will automatically and transparently migrate your underlying infrastructure to Nitro hardware without any action required from you and with no service interruption. For other resources, such as the previous generation of Amazon Elastic Compute Cloud (Amazon EC2) instances, you will need to switch to modern Nitro based instance types or configure TLS encryption at application level.
You can switch to enforce mode after all resources have been migrated to encryption-compliant infrastructure. This migration to encryption-compliant hardware and communication protocols is a prerequisite for enabling enforce mode. You can configure specific exclusions for resources such as internet gateways or NAT gateways, that don’t support encryption (because the traffic flows outside of your VPC or the AWS network).
Other resources must be encryption-compliant and can’t be excluded. After activation, enforce mode provides that all future resources are only created on compatible Nitro instances, and unencrypted traffic is dropped when incorrect protocols or ports are detected.
Let me show you how to get started
For this demo, I started three EC2 instances. I use one as a web server with Nginx installed on port 80, serving a clear text HTML page. The other two are continuously making HTTP GET requests to the server. This generates clear text traffic in my VPC. I use the m7g.medium instance type for the web server and one of the two clients. This instance type uses the underlying Nitro System hardware to automatically encrypt in-transit traffic between instances. I use a t4g.medium instance for the other web client. The network traffic of that instance is not encrypted at the hardware level.
To get started, I enable encryption controls in monitor mode. In the AWS Management Console, I select Your VPCs in the left navigation pane, then I switch to the VPC encryption controls tab. I choose Create encryption control and select the VPC I want to create the control for.
Each VPC can have only one VPC encryption control associated with it, creating a one-to-one relationship between the VPC ID and the VPC encryption control Id. When creating VPC encryption controls, you can add tags to help with resource organization and management. You can also activate VPC encryption control when you create a new VPC.
I enter a Name for this control. I select the VPC I want to control. For existing VPCs, I have to start in Monitor mode, and I can turn on Enforce mode when I’m sure there is no unencrypted traffic. For new VPCs, I can enforce encryption at the time of creation.
Optionally, I can define tags when creating encryption controls for an existing VPC. However, when enabling encryption controls during VPC creation, separate tags can’t be created for VPC encryption controls—because they automatically inherit the same tags as the VPC. When I’m ready, I choose Create encryption control.
Alternatively, I can use the AWS Command Line Interface (AWS CLI):
aws ec2 create-vpc-encryption-control --vpc-id vpc-123456789
Next, I audit the encryption status of my VPC using the console, command line, or flow logs:
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-123456789 \
--traffic-type ALL \
--log-destination-type s3 \
--log-destination arn:aws:s3:::vpc-flow-logs-012345678901/vpc-flow-logs/ \
--log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}'
{
"ClientToken": "F7xmLqTHgt9krTcFMBHrwHmAZHByyDXmA1J94PsxWiU=",
"FlowLogIds": [
"fl-0667848f2d19786ca"
],
"Unsuccessful": []
}
After a few minutes, I see this traffic in my logs:
flow-direction traffic-path srcaddr dstaddr srcport dstport encryption-status
ingress - 10.0.133.8 10.0.128.55 43236 80 1 # <-- HTTP between web client and server. Encrypted at hardware-level
egress 1 10.0.128.55 10.0.133.8 80 43236 1
ingress - 10.0.133.8 10.0.128.55 36902 80 1
egress 1 10.0.128.55 10.0.133.8 80 36902 1
ingress - 10.0.130.104 10.0.128.55 55016 80 0 # <-- HTTP between web client and server. Not encrypted at hardware-level
egress 1 10.0.128.55 10.0.130.104 80 55016 0
ingress - 10.0.130.104 10.0.128.55 60276 80 0
egress 1 10.0.128.55 10.0.130.104 80 60276 0
10.0.128.55is the web server with hardware-encrypted traffic, serving clear text traffic at application level.10.0.133.8is the web client with hardware-encrypted traffic.10.0.130.104is the web client with no encryption at the hardware level.
The encryption-status field tells me the status of the encryption for the traffic between the source and destination address:
- 0 means the traffic is in clear text
- 1 means the traffic is encrypted at the network layer (Level 3) by the Nitro system
- 2 means the traffic is encrypted at the application layer (Level7, TCP Port 443 and TLS/SSL)
- 3 means the traffic is encrypted both at the application layer (TLS) and the network layer (Nitro)
- “-” means VPC encryption controls are not enabled, or AWS Flow Logs don’t have the status information.
The traffic originating from the web client on the instance that isn’t Nitro based (10.0.130.104), is flagged as 0. The traffic initiated from the web client on the Nitro- ased instance (10.0.133.8) is flagged as 1.
I also use the console to identify resources that need modification. It reports two nonencrypted resources: the internet gateway and the elastic network interface (ENI) of the instance that isn’t based on Nitro.
I can also check for nonencrypted resources using the CLI:
aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-123456789
After updating my resources to support encryption, I can use the console or the CLI to switch to enforce mode.
In the console, I select the VPC encryption control. Then, I select Actions and Switch mode.
aws ec2 modify-vpc-encryption-control --vpc-id vpc-123456789 --mode enforce
How to modify the resources that are identified as nonencrypted?
All your VPC resources must support traffic encryption, either at the hardware layer or at the application layer. For most resources, you don’t need to take any action.
AWS services accessed through AWS PrivateLink and gateway endpoints automatically enforce encryption at the application layer. These services only accept TLS-encrypted traffic. AWS will automatically drop any traffic that isn’t encrypted at the application layer.
When you enable monitor mode, we automatically and gradually migrate your Network Load Balancers, Application Load Balancers, AWS Fargate clusters, and Amazon Elastic Kubernetes Service (Amazon EKS) clusters to hardware that inherently supports encryption. This migration happens transparently without any action required from you.
Some VPC resources require you to select the underlying instances that support modern Nitro hardware-layer encryption. These include EC2 Instances, Auto Scaling groups, Amazon Relational Database Service (Amazon RDS) databases (including Amazon DocumentDB), Amazon ElastiCache node-based clusters, Amazon Redshift provisioned clusters, EKS clusters, ECS with EC2 capacity, MSK Provisioned, Amazon OpenSearch Service, and Amazon EMR. To migrate your Redshift clusters, you must create a new cluster or namespace from a snapshot.
If you use newer-generation instances, you likely already have encryption-compliant infrastructure because all recent instance types support encryption. For older-generation instances that don’t support encryption-in transit, you’ll need to upgrade to supported instance types.
Something to know when using AWS Transit Gateway
When creating a Transit Gateway through AWS CloudFormation with VPC encryption enabled, you need two additional AWS Identity and Access Management (IAM) permissions: ec2:ModifyTransitGateway and ec2:ModifyTransitGatewayOptions. These permissions are required because CloudFormation uses a two-step process to create a Transit Gateway. It first creates the Transit Gateway with basic configuration, then calls ModifyTransitGateway to enable encryption support. Without these permissions, your CloudFormation stack will fail during creation when attempting to apply the encryption configuration, even if you’re only performing what appears to be a create operation.
Pricing and availability
You can start using VPC encryption controls today in these AWS Regions: US East (Ohio, N. Virginia), US West (N. California, Oregon), Africa (Cape Town), Asia Pacific (Hong Kong, Hyderabad, Jakarta, Melbourne, Mumbai, Osaka, Singapore, Sydney, Tokyo), Canada (Central), Canada West (Calgary), Europe (Frankfurt, Ireland, London, Milan, Paris, Stockholm, Zurich), Middle East (Bahrain, UAE), and South America (São Paulo).
VPC encryption controls is free of cost until March 1, 2026. The VPC pricing page will be updated with details as we get closer to that date.
To learn more, visit the VPC encryption controls documentation or try it out in your AWS account. I look forward to hearing how you use this feature to strengthen your security posture and help you meet compliance standards.
Ubiquiti Black Friday Deals: The Best Discounts You Need to See
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=5MGe3BKtp38
[$] Unpacking for Python comprehensions
Post Syndicated from jake original https://lwn.net/Articles/1046216/
Unpacking Python iterables of various sorts, such as dictionaries or lists,
is useful in a number of contexts, including for function arguments, but
there has long been a call for extending that capability to comprehensions. PEP 798 (“Unpacking in
Comprehensions”) was first proposed in June 2025 to fill that gap. In early
November, the steering council accepted
the PEP, which means that the feature will be coming to Python 3.15 in
October 2026. It may be something of a niche feature, but it is an
inconsistency
that has been apparent for a while—to the point that some Python programmers
assume that it is already present in the language.
PHP 8.5.0 released
Post Syndicated from corbet original https://lwn.net/Articles/1047429/
Version
8.5.0 of the PHP language has been released. Changes include a new
“|>” operator that, for some reason, makes these two lines
equivalent:
$result = strlen("Hello world");
$result = "Hello world" |> strlen(...);
Other changes include a new function attribute, “#[\NoDiscard]” to
indicate that the return value should be used, attributes on constants, and
more; see the
migration guide for details.
The Agentic AI Security Scoping Matrix: A framework for securing autonomous AI systems
Post Syndicated from Aaron Brown original https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/
As generative AI became mainstream, Amazon Web Services (AWS) launched the Generative AI Security Scoping Matrix to help organizations understand and address the unique security challenges of foundation model (FM)-based applications. This framework has been adopted not only by AWS customers across the globe, but also widely referenced by organizations such as OWASP, CoSAI, and other industry standards bodies, partners, systems integrators (SIs), analysts, auditors, and more. Now, as long-running, function-calling agentic AI systems emerge with capabilities for autonomous decision-making, we’re creating an additional framework to address an entirely new set of security challenges.
Agentic AI systems can autonomously execute multi-step tasks, make decisions, and interact with infrastructure and data. This is a paradigm shift, and organizations must adapt to it. Unlike traditional FMs that operate in stateless request-response patterns, agentic AI systems introduce autonomous capabilities, persistent memory, tool orchestration, identity and agency challenges, and external system integration, expanding the risks that organizations must address.
Working with customers deploying these systems, we’ve observed that traditional AI security frameworks don’t always extend into the agentic space. The autonomous nature of agentic systems requires fundamentally different security approaches. To address this gap, we’ve developed the Agentic AI Security Scoping Matrix, a mental model and framework that categorizes four distinct agentic architectures based on connectivity and autonomy levels, mapping critical security controls across each.
Understanding the agentic paradigm shift
FM-powered applications operate in a now well-understood, predictable pattern even though the responses that an FM produces are non-deterministic and stateless. These applications, in their most basic form receive a prompt or instruction, generate a response, then terminate the session. Security and safety controls focus on basic measures such as input validation, output filtering, and content moderation guardrails, while governance focuses on the overall risk profiles and the resilience of models. This model works because security failures have limited scope: a compromised interaction affects only that specific request and response, without persisting or propagating to other systems or users.
Agentic AI systems fundamentally change this security model through several key capabilities:
Autonomous execution and agency: Agents initiate actions based on goals and environmental triggers that might, or might not, require human prompts or approval. This creates risks of unauthorized actions, runaway processes, and decisions that exceed intended boundaries when agents misinterpret objectives or operate on compromised instructions.
When AI agents are given instructions or permissions to act based on the data, parameters, instructions, and responses given to them, the boundaries of independence or autonomy they are permitted to act within are important to define. In discussing agentic AI systems, it’s important to clarify the distinction between agency and autonomy, because these related but different concepts inform our security approach.
Agency refers to the scope of actions an AI system is permitted and enabled to take within the operating environment, and how much a human bounds an agent’s actions or capabilities. This includes what systems it can interact with, what operations it can perform, and what resources it can modify. Agency is fundamentally about capabilities and permissions—what the system is allowed to do within its operational environment. For example, an AI agent with no agency would be guided by human-defined workflow, process, tools, or orchestration compared to an AI agent with full agency that can self-determine how to accomplish a human-defined goal.
Autonomy, in contrast, refers to the degree of independent decision-making and action the system can take without human intervention. This includes when it operates, how it chooses between available actions, and whether it requires human approval for execution. Autonomy is about independence in decision-making and execution—how freely the system can act within its granted agency. For example, an AI agent might have high agency (able to perform many actions) but low autonomy (requiring human approval for each action), or vice versa.
Understanding this distinction is crucial for implementing appropriate security controls. Agency requires boundaries and permission systems, while autonomy requires oversight mechanisms and behavioral controls. Both dimensions must be carefully managed to create secure agentic AI systems.
It’s important to determine how much agency and autonomy you want to permit and grant your AI agents to act within. After you have determined the appropriate level that any given agent should operate within, you can then evaluate the appropriate security controls to put in place to restrict the agency to a permissible risk tolerance for your agentic-based application and your organization.
Persistent memory: Agents often benefit from maintaining context and learned behaviors across sessions, building knowledge bases that inform future decisions in the form of short- and long-term memory. This data persistence introduces additional data protection requirements and can add new risk vectors such as memory poisoning attacks where adversaries inject false information that corrupts decision-making across multiple interactions and users.
Tool orchestration: Agents directly integrate via functions with connections to databases, APIs, services, and potentially other agents or orchestration components to execute complex tasks autonomously depending on the tool abstraction level. This expanded attack surface creates risks of cascading compromises where a single agent breach can propagate through connected systems, multi-agent workflows, and downstream services and data stores.
External connectivity: Agents operate across network boundaries, accessing internet resources, third-party APIs, and enterprise systems. Like traditional non-agentic systems, expanded connectivity can help unlock new business value, but this access should be designed with security controls that limit risks such as data exfiltration, lateral movement, and external manipulation. Threat modeling your agentic AI applications should be a high priority and can help directly align security controls that assist your implementation of zero-trust principles into your strategy.
Self-directed behavior: Advanced agents can initiate activities based on environmental monitoring, scheduling, or learned patterns without human instantiation or review, depending on configuration. This self-direction introduces risks of uncontrolled operations, explainability, and auditability, and makes it difficult to maintain predictable security boundaries.
These capabilities transform security from a boundary problem to a continuous monitoring and control challenge. A compromised agent doesn’t just leak information—it could autonomously execute unauthorized transactions, modify critical infrastructure, or operate maliciously for extended periods without detection.
The Agentic AI Security Scoping Matrix
Working with customers and the community, we’ve identified four architectural scopes that represent the evolution of agentic AI systems based on two critical dimensions: level of human oversight compared with autonomy and the level of agency the AI system is permitted to act within. Each scope introduces new capabilities—and corresponding security requirements—that organizations must prioritize when addressing agentic AI risk. Figure 1 shows the Agentic AI Security Scoping Matrix.
Figure 1 – The Agentic AI Security Scoping Matrix
Scope 1: No agency
In this most basic scope, systems operate with human-initiated processes and no autonomous or even human-approved change capabilities through the agent itself. The agents are, essentially, read-only. These systems follow predefined execution paths and operate under strict human-triggered workflows, which are usually predefined and follow discrete steps, but could be augmented with non-deterministic outputs from an FM. Security focuses primarily on process integrity and boundary enforcement, helping operations remain within predetermined limits and agents are highly controlled and prohibited from change execution and unbounded actions.
Key characteristics:
- Agents can’t directly execute change in the environment
- Fixed step-by-step execution following predetermined paths
- Generative AI components process data within individual workflow nodes
- Conditional branching only where explicitly designed into the workflow
- No dynamic planning or autonomous goal-seeking behavior
- State persistence limited to workflow execution context
- Tool access restricted to specific predefined workflow steps
Security focus: Protecting data integrity within the environment and restricting agents to not exceed their boundaries, especially limits around environment and data modification. Primary concerns include securing state transitions between steps, validating data passed between workflow nodes, and preventing AI components from modifying the orchestration logic or escaping their designated boundaries within the workflow.
Example: We will use a very simplistic example, across all four scopes, of a use case for an agent that is designed to help you create calendar invites. Let’s say you need to book a meeting with another colleague. In Scope 1, you might have an agent that you instantiate through a workflow or prompt to look at your calendar and your colleague’s calendar for available meeting times. In this case, you initiate the request, and the agent executes a contextual search using a Model Context Protocol (MCP) server connected to your enterprise calendaring application. The agent is only allowed to look at available times, analyze the best times to meet, and provide a response back, which a human can then use to manually set up a meeting. In this example, the human defines specific workflows and orchestrations (no agency) and reviews and approves the actions taken (no autonomous change).
Scope 2: Prescribed agency
Moving up in agency and risk, Scope 2 systems also are instantiated by a human, but now have the potential to perform actions—limited agency—that could change the environment. However, all actions taken by an agent require explicit human approval for all actions of consequence—commonly referred to as human in the loop or HITL. These systems can gather information, analyze data, and prepare recommendations, but cannot execute actions that modify external systems or access sensitive resources without human authorization. Agents can also request human input to clarify ambiguities, provide missing context, or optimize their approach before presenting recommendations.
Key characteristics:
- Agents can execute change in the environment with human review and approval
- Real-time human oversight with approval workflows
- Bidirectional human interaction—agents can query humans for context
- Limited autonomous actions restricted to read-only operations (such as, querying data, running analysis jobs, and so on)
- Agent-initiated requests for clarification or additional information
- Audit trails of all human approval decisions and context exchanges
Security focus: Implementing robust approval workflows and preventing agents from bypassing human authorization controls. Key concerns include preventing privilege escalation, enforcing appropriate identity contexts, securing the approval process itself, validating human-provided context to prevent injection attacks, and maintaining visibility into all agent recommendations and their rationale.
Example: In our calendaring example, a Scope 2 agentic system is instantiated by a human. The agent then looks up the stakeholders’ calendar availability, does its analysis, returns a recommendation for a meeting time to the user, and asks the user if they want the agent to send the invitation out on their behalf. The user looks at the response and recommendation of the agent, validates that it meets their requirements, and then acknowledges and approves the agent’s request to modify the calendars and send the invitation. In this example, the human orchestrates a structured workflow, but the agent now can instantiate human reviewed change through bounded actions (limited agency and limited autonomy).
Scope 3: Supervised agency
In Scope 3, we expand the agency to allow for a greater sense of agentic autonomy—high agency—in execution. These are AI systems that execute complex autonomous tasks that are initiated by humans (or at least from an upstream human-managed workflow), with the ability to make decisions and take actions to connected systems without further approval or HITL mechanisms. Humans define the objectives and trigger execution, but agents operate independently to achieve goals through dynamic planning and tool usage. During execution, agents can request human guidance to optimize trajectory or handle edge cases, though they can continue operating without it.
Key characteristics:
- Agents can execute change in the environment, with no (or optional) human interaction or review
- Human-triggered execution with autonomous task completion
- Dynamic planning and decision-making during execution
- Optional human intervention points for trajectory optimization
- Human ability to adjust parameters or provide context mid-execution
- Direct access to external APIs and systems for task completion
- Persistent memory across extended execution sessions
- Autonomous tool selection and orchestration within defined boundaries
Security focus: Implementing comprehensive monitoring of agent actions during autonomous execution phases and establishing clear agency boundaries for agent operations—the bounds you’re willing to let the agents operate within, and actions that would be out of bounds and must be prevented. Critical concerns include securing the human intervention channel to prevent unauthorized modifications, preventing scope creep during task execution, implementing trusted identity propagation constructs, monitoring for behavioral anomalies, and validating that agents remain aligned with original human intent throughout extended operations even when trajectory adjustments are made.
Example: In our calendaring example, a Scope 3 agentic system can still be instantiated by a human. The agent then looks up the stakeholders’ calendar availability, does its analysis, and returns a recommendation for a meeting time to the user; however, it’s within the agent’s bounds to act upon its own recommendation on behalf of the user to automatically book the best available slot. The user is not prompted or expected to give the agent permission to do so prior to its actions. The result is that all stakeholders have a calendar entry added to their calendar in the context of the calling human user. In this example, the human defines an outcome but with more freedom for the agent to determine how to achieve that goal, and the agent now can take autonomous action without human review (high agency and high autonomy).
Scope 4: Full agency
Scope 4 includes fully autonomous AI systems that can initiate their own activities based on environmental monitoring, learned patterns, or predefined conditions, and execute complex tasks without human intervention. These systems represent the highest level of AI agency, operating continuously and making independent decisions about when and how to act. It’s key to note that AI systems within Scope 4 could have full agency when executing within their designed bounds; therefore, it’s critical that humans maintain supervisory oversight with the ability to provide strategic guidance, course corrections, or interventions when needed. Continuous compliance, auditing, and full-lifecycle management mechanisms, both human and automated reviews, which could also be aided by AI, are critical to successfully securing and governing Scope 4 agentic AI systems while limiting risk.
Key characteristics:
- Self-directed activity initiation based on environmental triggers
- Continuous operation with minimal human oversight or HITL processes during execution
- Human ability to inject strategic guidance without disrupting operations
- High to full degrees of autonomy in goal setting, planning, and execution
- Dynamic interaction with multiple external systems and agents
- Capability for recursive self-improvement and capability expansion
Security focus: Implementing advanced guardrails for behavioral monitoring, anomaly detection, scope-based tool access controls, and fail-safe mechanisms to prevent runaway operations. Primary concerns include maintaining alignment with organizational objectives, securing human intervention channels against adversarial manipulation, preventing unauthorized capability expansion, preventing human oversight mechanisms from being disabled by the agent, and enabling graceful degradation when agents encounter unexpected situations.
Example: Let’s look at how we might deploy our AI calendaring example in Scope 4. Let’s say you have implemented a generative AI meeting summarizer. This agent is automatically enabled when you host a web conference. At the conclusion of the meeting, the calendaring agent sees a new meeting occurred from the meeting summarizer agent. It looks at the action items that were summarized and determines that six people agreed to a whiteboard session on Friday. The calendaring agent might either have a statically defined API configuration or leverage dynamic discovery on MCP servers to help with calendaring. It then finds availability for the six identified resources and books the best available slot. It then uses the appropriate identity context of the user who is asking for the meeting to book the meeting autonomously. At no point does a user directly instantiate the request for calendaring; it is fully automated and driven off environment changes that the agent is instructed to look for (full agency and full autonomy).
Scope comparison across the scopes
In the context of the security scoping matrix, let’s compare how autonomy and agency characteristics shift depending on the scope:
Table 1 – Scope impacts on agency and autonomy levels
Critical security dimensions
|
Scope |
Agency level |
Agency characteristics |
Autonomy level |
Autonomy characteristics |
|
Scope 1: No agency |
None |
|
None |
|
|
Scope 2: Prescribed agency |
Limited |
|
Limited |
|
|
Scope 3: Supervised agency |
High |
|
High |
|
|
Scope 4: Full agency |
Full |
|
Full |
|
Each architectural scope requires specific security controls and considerations across six critical dimensions. Table 2 illustrates how security requirements escalate with increasing agency and autonomy:
|
Security dimension |
Scope 1: No agency |
Scope 2: Prescribed agency |
Scope 3: Supervised agency |
Scope 4: Full agency |
|
Identity context (authN and authZ) |
|
|
|
|
|
Data, memory, and state protection |
|
|
|
|
|
Audit and logging |
|
|
|
|
|
Agent and FM controls |
|
|
|
|
|
Agency perimeters and policies |
|
|
|
|
|
Orchestration |
|
|
|
|
Table 2 — Critical security dimensions per scope
Security implementation by scope
Now that we’ve outlined each of the scopes and the associated levels of agency and autonomy, let’s discuss some primary security challenges per scope and key considerations that should be taken to address the associated risks.
Scope 1: No agency
Primary security challenges: Protecting workflow integrity, preventing prompt injection from breaking predetermined flows, and maintaining isolation between workflow executions.
Implementation considerations:
- Comprehensive monitoring with anomaly detection
- Strict data validation and integrity checking
- Input validation at each workflow step boundary
- Immutable workflow definitions with version control
- State encryption and validation between workflow nodes
- Monitoring for attempts to escape workflow boundaries
- Segregation between different workflow executions
- Fixed timeout and resource limits per workflow step
- Audit trails showing actual compared to expected execution paths
Scope 2: Prescribed agency
Primary security challenges: Securing approval workflows, preventing human authorization bypass, and maintaining oversight effectiveness.
Implementation considerations:
- Multi-factor authentication for all human approvers
- Cryptographically signed approval decisions
- Securing bidirectional human-agent communication channels
- Time-bounded approval tokens with automatic expiration
- Comprehensive logging of all approval interactions
- Regular training for human approvers on agent capabilities and risks
Scope 3: Supervised agency
Primary security challenges: Maintaining control during autonomous execution, scope management, explainability and auditability, and behavioral monitoring.
Implementation considerations:
- Clear execution boundaries defined at initiation
- Real-time monitoring of agent actions during execution
- Automated kill switches for runaway processes
- Non-blocking intervention mechanisms
- Behavioral baselines for normal agent operations
- Regular validation of agent alignment with original objectives
Scope 4: Full agency
Primary security challenges: Continuous behavioral validation, enforcing agency boundaries, preventing capability drift, and maintaining organizational alignment.
Implementation considerations:
- Advanced AI safety techniques including reward modeling
- Continuous monitoring with machine learning-based anomaly detection
- Automated response systems for behavioral deviations
- Regular alignment validation through systematic testing
- Tamper-proof human override mechanisms
- Failsafe mechanisms that can halt operations when confidence drops
Key architectural patterns
Successful agentic deployments share common patterns that balance autonomy with control.
Progressive autonomy deployment: Start with Scope 1 or 2 implementations and gradually advance through the scopes as organizational confidence and security capabilities mature. This approach minimizes risk while building operational experience. Be cautious and selective when analyzing use cases and bounding controls for Scope 4 implementations and review your ability to address risks at the lower scopes and how risks increase as you move further up the levels.
Layered security architecture: Implement defense-in-depth with security controls at multiple levels—network, application, agent, and data layers—to safeguard that compromise at one level doesn’t lead to complete system failure. Although the combination of these controls is what enables a high security bar, be sure to spend considerable efforts on making sure that identity and authorization concerns are addressed—for both machines and humans. This helps prevent issues such as the confused deputy problem—when a human or service with lesser permissions is able to elevate permissions through agents that might themselves have more entitlements and privileges.
Continuous validation loops: Establish automated systems that continuously verify agent behavior against expected patterns, and that have escalation procedures for when deviations are detected. Auditability and explainability are key requirements to confirm that agents are performing within the bounds intended and to help you determine control effectiveness, adjust parameters, and validate your orchestration workflows.
Human oversight integration: Even in highly autonomous systems, maintain meaningful human oversight through strategic checkpoints, behavioral reporting, and manual override capabilities. It might be reasonable to assume that human oversight reduces when moving from Scope 1 to Scope 4 agency, but the truth is that it simply shifts focus. For example, the human requirement to instantiate, review, and approve certain agentic actions is higher in Scopes 1 and 2 and lower in Scopes 3 and 4; however, the human requirement to audit, assess, validate, and implement more complex security and operational controls is much higher in Scopes 4 and 3 than they are in Scopes 2 and 1.
Graceful degradation: Design systems to automatically reduce autonomy levels when security events are detected, allowing operations to continue safely while human operators investigate. If your agents start to act in ways that go beyond the intended bounds of their design, anomalous behavior is detected, or they begin to perform actions deemed particularly risky or sensitive to your business, then consider having detective controls that will automatically inject tighter restrictions such as requiring more HITL or reducing the actions an agent can take. You might do this as incremental degradation or, you might choose to disable the agent if it’s acting in ways that negatively impact the environment. These agentic safety mechanisms that can implement additional restrictions or even disable an agent should be considered when building or deploying agents.
Conclusion
The Agentic AI Security Scoping Matrix provides a structured mental model and framework for understanding and addressing the security challenges of autonomous agentic AI systems across four distinct scopes. By accurately assessing your current scope and implementing appropriate controls across all six security dimensions, organizations can confidently deploy agentic AI while managing the landscape of associated risks.
The progression from basic and highly constrained agents to fully autonomous and even self-directing agents represents a fundamental shift in how we approach AI security. Each scope requires specific security capabilities, and organizations must build these capabilities systematically to support their agentic ambitions safely.
Next steps
To implement the Agentic AI Security Scoping Matrix in your organization:
- Assess your current agentic use cases and maturity against the four scopes to understand your security requirements and associated risks. Integrate it into your procurement and SDLC processes.
- Identify capability gaps across the six security dimensions for your target scope.
- Develop a progressive deployment strategy that builds security capabilities as you advance through scopes.
- Implement continuous monitoring and behavioral analysis appropriate for your scope level.
- Establish governance processes for scope progression and security validation.
- Train your teams on the unique security challenges of each scope.
You can find additional information on the Agentic AI Security Scoping matrix here, along with additional information on AI security topics. For additional resources on securing AI workloads, see the AI for security and security for AI: Navigating Opportunities and Challenges whitepaper and explore purpose-built platforms designed for the unique challenges of agentic AI.
If you have feedback about this post, submit comments in the Comments section below.
Security updates for Friday
Post Syndicated from jzb original https://lwn.net/Articles/1047386/
Security updates have been issued by AlmaLinux (delve and golang), Debian (webkit2gtk), Oracle (expat and thunderbird), Red Hat (kernel), Slackware (openvpn), SUSE (chromium, grub2, and kernel), and Ubuntu (cups-filters, imagemagick, and libcupsfilters).
What’s in a name? History
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=zMqRLRLe7ZE
Nikon’s Coolest Camera just got a major update
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=XV7qEfmsipU
AI as Cyberattacker
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/ai-as-cyberattacker.html
From Anthropic:
In mid-September 2025, we detected suspicious activity that later investigation determined to be a highly sophisticated espionage campaign. The attackers used AI’s “agentic” capabilities to an unprecedented degree—using AI not just as an advisor, but to execute the cyberattacks themselves.
The threat actor—whom we assess with high confidence was a Chinese state-sponsored group—manipulated our Claude Code tool into attempting infiltration into roughly thirty global targets and succeeded in a small number of cases. The operation targeted large tech companies, financial institutions, chemical manufacturing companies, and government agencies. We believe this is the first documented case of a large-scale cyberattack executed without substantial human intervention.
[…]
The attack relied on several features of AI models that did not exist, or were in much more nascent form, just a year ago:
- Intelligence. Models’ general levels of capability have increased to the point that they can follow complex instructions and understand context in ways that make very sophisticated tasks possible. Not only that, but several of their well-developed specific skills—in particular, software coding—lend themselves to being used in cyberattacks.
- Agency. Models can act as agents—that is, they can run in loops where they take autonomous actions, chain together tasks, and make decisions with only minimal, occasional human input.
- Tools. Models have access to a wide array of software tools (often via the open standard Model Context Protocol). They can now search the web, retrieve data, and perform many other actions that were previously the sole domain of human operators. In the case of cyberattacks, the tools might include password crackers, network scanners, and other security-related software.
Comic for 2025.11.21 – Five Finger
Post Syndicated from Explosm.net original https://explosm.net/comics/five-finger
New Cyanide and Happiness Comic
Гневни ли сте?
Post Syndicated from Емилия Милчева original https://www.toest.bg/gnevni-li-ste/

Какво очаква председателят на „Продължаваме промяната“ Асен Василев, призовавайки за окупация на парламента на 25 ноември, когато ще се обсъжда бюджетът за 2026-та?
Да окупираме парламента идния вторник, когато се приема бюджетът и да не позволим на прасетата да го приемат. Защото после трудно ще е връщането назад.
Окупацията няма да попречи на ГЕРБ–СДС, БСП, „Има такъв народ“ и ДПС – Ново начало да гласуват бюджета. Освен ако в нея не се включат синдикати, бизнес – изобщо всички недоволни от този бюджет, и не щурмуват парламента. Тоест да се повтори 10 януари 1997 г.
Но това няма да се случи и Асен Василев е наясно. А той готов ли е да поведе щурм? Едно е да поставиш фигура на розово прасе касичка пред Народното събрание, съвсем друго да предвождаш разгневени хора.
Но подобни призиви не са прецедент и показват, че демократични партии адаптират методи, типични за радикалния популизъм, за да постигнат своите цели. Гневът вече не е монопол на екстремистите или националистите, а се превръща в инструмент за мобилизация и натиск.
10 януари няма да се повтори
В действителност Асен Василев не призовава към 10 януари, просто дава сигнал. Политически жест – комуникационен, не революционен, който вдига адреналина на симпатизанти и избиратели, но без реален риск да запали улицата.
Общественият гняв днес е „разреден“ – хората скандират „Свобода!“ и са недоволни, но не са в онзи стадий на екзистенциален страх и отчаяние от 1996–1997 г., когато икономическата катастрофа засегна почти всички. Да, храните поскъпват, бюджетът е силно популистки, но няма хиперинфлация, празни магазини, фалирали банки и масова безизходица. След 40 дни България ще е в еврозоната. Стандартът на живот все още изостава от средните нива за ЕС, но се е подобрил.
Тоест няма маса от десетки хиляди хора, готови да протестират с риск от сблъсък с полицията или арест. През зимата на 1997 г. блокади и протести имаше в цяла България и всички, излезли на улицата, искаха едно: правителството на Жан Виденов и БСП да падне от власт.
За третото тримесечие на 2025 г. индексът на обществено напрежение, който измерва Центърът за анализ и кризисни комуникации заедно със Социологическа агенция „Мяра“, е 6,09 по скалата от 0 до 10. Тази стойност се формира от 21 показателя, сред които държавност и среда, където са всички показатели за политическата ситуация и външните катаклизми, благосъстояниe, публичност и др. Според социолозите 6,09 е в зоната „високо напрежение, трудно контролируем риск“ – или една стъпка дели обществото от „почти неуправляема ситуация“.
При това в края на септември дори не беше внесен спорният бюджет за 2026 г. и все още имаше шанс мярката за неотклонение на кмета на Варна Благомир Коцев да бъде променена в по-лека – от задържане под стража в домашен арест.
Разнопосочни недоволства
Въпреки че данните показват висок индекс на обществено напрежение, липсва колективен фокус. За сериозна окупация са необходими общ враг и общ мотив, а в момента има само разнопосочни недоволства. Едни са гневни заради несправедливото правосъдие и институциите бухалки. Няколко хиляди души в София, Варна и Пловдив се отзоваха на призива на ПП–ДБ за протести в защита на варненския кмет Благомир Коцев, който е 130 дни в ареста. Шествието под наслов „Свобода за политическите затворници“ стигна и до централата на ДПС на ул. „Врабча“.
Тази седмица делото срещу Коцев взе нов обрат. Върховният касационен съд се произнесе по спора кой съд е компетентен да го гледа – Софийският градски или Окръжният във Варна, и го прати на местния съд.
Петимата обвиняеми са от Варна, както и 25 от 28 свидетели, твърди се, че престъпленията са извършени във Варна – значи процесът трябва да се разглежда там.
Включването на неизвестно лице, за което е налице единствено твърдение, че разполага с имунитет, което твърдение не може да бъде проверено по съответния процесуален ред, не е достатъчно, за да обуслови наличието на специална подсъдност […].
Партиите не искат ескалация, затова и не се чуват отчетливи призиви за оставка. Дори симпатизантите на протестните формации са предпазливи към „революционни“ жестове, които могат да бъдат използвани срещу тях. А без политическа коалиция няма критична маса на улицата – правило, доказано от всички протести в най-новата история.
Бизнесът е недоволен заради вдигането на осигуровките с 2 процентни пункта, което е над 10%, и заради данък дивидент, но настоява за преговори, не за барикади. Нито една работодателска организация няма да подкрепи окупация, за да си остави врата за преговори – макар че от години не е имало такъв разрив между управляващите и организациите на предприемачите заради разходите на държавата. Асоциацията на индустриалния капитал в България определи бюджета като „безнадеждно неадекватен“, а Българската работодателска асоциация иновативни технологии предупреди за ефект от забавяне на растежа и отлагане на инвестиции.
В БСП зрее недоволство заради „безгръбначното поведение на ръководството пред Борисов и Пеевски“. ИТН са раздразнени от растящото влияние на Пеевски. Синдикатите пък, в началото гневни заради минималната работна заплата, впоследствие се разбраха с управляващите – както винаги впрочем.
Но пък стотици софиянци са ядосани заради обявената от Столичната община „реформа“, която разширява синята и зелената зона и удвоява цените на платеното почасово паркиране. Кметът Васил Терзиев намери няколко аргумента, за да оправдае действията – корекции на цените не са правени повече от 10 години, мерките ще внесат повече ред, а получените приходи ще се реинвестират в районите. Липсват обаче разчети за прогнозните приходи, какви проекти са подготвени срещу тях, а и как ще се договаря с Центъра за градска мобилност каква част да отива за районните кметства, защото средствата постъпват най-напред в него.
Гневът не преминава в действие
За да стане гневът действие, са необходими ясна цел, усещане, че промяна на системата е възможна – значи има алтернатива, лидерство и готовност да се поеме колективен риск. В момента никоя от парламентарно представените партии не се осмелява да се заяви като алтернатива. Рисковете са прекалено големи – несигурността на пазара на горива, предстоящата смяна на валутата, натискът върху публичните разходи. Затова и предпочитат по-скоро да поддържат огъня, отколкото да вадят кестени от него.
А когато гневът не води до решаване на проблема или преодоляване на препятствието, постепенно се трансформира във фрустрация – усещане за безсилие, разочарование, вътрешно напрежение.
Така че буревестници още няма. Политиците се надвикват, но никой не води.
Истинският въпрос не е „Гневни ли сте?“. Истинският въпрос е кой е способен да превърне гнева в действие, не в динамит.
Т.Е. от Е.Т. – епизод 32
Post Syndicated from Тоест original https://www.toest.bg/t-e-ot-e-t-epizod-32/

В този епизод вървим. Към извънредно положение, институционална катастрофа, обществена ентропия, личностен разпад – кой каквото си избере. А иначе като цяло вървим на майната си.
Следете видеорубриката на Елена Телбис за „Тоест“ и във Facebook, Instagram и TikTok.
Serverless strategies for streaming LLM responses
Post Syndicated from KyungYong Shim original https://aws.amazon.com/blogs/compute/serverless-strategies-for-streaming-llm-responses/
Modern generative AI applications often need to stream large language model (LLM) outputs to users in real-time. Instead of waiting for a complete response, streaming delivers partial results as they become available, which significantly improves the user experience for chat interfaces and long-running AI tasks. This post compares three serverless approaches to handle Amazon Bedrock LLM streaming on Amazon Web Services (AWS), which helps you choose the best fit for your application.
- AWS Lambda function URLs with response streaming
- Amazon API Gateway WebSocket APIs
- AWS AppSync GraphQL subscriptions
We cover how each option works, the implementation details, authentication with Amazon Cognito, and when to choose one over the others.
Lambda function URLs with response streaming
AWS Lambda function URLs provide a direct HTTP(S) endpoint to invoke your Lambda function. Response streaming allows your function to send incremental chunks of data back to the caller without buffering the entire response. This approach is ideal for forwarding the Amazon Bedrock streamed output, providing a faster user experience. Streaming is supported in Node.js 18+. In Node.js, you wrap your handler with awslambda.streamifyResponse(), which provides a stream to write data to, and which sends it immediately to the HTTP response.
Architecture
The following figure shows the architecture.
- The client makes a
fetch()call to the Lambda function URL. - Lambda invokes
InvokeModelWithResponseStreamusing the AWS SDK for JavaScript. - As tokens arrive from Amazon Bedrock, they are written to the response stream.
Implementation steps
- Create a streaming Lambda function: Use a Node.js 18+ or later runtime (necessary for native streaming). Install the AWS SDK to call Amazon Bedrock. In the handler code, wrap the function with
awslambda.streamifyResponseand stream the model output. For example, in Node.js you might do the following: - This code snippet uses the Amazon Bedrock SDK’s async iterable to read the event stream of tokens and writes each to the responseStream.
- Configure the Lambda role: the execution role must allow the Amazon Bedrock invocation (such as
bedrock:InvokeModelWithResponseStreamon the LLM model Amazon Resource Name (ARN)).
Authentication with Amazon Cognito
Lambda function URLs can be set to “None” (public) or “AWS_IAM”. Native Cognito User Pool token authentication isn’t supported, thus you need to implement a solution.
- JWT verification in Lambda: Allow public access and verify a valid JWT from Amazon Cognito in the request header within your Lambda code. This necessitates development effort.
- IAM authorization with Amazon Cognito identity: Use AWS credentials obtained from Amazon Cognito. A more complex setup, especially for web apps, is potentially overkill for a single function.
Pros and cons of Lambda function URLs
Pros:
- Clarity: No API Gateway or other services are needed, which minimizes operational overhead.
- Low latency, high throughput: The response is delivered directly from Lambda to the client. This yields excellent Time To First Byte (TTFB) performance, with no intermediate buffering.
- Direct implementation: For Node.js developers, enabling streaming is as direct as a wrapper and writing to a stream. This is ideal for quick prototypes or single function microservices.
- Lower cost for low concurrent usage: You pay only for Lambda execution time. There’s no persistent connection cost, which is the same as with WebSocket or AWS AppSync. If invocations are infrequent or short, then this could be cost-efficient.
Cons:
- Limited runtime support: Native streaming is only supported in Node.js.
- No built-in user pool auth: Unlike API Gateway or AWS AppSync, Lambda URLs don’t directly support Amazon Cognito user pool authorizers. You must handle auth either through AWS Identity and Access Management (IAM) or manual token validation, adding some development effort and potential security pitfalls if done incorrectly.
- Error handling complexity: Streaming makes error propagation trickier. If an error occurs mid-stream, then you need to decide how to inform the client.
API Gateway WebSocket for streaming
API Gateway WebSocket APIs establish persistent, stateful connections between clients and your backend. This is ideal for real-time applications needing server-initiated messages. The client connects once, sends a prompt to Amazon Bedrock through the WebSocket, and the server pushes the streamed response back over the same connection.
Architecture
The following figure shows the architecture.
- Client connects through the WebSocket URL and store
connectionId. - Client sends a prompt through a custom route to the LLMHandler.
- Lambda as LLMHandler invokes Amazon Bedrock and streams back through WebSocket.
- Client disconnects through the DisconnectHandler and removes
connectionId.
Implementation steps
- Create a WebSocket API in API Gateway with routes
- $connect: Connected to ConnectHandler Lambda.
- $disconnect: Connected to DisconnectHandler Lambda.
- $stream: All messages go to StreamHandler Lambda.
- Create Lambda Authorizer
- Receives the connection request with token in query string.
- Validates the JWT token against Amazon Cognito.
- Returns Allow/Deny policy for the connection.
- Create Connection Handler
- Connection Lambda runs after successful authorization.
- Receives the new connection’s unique connectionId.
- Store connection info in Amazon DynamoDB (optional).
- Returns 200 status to complete the connection.
- Create Disconnect Handler
- Disconnect Lambda is triggered automatically when clients disconnect.
- Receives the terminated connection’s connectionId.
- Cleans up any stored connection data.
- Returns 200 status
- Create LLM Handler
-
- Receives messages sent to the
streamroute. - Extracts prompt from the message body.
- Calls Amazon Bedrock model with streaming response.
- Streams tokens back to the client using the connection ID.
def lambda_handler(event, context): # Extract connectionId and domain details for sending responses connection_id = event["requestContext"]["connectionId"] domain = event["requestContext"]["domainName"] stage = event["requestContext"]["stage"] # Parse message body to get the prompt body = json.loads(event.get("body", "{}")) prompt = body.get("prompt", "") # Create API Gateway management client for sending responses api_client = boto3.client( 'apigatewaymanagementapi', endpoint_url=f'https://{domain}/{stage}' ) # Call Amazon Bedrock with streaming response response = bedrock_client.invoke_model_with_response_stream(...) # Stream tokens back to client for chunk in response["body"]: # Extract token from chunk token = process_chunk(chunk) # Send token directly back through the WebSocket api_client.post_to_connection( ConnectionId=connection_id, Data=json.dumps({"token": token, "isComplete": False}) ) # Send completion message api_client.post_to_connection( ConnectionId=connection_id, Data=json.dumps({"token": "", "isComplete": True}) ) return {"statusCode": 200}
- Receives messages sent to the
-
Authentication with Amazon Cognito
Securing a WebSocket API with Amazon Cognito needs a bit more work. API Gateway WebSocket doesn’t have a built-in Amazon Cognito User Pool authorizer:
- Lambda authorizer with JWT authentication: API Gateway invokes your Lambda authorizer upon connection, validating the Amazon Cognito JWT (passed as a query parameter). The Lambda generates an IAM policy granting access and returns it.
- IAM authentication for WebSockets: Clients sign requests with SigV4 using AWS credentials from an Amazon Cognito Identity Pool. API Gateway evaluates the request against IAM policies.
Pros and cons of API Gateway WebSocket APIs
Pros:
- Bidirectional real-time communication: WebSockets are ideal for applications where the server needs to push data such as the LLM’s response without explicit requests.
- Persistent connection for multi-turn conversations: After the initial handshake, the same connection can be reused for subsequent prompts and responses, avoiding repeated setup latency. This is great for a chat UI where the user asks multiple questions in one session.
- Scalability: API Gateway is a managed service that can handle 500 connections/second and 10,000 requests/second across APIs, which can be increased by request.
Cons:
- Higher development complexity: When compared to the clarity of a direct Lambda URL, a WebSocket API involves multiple Lambdas and coordination to manage the connection state.
- Custom auth implementation: There is no built-in Amazon Cognito user pool integration, thus you must implement a Lambda authorizer.
- Timeout management: The API Gateway integration timeout is 29 s, thus your Lambda function should return the response promptly.
AWS AppSync GraphQL subscription
AWS AppSync is a fully managed GraphQL service that streamlines building real-time APIs. It handles WebSocket connections and client fan-out automatically. Clients subscribe to a GraphQL subscription, and a Lambda resolver pushes the Amazon Bedrock streamed tokens back.
Architecture
The following figure shows the architecture.
- Client calls a
startStreammutation. AppSync invokes the Request Lambda. - The Request Lambda immediately returns a unique
sessionIdand sends the processing task to an Amazon Simple Queue Service (Amazon SQS) queue. - Client uses the
sessionIdto subscribe to anonTokenReceivedGraphQL subscription. - The Processing Lambda (triggered by Amazon SQS) invokes Amazon Bedrock and, for each token, calls a
publishTokenmutation in AWS AppSync. - AWS AppSync automatically pushes the token to all clients subscribed with the matching
sessionId.
Implementation steps
- Design the GraphQL Schema: define types and operations.
- Create the Request Handler (Request Lambda)
- Receives the GraphQL mutation with the prompt.
- Generates a unique session ID.
- Sends the prompt and session ID to the SQS queue.
- Returns the session ID to the client immediately.
- Create the Processing Handler (Processing Lambda)
- It is triggered by Amazon SQS messages.
- It calls Amazon Bedrock with streaming enabled.
- For each token generated, it calls the AppSync
publishTokenmutation.
- Configure GraphQL Resolvers
- StartStream resolver: Connect to the Request Lambda.
- PublishToken resolver: Trigger subscription with a NONE data source.
- Client subscription setup
- Make a
startStreammutation. - Subscribe to receive tokens.
- Make a
Authentication with Amazon Cognito
AWS AppSync integrates seamlessly with Amazon Cognito User Pools. Setting the API’s auth mode to Amazon Cognito User Pool needs a valid JWT for every GraphQL operation. This is the most developer-friendly option for authentication. AWS AppSync handles the handshake and token refresh.
Pros and cons of AWS AppSync subscriptions
Pros:
- Fully managed real-time protocol: You don’t deal with raw WebSockets or connection IDs at all. AWS AppSync automatically establishes and maintains a secure WebSocket for subscriptions (no need for a connect or disconnect Lambda).
- Streamlined authentication: Built-in support for Amazon Cognito User Pool tokens means that you can secure the API without writing custom authorizers.
Cons:
- Potential overhead and complexity: For a direct case (one prompt—one stream), introducing GraphQL and AWS AppSync might be seen as over-engineering if your app doesn’t use GraphQL for other use cases.
- 30-second resolver limit: AWS AppSync has a 30-second limit for mutation resolvers, thus you need to design the initial request to start the process and immediately return, relying on a subscription to stream the results progressively to avoid blocking the user.
Conclusion
The Amazon Bedrock streaming interface unlocks fluid, low-latency LLM experiences. You can use the right AWS serverless architecture to deliver streamed responses in a secure, scalable, and cost-effective way.
- Lambda function URLs with streaming: Direct, single-user applications and prototypes.
- API Gateway WebSocket: Multi-turn conversations, collaborative applications.
- AppSync: Complex applications already using GraphQL.
Each method is serverless, production-ready, and fully integrated with Amazon Cognito for secure access control. AWS provides the flexibility to design high-quality AI user experiences at scale.
Refer to GitHub sample source code for more details.
Comparative table
| Feature | LAMBDA FUNCTION URLS | API GATEWAY WEBSOCKET APIs | APPSYNC GRAPHQL SUBSCRIPTIONS |
| Complexity | Lowest | Medium | High |
| Real-time focus | Limited | Strong | Strong |
| Authentication | Needs custom logic | Needs custom logic | Built-in Amazon Cognito support |
| Scalability | Good | Good | Excellent |
| GraphQL support | None | None | Native |
| Use cases | Q&A | Chatbots, real-time apps | Complex apps, multi-user scenarios |
| Cost | Pay per invocation | Connection time and Lambda execution | Request/connection-based pricing |
This is the Google TPU v7 Ironwood Chip
Post Syndicated from Cliff Robinson original https://www.servethehome.com/this-is-the-google-tpu-v7-ironwood-chip/
At SC25, we saw the Google TPU v7 Ironwood generation package on the show floor and took some photos of Google’s AI chip
The post This is the Google TPU v7 Ironwood Chip appeared first on ServeTheHome.
Introducing attribute-based access control for Amazon S3 general purpose buckets
Post Syndicated from Matheus Guimaraes original https://aws.amazon.com/blogs/aws/introducing-attribute-based-access-control-for-amazon-s3-general-purpose-buckets/
As organizations scale, managing access permissions for storage resources becomes increasingly complex and time-consuming. As new team members join, existing staff changes roles, and new S3 buckets are created, organizations must constantly update multiple types of access policies to govern access across their S3 buckets. This challenge is especially pronounced in multi-tenant S3 environments where administrators must frequently update these policies to control access across shared datasets and numerous users.
Today we’re introducing attribute-based access control (ABAC) for Amazon Simple Storage Service (S3) general purpose buckets, a new capability you can use to automatically manage permissions for users and roles by controlling data access through tags on S3 general purpose buckets. Instead of managing permissions individually, you can use tag-based IAM or bucket policies to automatically grant or deny access based on tags between users, roles, and S3 general purpose buckets. Tag-based authorization makes it easy to grant S3 access based on project, team, cost center, data classification, or other bucket attributes instead of bucket names, dramatically simplifying permissions management for large organizations.
How ABAC works
Here’s a common scenario: as an administrator, I want to give developers access to all S3 buckets meant to be used in development environments.
With ABAC, I can tag my development environment S3 buckets with a key-value pair such as environment:development and then attach an ABAC policy to an AWS Identity and Access Management (IAM) principal that checks for the same environment:development tag. If the bucket tag matches the condition in the policy, the principal is granted access.
Let’s see how this works.
Getting started
First, I need to explicitly enable ABAC on each S3 general purpose bucket where I want to use tag-based authorization.
I navigate to the Amazon S3 console, select my general purpose bucket then navigate to Properties where I can find the option to enable ABAC for this bucket.
I can also use the AWS Command Line Interface (AWS CLI) to enable it programmatically by using the new PutBucketAbac API. Here I am enabling ABAC on a bucket called my-demo-development-bucket located in the US East (Ohio) us-east-2 AWS Region.
aws s3api put-bucket-abac --bucket my-demo-development-bucket abac-status Status=Enabled --region us-east-2
Alternatively, if you use AWS CloudFormation, you can enable ABAC by setting the AbacStatus property to Enabled in your template.
Next, let’s tag our S3 general purpose bucket. I add an environment:development tag which will become the criteria for my tag-based authorization.
Now that my S3 bucket is tagged, I’ll create an ABAC policy that verifies matching environment:development tags and attach it to an IAM role called dev-env-role. By managing developer access to this role, I can control permissions to all development environment buckets in a single place.
I navigate to the IAM console, choose Policies, and then Create policy. In the Policy editor, I switch to JSON view and create a policy that allows users to read, write and list S3 objects, but only when they have a tag with a key of “environment” attached and its value matches the one declared on the S3 bucket. I give this policy the name of s3-abac-policy and save it.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/environment": "development"
}
}
}
]
}
I then attach this s3-abac-policy to the dev-env-role.
That’s it! Now a user assuming the dev-role can access any ABAC-enabled bucket with the tag environment:development such as my-demo-development-bucket.
Using your existing tags
Keep in mind that although you can use your existing tags for ABAC, because these tags will now be used for access control, we recommend reviewing your current tag setup before enabling the feature. This includes reviewing your existing bucket tags and tag-based policies to prevent unintended access, and updating your tagging workflows to use the standard TagResource API (since enabling ABAC on your buckets will block the use of the PutBucketTagging API). You can use AWS Config to check which buckets have ABAC enabled and review your usage of PutBucketTagging API in your application using AWS Cloudtrail management events.
Additionally, the same tags you use for ABAC can also serve as cost allocation tags for your S3 buckets. Activate them as cost allocation tags in the AWS Billing Console or through APIs, and your AWS Cost Explorer and Cost and Usage Reports will automatically organize spending data based on these tags.
Enforcing tags on creation
To help standardize access control across your organization, you can now enforce tagging requirements when buckets are created through service control policies (SCPs) or IAM policies using the aws:TagKeys and aws:RequestTag condition keys. Then you can enable ABAC on these buckets to provide consistent access control patterns across your organization. To tag a bucket during creation you can add the tags to your CloudFormation templates or provide them in the request body of your call to the existing S3 CreateBucket API. For example, I could enforce a policy for my developers to create buckets with the tag environment=development so all my buckets are tagged accurately for cost allocation. If I want to use the same tags for access control, I can then enable ABAC for these buckets.
Things to know
With ABAC for Amazon S3, you can now implement scalable, tag-based access control across your S3 buckets. This feature makes writing access control policies simpler, and reduces the need for policy updates as principals and resources come and go. This helps you reduce administrative overhead while maintaining strong security governance as you scale.
Attribute-based access control for Amazon S3 general purpose buckets is available now through the AWS Management Console, API, AWS SDKs, AWS CLI, and AWS CloudFormation at no additional cost. Standard API request rates apply according to Amazon S3 pricing. There’s no additional charge for tag storage on S3 resources.
You can use AWS CloudTrail to audit access requests and understand which policies granted or denied access to your resources.
You can also use ABAC with other S3 resources such as S3 directory bucket, S3 access points and S3 tables buckets and tables. To learn more about ABAC on S3 buckets see the Amazon S3 User Guide.
You can use the same tags you use for access control for cost allocation as well. You can activate them as cost allocation tags through the AWS Billing Console or APIs. Check out the documentation for more details on how to use cost allocation tags.
Heisenberg Dependency Health Check – GitHub Action for Supply Chain Risk
Post Syndicated from Darknet original https://www.darknet.org.uk/2025/11/heisenberg-dependency-health-check-github-action-for-supply-chain-risk/
Heisenberg Dependency Health Check is a GitHub Action that flags risky or newly introduced dependencies in pull requests using supply-chain signals.
SpellVault’s evolution: Beyond LLM apps, towards the agentic future
Post Syndicated from Grab Tech original https://engineering.grab.com/spellvault-evolution-beyond-llm
Introduction
At Grab, innovation isn’t just about building new features; it’s about evolving our platforms to meet the changing needs of our users and the broader technological landscape. SpellVault, our internal AI platform, exemplifies this philosophy. When SpellVault was first launched, our vision was straightforward: empower everyone at Grab to effortlessly build and manage AI-powered apps without the need for coding. Built on the principles of Retrieval-Augmented Generation (RAG) and enhanced by plugin support, SpellVault rapidly evolved into a powerful productivity engine for the organization, enabling the creation of thousands of apps that drive automation, foster experimentation, and support production use cases.
As the AI landscape has evolved, SpellVault has grown alongside it. Initially launched as a straightforward no-code app builder for Large Language Models (LLMs), it has now evolved into a cutting-edge platform that embraces the agentic future—a future where AI goes beyond generating responses to reasoning, acting, and dynamically adapting through the use of tools and contextual understanding.
This article outlines SpellVault’s journey towards an agentic future and how we empower users to build AI Agents that are smarter, more adaptable, and ready for the future.
A no-code platform for building LLM apps
SpellVault was founded with a clear mission: to democratize access to AI for everyone at Grab, regardless of their technical expertise. Initially launched as a no-code LLM app builder, the platform was built on a foundation of RAG pipelines and basic plugin support.
Early on, we recognized that the true potential of AI apps extends beyond the capabilities of language models alone. Their real value lies in the ability to seamlessly interact with external systems and diverse data sources. This insight drove our commitment to minimizing barriers and ensuring users could access data from various sources with ease. From the very beginning, we centered our efforts on three key focus areas:
Comprehensive RAG solution with useful integrations
From the start, the SpellVault team prioritized enabling users to enhance their LLM apps with data through RAG. Rather than solely relying on the LLM’s internal information, we wanted the apps to ground their responses in up-to-date, contextually relevant, and factual information. SpellVault has built-in integrations with knowledge sources such as Wikis, Google Docs, as well as plain text and PDF uploads. These capabilities empower users to build assistants that reference relevant knowledge and provide more accurate, verifiable answers.
Plugins to fetch information on demand
To move beyond static knowledge retrieval, we needed a way for apps to act dynamically. This was made possible through SpellVault plugins—modular components that allow apps to interact with internal systems (e.g. service dashboards, incident trackers) and external APIs (e.g. search engines, weather data). Rather than being confined to their initial prompt and data, these plugins can fetch fresh information at runtime. From the available plugin types, users can create their own instances of plugins with custom settings, enabling highly specialized functionality tailored to their specific workflows. For instance, with SpellVault’s HTTP plugin, users can define custom endpoints and credentials, enabling their AI apps to make tailored HTTP calls during runtime. These custom plugins have become the backbone of many of our most impactful apps, empowering teams to seamlessly integrate SpellVault with their existing systems and processes.

Making SpellVault accessible via common interfaces: Web, Slack, API
One of our primary goals was to make AI seamlessly accessible and useful within the tools users already use—whether it’s a browser or Slack. With SpellVault, users can make their AI apps in minutes and start using them via browser or Slack messaging immediately and intuitively, without requiring any additional setup. We also exposed APIs that enabled other internal services to integrate with SpellVault apps for a variety of use cases. This multi-channel approach ensured that SpellVault wasn’t just a standalone sandbox but a platform woven into existing tools and processes.
Users quickly adopted the platform, creating thousands of apps for internal productivity gains, automation, and even production use cases. The platform’s success validated our hypothesis that there was significant demand for democratized AI tools within the organization.

Evolution over time
The AI landscape over the past few years has been defined by relentless change. New frameworks, execution paradigms, and standards have emerged in quick succession, each promising to make AI systems more powerful, more reliable, or more extensible. At Grab, we recognized that for SpellVault to stay relevant, it could not remain static. It needed to evolve in tandem with the ever-changing ecosystem, continuously incorporating valuable advancements while ensuring a seamless experience for our users.
This philosophy of continuous adaptation has guided SpellVault’s journey. From its early days as a simple RAG-powered app builder with a few plugins, the platform grew to support an extensive number of plugin types, richer execution models, and eventually a unified approach to tools. Each step was a response both to the needs of our users and to the shifting definition of what “building with AI” meant in practice. Rather than opting for a complete overhaul, SpellVault has embraced incremental advancements, ensuring that users can seamlessly benefit from new capabilities without disruption.
This approach to evolution has naturally positioned SpellVault to transition from a platform for LLM apps to one designed for AI agents. The following section delves into this transition in greater detail.
Expanding capabilities
Over time, we introduced numerous new capabilities to SpellVault, driven both by user feedback and our commitment to innovation and staying ahead of industry trends. For instance, we extended support for different plugin types, enabling integrations with tools like Slack and Kibana, and continuously added more integrations to enhance the platform’s versatility. We implemented auto-updates for users’ Knowledge Vaults, ensuring their data remained current. With more users building with the platform, ensuring the trustworthiness of responses generated by SpellVault apps became increasingly important. We included citation capability to mitigate some of that concern. Recognizing the need for more precise answers to mathematical problems, we developed a feature that enabled LLMs to solve such problems using Python runtime. Additionally, many users requested an automated way to trigger their LLM apps, which led to the creation of a Task Scheduler feature that allows LLMs to schedule actions based on natural language user input.
A significant milestone in SpellVault’s evolution was the introduction of “Workflow,” a drag-and-drop interface within the platform that empowered users to design deterministic workflows. These workflows enabled users to seamlessly combine various components from the SpellVault ecosystem—such as LLM calls, Python code execution, and Knowledge Vault lookups—in a predefined and structured manner. This enabled advanced use cases for many users.

Shifting the execution model
As SpellVault evolved, a fundamental shift took place in the way its apps were executed internally. We transitioned from our legacy executor system, which facilitated one-off information retrieval from the Knowledge Vault or user plugins, to a more advanced graph based executor. This empowered SpellVault’s app execution with nodes, edges, and states that supported branching, looping, and modularity. This laid the groundwork for more sophisticated agent behaviors, moving beyond the linear input-output paradigm.
This transformed all existing SpellVault apps into ‘Reasoning and Acting’ agents, better known as ReAct agents – a “one size fits many” solution that significantly enhanced the capabilities of these apps. By enabling them to leverage the Knowledge Vault and plugins in a more agentic and dynamic manner, the ReAct agent framework allowed apps to perform more complex tasks while seamlessly preserving their existing functionality, ensuring no disruption to their behavior.
In addition, the internal decoupling of the executor and prompt engineering components enabled us to design multiple execution pathways with ease. This allowed us to provide generic Deep Research capability to any SpellVault app via a simple UI checkbox, as well as sophisticated internal workflows that cater to high-ROI complex use cases like on-call alert analysis. The Deep Research capability came with SpellVault’s ability to search across internal information repositories (e.g., Slack messages, Wiki, Jira) within Grab, as well as searching online for relevant information.

Towards an agentic framework
Over time, several capabilities were added to SpellVault, including features like Python code execution and internal repository search. Initially, these functionalities were integrated directly into the core PromptBuilder class. For users, these features were primarily accessible through simple checkboxes in the user interface. As SpellVault gradually transitioned towards giving more agency to user-crafted apps, we recognized that these capabilities should instead be positioned as “Tools” for LLMs to use with greater autonomy, similar to how ReAct agent–backed apps have been using SpellVault’s user plugins. We also understood that this shift could bring a clearer mental model for users where they were no longer simply toggling features but creating AI agents with access to a defined set of tools. The agents could then decide when and how to use those tools intelligently to accomplish tasks, making the overall experience more natural and intuitive.
This recognition led to the consolidation of these scattered capabilities into a unified framework called “Native Tools.” These Native Tools, along with SpellVault’s existing user plugins—rebranded as “Community Built Tools”—formed a comprehensive collection of tools that LLMs could dynamically invoke at runtime. Despite being grouped under the same umbrella, a key distinction was maintained: Native Tools required no user-specific configuration (e.g., performing internet searches), whereas Community Built Tools were custom, user-configured entities (e.g., invoking specific HTTP endpoints) created from available plugin types, often requiring credentials or other personalized settings.
This consolidation of capabilities under a unified Tools abstraction and enabling SpellVault apps to invoke them with greater autonomy marked a pivotal milestone in the platform’s evolution. It meaningfully shifted SpellVault toward making agentic behavior more natural, discoverable, and extensible for every app.

SpellVault as an MCP service
As we streamlined SpellVault’s internal capabilities into a unified tools framework, we also turned our focus outward to align with industry standards. The growing adoption of the Model Context Protocol (MCP) presented an opportunity for agents and clients to seamlessly interact without requiring custom integrations. To remain at the forefront of innovation, we adapted SpellVault to function as an MCP service, enabling it to actively participate in this evolving ecosystem. This extension brought two key advancements:
-
SpellVault apps as MCP tools: Each app created in SpellVault can now be exposed through the MCP protocol. This allows other agents or MCP-compatible clients, such as IDEs or external orchestration frameworks, to treat a SpellVault app as a callable tool. Instead of living only inside our web user interface or Slack interface, these apps become accessible building blocks that other systems can invoke dynamically.
-
RAG as an MCP tool: We extended the same idea to our Knowledge Vaults. Through MCP, external clients can search, retrieve, and even add information to Vaults. This effectively turns SpellVault’s RAG pipeline into an MCP-native service, making contextual grounding available to agents beyond SpellVault itself.
While building the SpellVault MCP Server, we also created TinyMCP – a lightweight open-source Python library that adds MCP capabilities to an existing FastAPI app as just another router, instead of mounting a separate app.
By exposing both apps and RAG through MCP, we shifted SpellVault from being a self-contained platform to becoming an interoperable service provider in the agentic ecosystem. Users still benefit from the no-code simplicity inside SpellVault. However, the output of their work, apps, and knowledge, are now usable by other agents and tools outside of it.
Conclusion
SpellVault’s evolution shows how a platform can adapt with the AI landscape while staying true to its original mission of making powerful technology accessible to everyone. What began as a no-code builder for LLM apps has steadily expanded into an agentic platform – one where apps can act with more intelligence, agency, and context and interact with the systems around them.
This progress wasn’t the result of a single breakthrough, but of steady, incremental improvements that introduced new capabilities while preserving ease of use. By layering in these advancements thoughtfully but boldly, SpellVault has managed to support more sophisticated agentic behaviors without compromising its original goal of democratizing AI at Grab.
Join us
Grab is a leading superapp in Southeast Asia, operating across the deliveries, mobility and digital financial services sectors. Serving over 800 cities in eight Southeast Asian countries, Grab enables millions of people everyday to order food or groceries, send packages, hail a ride or taxi, pay for online purchases or access services such as lending and insurance, all through a single app. Grab was founded in 2012 with the mission to drive Southeast Asia forward by creating economic empowerment for everyone. Grab strives to serve a triple bottom line – we aim to simultaneously deliver financial performance for our shareholders and have a positive social impact, which includes economic empowerment for millions of people in the region, while mitigating our environmental footprint.
Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!










