AWS Introduces Loom: A New Open-Source Platform for Building and Governing Secure AI Agents at Scale

AWS recently unveiled Loom, an open-source, opinionated agent platform designed to guide organizations in building, deploying, and governing AI agents on the AWS cloud. The platform emphasizes robust security controls integrated from the initial development stages. Loom leverages the Strands Agents SDK for agent creation and utilizes Amazon Bedrock AgentCore Runtime for execution, with its availability on AWS Labs signifying its role as a concrete example for organizations to emulate rather than a directly managed service. This strategic release aims to empower platform engineering teams by addressing key challenges in scaling AI agent deployments, offering a blueprint for secure and manageable AI operations within the enterprise.

The introduction of Loom addresses a critical need in the rapidly evolving landscape of enterprise AI. As organizations increasingly explore the potential of AI agents for automating tasks, enhancing customer interactions, and driving business insights, the complexities of secure development, deployment, and governance at scale become paramount. Loom’s open-source nature and its positioning as a reference implementation suggest a move by AWS to foster a more standardized and secure approach to custom AI agent development, while simultaneously showcasing the capabilities of its underlying cloud services.

Loom’s architecture is meticulously structured around seven core challenges that platform engineering teams commonly encounter when expanding AI agent initiatives. These challenges include: the enforcement of consistent resource tagging for inventory and cost management; the implementation of granular role-based and attribute-based access controls to ensure data security and operational integrity; the development of standardized deployment blueprints for repeatable and reliable deployments; the validation of software components prior to deployment to mitigate risks; the propagation of identity through delegated actor chains to maintain auditability and accountability; the management of agent sprawl to prevent unmanageable proliferation of AI entities; and the necessity of human review for sensitive actions to maintain oversight and prevent unintended consequences.

A significant technical hurdle addressed by Loom is the intricate problem of identity propagation within complex agent interactions. In scenarios where an AI agent acts on behalf of an end-user, interacts with a Machine Control Plane (MCP) server, and subsequently calls a REST API, each step in this delegation chain requires an access token that accurately preserves the originating user’s identity and associated permissions. Loom tackles this by implementing the complete authorization code flow for user interactions. It harnesses the RFC 8693 token exchange process, natively supported by AgentCore Identity. This ensures that both the end-user and the agent’s identity are seamlessly carried within downstream access tokens, thereby maintaining the integrity of the delegation chain. The platform provides visualization capabilities for each hop in this exchange, illustrating the flow from the agent to the MCP server and finally to an Amazon API Gateway endpoint, each equipped with its own “on-behalf-of” token. This robust mechanism ensures that downstream systems only expose data to which the originating user is explicitly permitted to access, reinforcing a principle of least privilege.

The deployment model adopted by Loom deliberately steers clear of runtime code generation. Instead, it champions a configuration-driven approach. Loom agents are pre-written and configurable Python applications built using the Strands Agents SDK. Behavioral guidelines, memory resources, and configurations for MCP or agent-to-agent (A2A) integrations are injected at deployment time. This methodology ensures that the core agent code remains static between deployments, with changes exclusively managed through configuration updates. This allows platform teams to conduct a single security scan of the agent code, integrate enterprise-specific customizations like advanced logging requirements, and then reuse this audited code across all deployments. For teams requiring minimal customization, Loom offers a no-code path through AgentCore’s managed harness, further simplifying the deployment process. Crucially, Loom itself does not store any secrets or credentials. These sensitive elements are managed externally within AWS Secrets Manager and are retrieved only when required, with both inbound and outbound authentication handled by AgentCore Identity, reinforcing a layered security posture.

Governance within Loom is implemented through two primary mechanisms. Tag profiles are mandated to enforce three essential tags on every deployed resource: loom:application, loom:group, and loom:owner. These tags are crucial for resource identification, cost allocation, and operational management. Additionally, optional custom tags, such as cost center identifiers, can be incorporated to enhance financial tracking and departmental accountability. Access control operates on a dual-dimensional framework. The user’s role dictates their inherent capabilities and the scope of their view within the platform, while group tags determine the specific resources and agents they can access. This segregation ensures that administrators have a comprehensive catalog dashboard, whereas end-users are presented with a streamlined chat interface, visibility into agents within their assigned group, and access only to their personal conversation history, thereby minimizing exposure and simplifying user experience.

For agent discovery, Loom integrates with the AWS Agent Registry, which is currently in public preview. This integration ensures compliance with the Agent-to-Agent (A2A) agent card specification and the Machine Control Plane (MCP) tool schema, facilitating interoperability and discoverability. A rigorous review process is in place for agents before they can be published for production use, ensuring a baseline level of quality and security. An earlier write-up by Heeki Park, a principal solutions architect at AWS and a key figure behind Loom, detailed the integration with AWS Agent Registry, highlighting a practical friction point: the Agent Registry ARN comprises a random alphanumeric string rather than a human-readable registry name. This characteristic necessitates the use of wildcards in IAM policies for registry actions, a detail that platform engineering teams should be aware of when configuring access.

The human-in-the-loop review process is a cornerstone of Loom’s security and governance model, implemented through three distinct pathways. These methods leverage the Strands Agents hook framework and native MCP elicitations, enabling sensitive tool invocations to be paused and routed for human approval before execution. This ensures that critical or potentially impactful actions are subject to human judgment, providing an essential safeguard against autonomous AI decision-making in high-stakes scenarios.

The initial community reaction to Loom suggests a cautious, wait-and-see approach. A thread on Reddit inquiring about early deployments of Loom yielded no reported instances two days after its release. However, one commenter provided a substantive assessment that accurately captures both the platform’s appeal and the inherent questions surrounding adoption versus custom development. The commenter stated, "I think Loom is one of the more promising new products from AWS and should certainly be considered for corporate AI agent rollout projects. If you look at docs and Loom dashboard, it’s quite well thought out and opinionated in a good way. You could probably build your own version in a week though." This sentiment highlights the perceived value of Loom’s thoughtful design and opinionated structure, while also acknowledging the potential for organizations with specific needs or existing infrastructure to replicate its functionality.

From a cost perspective, Loom itself is provided as free and open-source software. The associated costs are incurred through the underlying AWS managed services required for its operation, such as Amazon Bedrock AgentCore Runtime, AWS Secrets Manager, and potentially others depending on the scale and complexity of the agent deployments. This model allows organizations to leverage the platform without direct licensing fees, shifting the cost structure to consumption-based usage of AWS services.

Loom enters a burgeoning category of AI agent platforms, a space that is rapidly evolving. Companies like Anthropic, with their Claude Apps Gateway, are offering access and cost control layers specifically for AI coding tools. InfoQ recently covered Anthropic’s offering, noting its focus on managing AI-powered development tools. In contrast, Loom demonstrates the platform layer for broader custom AI agent workloads, encompassing identity management, deployment pipelines, registry governance, and approval workflows. The difference in maturity is notable; Anthropic’s gateway is presented as a supported product, whereas Loom is positioned as an AWS Labs reference implementation. This distinction suggests that Loom is intended for organizations embarking on greenfield builds of their own agent platforms, and its role-based access model still exhibits visible demo scaffolding, indicating potential areas for further refinement and feature development.

The Loom repository itself is comprehensive, offering essential overview documentation, detailed specifications that underpin the platform’s architecture, and a practical deployment guide that includes instructions for cleanup after testing. This accessibility of information is crucial for platform engineering teams looking to understand, adapt, and implement the Loom framework within their organizational contexts. As the adoption of AI agents continues to accelerate, platforms like Loom are poised to play a significant role in shaping how enterprises build, manage, and secure these powerful new tools.