AWS Releases Loom, an Open-Source Reference Platform for Governing AI Agents at Enterprise Scale
Steef-Jan Wiggers · rss · 2026-07 Reader 🖥️
Agent Governance (Internal)Agent SecurityAgent-to-Agent ProtocolsAgent Tool ManagementHuman-in-the-LoopMCP (Model Context Protocol)Platform Engineering
Loom demonstrates — as a free, open-source reference implementation rather than a managed product — that enterprise-grade AI agent governance is achievable today by composing existing AWS primitives (Strands Agents, Bedrock AgentCore Identity, RFC 8693 token exchange, Secrets Manager) into a configuration-driven, identity-propagating platform, with resource tagging and delegated on-behalf-of tokens as the two mechanisms that make agent actions auditable and scoped end-to-end.
practical · expository — A news report (InfoQ) summarizing an AWS product announcement. It doesn't argue a thesis so much as describe an artifact and position it in a category — but the description itself embodies a practical claim about how enterprises should build agent platforms, and the closing paragraphs make an explicit comparative/evaluative move (Loom vs. Claude apps gateway; reference implementation vs. supported product).
Structure
| Part | Role |
|---|---|
| Opening framing (what Loom is and how it's built) | context |
| The seven challenges Loom is structured around (tagging, RBAC/ABAC, deployment blueprints, validation, identity propagation, agent sprawl, human review) | structural skeleton for the rest of the article |
| Deep dive on identity propagation (RFC 8693 token exchange, delegated actor chains, on-behalf-of tokens per hop) | evidence — the article's own framing names this 'the hardest problem on that list' |
| Deployment model: pre-written configurable agent vs. runtime code generation, secrets pulled from Secrets Manager not stored in Loom | evidence for a specific design stance (configuration over code generation) that underwrites auditability |
| Governance mechanisms: mandatory tag profiles + two-dimensional access control (role type x group tags) | evidence |
| Agent discovery via AWS Agent Registry (A2A card spec, MCP tool schema) plus a friction point from Park's earlier write-up (wildcard ARNs) | evidence, with an embedded caveat about registry maturity |
| Human-in-the-loop review via Strands hooks + MCP elicitations | evidence |
| Reddit community reaction: cautiously positive, no deployment reports yet, one comment noting 'you could probably build your own version in a week though' | counter-evidence / reality check on adoption and on the reference-implementation value proposition |
| Positioning against Anthropic's Claude apps gateway; explicit maturity caveat (Loom carries 'visible demo scaffolding') | conclusion — categorizes Loom within a forming market and qualifies its own claims |
Key terms
- reference platform / reference implementation
A concrete, open-source example of how an organization could build its own agent governance platform — explicitly not a managed AWS service, and explicitly not production-hardened (it 'carries visible demo scaffolding'). - identity propagation
Preserving both the originating end-user's identity and the acting agent's identity through every hop of a multi-step call chain (agent -> MCP server -> REST API), so each downstream system can enforce the original user's actual permissions rather than the agent's broad service-account permissions. - delegated actor chain
The sequence of hops (agent to MCP server to API Gateway endpoint) each carrying its own on-behalf-of access token, together preserving an unbroken record of who ultimately authorized the action. - configuration-driven deployment
A deployment model where a single pre-written, security-scanned agent codebase is reused across all deployments, with behavior varied only via injected configuration (behavioral guidelines, memory resources, MCP/A2A wiring) — deliberately excluding runtime code generation. - tag profile / mandatory tagging
A required set of three resource tags (loom:application, loom:group, loom:owner) enforced on every deployed resource, used as the join key between resource-level governance and group-based access control. - agent sprawl
One of the seven named platform-engineering challenges — the proliferation of agents, memory resources, MCP servers and A2A integrations without centralized visibility or lifecycle management — that Loom addresses via a catalog dashboard and registry integration.
Propositions
- explicitLoom is a free, open-source, opinionated reference platform for building, deploying, and governing AI agents on AWS, explicitly positioned as an example to build from rather than a managed service.conf: high
- explicitcorroboratedPreserving the delegation chain across every hop of an agent-to-MCP-server-to-API call requires an explicit token-exchange mechanism (RFC 8693), not just a single authentication event at session start.conf: highextendsAWS Launches Amazon GuardDuty Investigation Agent to Automate Threat Triage · p9 — The GuardDuty article named Loom as the reference platform answering its own unresolved agent-deployment governance questions; this extraction supplies the specific mechanism (RFC 8693 token exchange, delegated actor chains) it deferred to.extendsAI Model Context Protocol Adds Centralised Auth for Enterprise · p10 — MCP's Enterprise-Managed Authorisation explicitly stops at connection-level access and leaves runtime, per-action authorization to the organization; Loom's RFC 8693-based identity propagation is a concrete instance of exactly that missing runtime layer.supports ←Podcast: Securing AI Agents: Identity, Authorization, and the DPACT Framework · p10 — Both treat direct reuse of a human's token/credential as the anti-pattern; Loom's RFC 8693 token-exchange mechanism is a concrete instance of the separation DPACT calls for.extends ←The Interfaces Are Arriving · p11 — Names the harder problem that Loom's RFC 8693 token-exchange mechanism only partially addresses: preserving a delegation chain across hops is necessary, but the article observes there is still no common mechanism for how authority should narrow at each hop.
- implicitA configuration-driven deployment model (fixed, pre-scanned agent code plus injected configuration) is safer and more auditable at scale than allowing agents to generate or modify their own code at deployment or runtime.conf: high
- implicitMandatory, enforced resource tagging (rather than optional or best-effort tagging) is a necessary foundation for scope-based access control in a multi-tenant agent platform.conf: high
- explicitSecrets and credentials should never be stored inside the agent platform itself; they should live in a dedicated secrets manager and be pulled in only at the moment of use.conf: highsupportsHow to Manage Privilege Drift in Multi-Agent Systems · p6 — Both propositions converge on pulling short-lived, just-in-time credentials from a dedicated store rather than embedding long-lived secrets in agent configuration.
- explicitA free, open-source reference implementation for agent governance is materially different from — and less mature than — a vendor-supported governance product, even when they compete for the same buyer's attention.conf: highsupportsGKE Security Blueprint Joins Growing List of Cloud AI Frameworks · p11 — Loom is AWS's own entry in the near-simultaneous, cross-vendor convergence on packaged AI governance frameworks/blueprints that the GKE article observes across Google, AWS, and Microsoft.
- implicitThe practical value of a well-designed reference platform can be undercut by how easy it is to reimplement the same idea independently, making 'build vs. adopt' a live, unresolved question for teams considering it.conf: medium
- explicitcorroboratedHuman-in-the-loop review for sensitive agent actions can be implemented as a first-class platform capability (via hooks and MCP elicitations) rather than as an ad hoc, per-agent afterthought.conf: highsupports ←10 Things Developers Want from their Agentic IDEs in 2025 · p9 — Both describe human-in-the-loop review for sensitive/destructive agent actions as something implementable as a first-class platform capability (hooks/MCP elicitations), not merely a developer wish.extends ←Human Oversight Is Not a Human in the Loop · p10 — AWS Loom's point that human-in-the-loop review should be a first-class platform capability rather than an ad hoc afterthought is a concrete implementation of Bataller's claim that the system itself — not just the supervising human — must be engineered to preserve the conditions for meaningful oversight.
- explicitCentralized agent/tool discovery (via a registry complying with the A2A agent card spec and MCP tool schema) is treated as a governance mechanism, not merely a convenience feature — agents undergo review before being publishable for production use.conf: highsupportsFighting Tool Sprawl: The Case for AI Tool Registries · p2 — Loom's use of a review-gated AWS Agent Registry for discovery is a concrete instance of the claim that a centralized registry is a precondition for securing agent/tool sprawl.
- implicitEven carefully designed identity/registry infrastructure carries early-stage rough edges (e.g. registry ARNs using only a random alphanumeric string, forcing wildcard IAM policies) that partially undermine the fine-grained access control the platform otherwise promises.conf: medium
Arguments
Enterprises evaluating agent platforms should treat identity propagation (not model capability or UI polish) as the load-bearing governance problem to solve first. strength: medium
Explicit premises:
- Identity propagation is described as 'where Loom addresses the hardest problem on that list' (of seven platform-engineering challenges).
- Downstream systems must expose only the data the originating user is permitted to access, which requires the full chain of tokens to preserve both user and agent identity.
Implicit premises:
- Without preserved end-to-end identity, an agent acting on a user's behalf could over-access data or systems beyond that user's actual permissions — a real security/compliance failure, not just a hygiene concern.
- The other six challenges (tagging, RBAC, blueprints, validation, sprawl, human review) are comparatively tractable with existing tooling patterns, while identity propagation required new protocol-level work (RFC 8693 token exchange).
Inferences:
- If identity propagation is the hardest and most novel piece, platforms that skip or fake it (e.g. by passing a single service-account credential through the whole chain) are the ones most likely to fail an enterprise security review, regardless of how polished their UI or deployment tooling is.
A reference implementation's usefulness as an enterprise governance blueprint is limited by both its own residual immaturity (demo scaffolding, wildcard ARNs) and by the ease with which a competent platform team could rebuild an equivalent system themselves. strength: medium
Explicit premises:
- The author explicitly notes Loom's 'role-based access model still carries visible demo scaffolding.'
- A Reddit commenter's assessment — the only substantive community reaction cited — states you could 'probably build your own version in a week.'
Implicit premises:
- The value of a reference platform is not the code itself (which is reproducible) but the design decisions embedded in it (the seven-challenge framework, the RFC 8693 approach to identity, the tag-driven access model) — value that survives even if teams don't literally adopt the codebase.
- AWS's own credibility and the alignment with its native services (Bedrock AgentCore, Secrets Manager, Agent Registry) create switching costs that make 'build your own in a week' less attractive than it sounds once integration work is counted.
Inferences:
- The real audience for Loom is less 'teams who will run Loom in production' and more 'teams who will copy its architecture' — making the article (and the underlying blog post) more valuable as a governance design reference than as a deployable product.
Narratives
- The origin story: Heeki Park, an AWS principal solutions architect, documented a Loom prototype on Medium in June before it graduated to an official AWS Labs project.
→ Implicitly supports the proposition that Loom's governance patterns emerged from real internal AWS practice (an individual architect's working solution) rather than being designed top-down as a marketing artifact — lending it grounded credibility as a reference design. - A Reddit thread asking whether anyone had deployed Loom yet drew no deployment reports two days after release, with one commenter offering the article's only substantive assessment.
→ Functions as a reality check against the vendor-blog framing — showing the piece the author cannot yet independently verify (real-world adoption) rather than merely restating AWS's own claims.
Questions addressed
- ✅ How can identity and permissions be preserved when an AI agent acts on a user's behalf through multiple hops (agent -> MCP server -> API)?
RFC 8693 token exchange plus AgentCore Identity, propagating on-behalf-of tokens at each hop, with downstream systems restricted to what the originating user is permitted to access. - ✅ How should platform teams prevent agent/tool/resource sprawl as agent deployments scale across an organization?
A catalog dashboard for administrators, mandatory tagging tied to group-based visibility, and integration with the AWS Agent Registry (with a pre-publication review process). - ✅ Should agent behavior be customized via runtime code generation or via configuration of a fixed, pre-vetted codebase?
Loom deliberately chooses configuration over runtime code generation, so code can be security-scanned once and reused, trading flexibility for auditability. - ⭕ Is Loom itself production-ready, and what does 'success' for a reference implementation like this actually look like — wide reuse of the code, or wide reuse of the design?
- ⭕ What is the actual adoption trajectory of Loom, and does the 'build your own in a week' critique undermine its value proposition?
Gaps
- incompleteThe article describes RFC 8693 token exchange and delegated actor chains at a conceptual level but never shows what happens on failure or partial-trust cases: what if an intermediate MCP server is compromised or misbehaves, what if a downstream API doesn't support scoped on-behalf-of tokens, or what audit/retention guarantees actually apply to the token exchange logs. This is the same class of unresolved question a companion InfoQ article (on the GuardDuty investigation agent) explicitly flagged and deferred to this Loom article by name — a deferral this article does not fully discharge, since it explains the identity-propagation mechanism without detailing the specific auth/audit/retention controls for any concrete downstream scenario.
Read next: Read AWS's own Loom documentation and the AWS Open Source Blog post directly for the specific audit-log retention, failure-mode handling, and revocation semantics of the RFC 8693 token exchange implementation. - incompleteNo adoption or outcome data is presented — no organizations are named as having deployed Loom, no metrics on how it performs against the seven challenges in practice, and the only community reaction is a single Reddit comment two days after release. The 'reference platform' framing is asserted, not evidenced.
Read next: Track future InfoQ or AWS coverage for case studies of organizations that adopted or forked Loom, or search for post-mortems on the AWS Labs GitHub repo (issues, forks, deployment reports). - incompleteThe article notes Loom's role-based access model 'still carries visible demo scaffolding' but doesn't specify what that scaffolding is or what a production-hardening checklist would include — leaving the reader unable to assess how much engineering work stands between the reference implementation and an actual production deployment.
Read next: Read the AWS Labs repository's own deployment guide and cleanup instructions (mentioned in the closing paragraph) for the concrete list of what's demo-only versus production-grade. - uninformedThe article doesn't compare Loom's tag-based, role x group access-control model against policy-as-code approaches (OPA/Cedar/Amazon Verified Permissions) already used elsewhere in AWS's own ecosystem for dynamic, context-aware authorization — leaving open whether Loom's model can express the kind of contextual conditions (data age, environment, multi-team approval) that static tag-based ABAC typically cannot.
Read next: Compare against AWS Cedar / Amazon Verified Permissions documentation and the corpus's existing coverage of policy-as-code governance architectures for cloud AI workloads.
Closes gaps elsewhere
- AWS Launches Amazon GuardDuty Investigation Agent to Automate Threat Triage · g3 — Partially closes it: explains the identity-propagation mechanism (RFC 8693 token exchange, on-behalf-of tokens per hop) that would govern which principal ran an investigation, but does not address the GuardDuty article's specific questions about 90-day telemetry retention in an agent's context window or transcript retention — those remain open (see this extraction's own first gap).
Related documents
- Why AI agents need a Context Lake
- Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI
- AWS Launches Amazon GuardDuty Investigation Agent to Automate Threat Triage
- An Evolutionary Architecture Pattern for Managing AI's Pace of Change
- Fighting Tool Sprawl: The Case for AI Tool Registries
- Article: Securing MCP in Production: Defense-in-Depth Beyond the Gateway
- Presentation: APIs for Agents: Rethinking API Programs in the MCP Era
- Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core
- The Interfaces Are Arriving
- The Production Gap: 5 Patterns for Building Long-Running AI Agents