AWS Loom: open-source AI agent governance for enterprises

Key Takeaways

• Loom is a reference implementation, not a managed service. AWS expects enterprises to fork and customize it.
• Identity propagation through token exchange solves the hardest problem in multi-hop agent architectures.
• Configuration-driven deployment means agent code never changes between environments, only behavior settings.

AWS has released Loom, an open-source platform that shows enterprises how to build, deploy, and govern AI agents with security controls from the start. The project lives on AWS Labs and combines the Strands Agents SDK with Amazon Bedrock AgentCore Runtime. AWS is explicit about what Loom is not: a managed service. It is a reference implementation, a starting point for platform teams who want to build their own agent infrastructure.

What problems does Loom solve?

The platform grew out of a prototype by Heeki Park, a principal solutions architect at AWS, who documented the work on Medium in June before it graduated to AWS Labs. Park structured Loom around seven challenges that platform engineering teams hit when scaling agent deployments: enforcing consistent resource tagging, implementing role-based and attribute-based access controls, building deployment blueprints, validating software before deployment, propagating identity through delegation chains, managing agent sprawl, and requiring human review before sensitive actions.

Identity propagation is the hardest problem on that list. When an agent acts on behalf of a user, calls an MCP server, which in turn calls a REST API, each hop needs an access token that preserves the originating user's identity and permissions. Loom implements the full authorization code flow for user interactions and uses the RFC 8693 token exchange process supported by AgentCore Identity. Both the end user and agent identity travel in downstream access tokens while the delegation chain stays intact. The platform visualizes each hop of the exchange, from agent to MCP server to Amazon API Gateway endpoint.

How does deployment work?

Loom takes a deliberate stance against runtime code generation. It deploys a pre-written, configurable Python agent built with Strands Agents. Behavioral guidelines, memory resources, and MCP or agent-to-agent configurations get injected at deployment time. Code never changes between deployments. Only configuration does.

This matters for security. Platform teams can scan the agent code once, add enterprise customizations like logging requirements, and reuse it across every deployment. Teams that need no customization can instead use the no-code path through AgentCore's managed harness. Secrets and credentials are not stored in Loom at all. They live in AWS Secrets Manager and are pulled in only when required, with inbound and outbound auth managed by AgentCore Identity.

What governance controls does it include?

Governance runs through two mechanisms. Tag profiles enforce three mandatory tags (loom:application, loom:group, loom:owner) on every deployed resource, with optional custom tags such as cost center identifiers. Access control combines two dimensions: role type determines the capabilities and view a user gets, while group tags determine which resources they can see. Administrators land on a catalog dashboard. End users see only a chat interface, agents in their own group, and their own conversation history.

For agent discovery, Loom integrates with AWS Agent Registry, currently in public preview, complying with the agent-to-agent card specification and the MCP tool schema. Agents undergo a review process before they can be published for production use. Park's earlier write-up on that integration surfaced a friction point: the registry ARN contains only a random alphanumeric string rather than the registry name, forcing IAM policies for registry actions to use a wildcard resource.

Human-in-the-loop review is implemented three ways, using the Strands Agents hook framework and native MCP elicitations. Sensitive tool invocations pause for human approval before executing.

Early community reaction

The reaction so far reflects a wait-and-see stance. A Reddit thread asking whether anyone had deployed Loom drew no deployment reports two days after release. One commenter offered the only substantive assessment, capturing both the appeal and the build-versus-adopt question that reference implementations invite.

The lack of early adopters is not surprising. Reference implementations require engineering investment to fork, customize, and maintain. Teams evaluating Loom need to weigh that cost against building from scratch or waiting for managed alternatives.

Frequently Asked Questions

Is AWS Loom a managed service?

No. Loom is an open-source reference implementation on AWS Labs. AWS expects enterprises to fork and customize it for their own infrastructure.

What SDKs does Loom use?

Loom builds agents with the Strands Agents SDK and runs them on Amazon Bedrock AgentCore Runtime.

How does Loom handle identity propagation?

Loom implements RFC 8693 token exchange through AgentCore Identity. Both end user and agent identity travel in downstream access tokens while the delegation chain stays intact.

Does Loom store secrets or credentials?

No. Secrets live in AWS Secrets Manager and are pulled in only when required. AgentCore Identity manages inbound and outbound authentication.

What tags does Loom require on deployed resources?

Loom enforces three mandatory tags: loom:application, loom:group, and loom:owner. Custom tags like cost center identifiers are optional.

Source: InfoQ