As organizations move to adopt agentic capabilities to accelerate their business objectives, they are challenged with enabling those capabilities within a security and governance framework that complies with enterprise requirements. Some organizations lean into the promise of serverless capabilities, as those fully managed services enable them to build fast and deliver customer value quickly. Amazon Bedrock AgentCore is a portfolio of services for building, deploying, and operating AI agents in production at scale.
While AWS provides the building blocks, organizations must still build agent platforms that weave together agent capabilities and deploy them with guardrails and least privilege security.
To address these challenges, we’re releasing Loom for AWS (Loom), an enterprise-grade platform for building agents with AWS Strands Agents and deploying and operating them on Amazon Bedrock AgentCore Runtime. This post outlines some key capabilities and is targeted for teams that are looking to securely scale agent deployments.
The project is available in AWS Labs at: https://github.com/awslabs/loom/.
Loom provides a unified management UI and backend API with identity provider integration, scope-based authorization, multi-persona navigation, and full lifecycle management for agents, memory, MCP servers, and A2A integrations. It integrates with AWS Agent Registry for discovery and governance and tracks compute and model usage for cost transparency.
When building an agent, Loom brings together all the required, pre-validated configurations. Agents can be deployed as a low-code option onto AgentCore Runtime with a pre-written but configurable Python agent in AWS Strands or directly as a no-code option via AgentCore’s managed harness. The managed harness in AgentCore makes it simple to define and deploy an agent using configuration. Loom layers on top of both, offering agent builders customizability and simplicity of deployment.
Loom is built with three tenets in mind.
Simple. Loom is an agent platform that gives builders the ability to easily create AI agent applications, integrate data sources, and connect to other agents, all with security and governance baked in.
Opinionated. Loom is an opinionated implementation of an agent builder platform that implements agents using the Strands Agents SDK under the hood and leverages AWS managed services like Bedrock for model inference and AgentCore for agent infrastructure, while abstracting the implementation details from the end-user. Thus, Loom is intended for platform engineering teams who are looking to build a greenfield application using fully managed AWS services.
Enterprise-grade. Loom implements enterprise best practices by using a paved path approach, i.e., blueprints with best practices baked-in, to packaging and deploying agentic applications, applying least privilege security, abstracting configuration parameters, and applying strict guardrails on deployments.
The following screenshot shows Loom’s catalog view, the administrator’s landing page and dashboard of agents, memory resources, MCP servers, and A2A agents that are configured in Loom.
In the rest of the post, I outline seven common challenges and how Loom addresses them.
Resource tagging in AWS is a standard practice for both cost attribution and applying conditional governance policies. While configuration management databases can track metadata about resource deployments, tags provide simple in-console visibility to relevant metadata, e.g., application identifier, group association, owner id, etc.
Challenge #1. Enforcing consistent application of tags on deployed resources can be challenging. Paved path blueprints are one way customers enforce tagging on deployed resources.
Loom requires three tags and automatically applies them to every resource that it deploys. These include loom:application, loom:group, and loom:owner. It also allows for creating additional custom tags, as organizations often have their own set of required tags.
Loom then combines a set of tags as a tag profile. The three required tags are always included in a tag profile. An administrator can optionally select additional custom tags to include. If additional custom tags are selected, a value is required for that tag profile. For example, suppose I wanted to also include a tag that includes a cost center id. I could create a custom tag loom:cost.center and set a value of 4015 in the tag profile. When Loom creates any resource, a tag profile is a configuration requirement and is used whenever a new resource is created.
The following screenshot shows how tag profiles are constructed. The first shows the base tag profile with three platform required tags and two optional tags. The latter three boxes are example tag profiles with values for each of those required and optional tags.
Granting access based on role or persona is a standard practice for using any type of modern application. Further refining access based on attributes of a particular user profile is a commonly desired capability of most software as a service products.
Challenge #2. Implementing fine-grained role-based and attribute-based controls can be challenging. Unless that is baked into the product at inception, it can be quite challenging to retrofit those security requirements, especially as the user base scales.
Loom uses a 2-dimensional approach for access control: 1/ role type, 2/ group tags. The role type defines the core capabilities and view that is presented, while group tags define which resources are accessible.
For role-based access control (RBAC), Loom has two roles: 1/ administrator, 2/ end user. Administrators see the administrator view upon login, while end users see the chat interface.
For administrators, Loom has two administrator types. The super administrator has full access to the entire system, while the demo administrator has access to most aspects but is restricted in some ways, e.g., can’t see the admin dashboard which has usage metrics, can’t modify resources outside its own demo group.
For users, Loom has administrators, a test user, and a number of demo users. Administrators see the administrator interface, have views into different pages, and can see all resources for pages to which they have access. End users see the chat interface, can only see agents that belong to the same group, and can only see their own conversation history.
For attribute-based access control (ABAC), Loom uses the group tag to define what resources that particular user is allowed to see.
The following chart depicts each of the groups and their associated permissions via scopes.
This approach ensures that users have just the right amount of access to only the subset of resources that they should see.
Conducting agent deployments with paved path blueprints coupled with governance controls are common among enterprises. Platform engineering teams rigorously test and validate those blueprints to ensure that resources are deployed with least privilege configurations and are integrated with cost management and reporting mechanisms.
Challenge #3. Implementing blueprints for new services and patterns are non-trivial and could require months of research, implementation, and validation.
Loom implements its own control plane API using FastAPI for prescriptively managing agent deployments. It is an abstraction layer on top of the boto3 SDK and implements only the parameters allowed by the system.
This approach collapses the deployment process into an opinionated control plane API and handles the functions of a traditional deployment pipeline.
Building software involves a lot of moving parts, especially with the latest advancements in agentic coding tools.
Challenge #4. Deploying software requires rigorous testing, validation, and security scanning before agent deployments can occur. This is all the more true of AI-generated code.
Loom builds and deploys agents using Strands Agents and uses a pre-written agent for deployments into AgentCore Runtime. In other words, no code is generated at runtime and deployed into any environment. That would be untrusted code and would need to operate in a secure, isolated compute environment.
The following diagram depicts where configurations are injected during the agent deployment process.
OAuth2 configurations are pre-defined by the security administrator. In scenarios where both a client id and client secret are required for machine-to-machine auth, only the security administrator is privy to that information. Furthermore, secrets and credentials are not stored directly in Loom. Those are all externalized in AWS Secrets Manager and pulled in only when required. When deployed, inbound and outbound auth is managed using AgentCore Identity.
This low-code approach allows for platform teams to bake a pre-written agent with enterprise customizations, like enterprise logging requirements, and scan it once for deployment, as the code does not change from deployment to deployment. Only configuration is changed, and those configurations are managed by the control plane API.
Alternatively, if no customizations are required, the no-code approach with managed harness for AgentCore can be used. The same approach for deploying agents has been applied to harness with the deployment configurations common but simplified in the backend deployment.
As agents become more capable and take actions on behalf of end users, agent systems need to ensure that permissions are scoped to the user and propagate information that an agent is involved in the request chain.
Challenge #5. Managing identity propagation through delegated actor chains is a hard problem to solve. Mapping scopes from hop-to-hop is doubly hard, as disparate identity systems may not have consistent scope nomenclature nor scope semantics.
Loom implements the full authorization code flow when users interact with both the frontend and backend. AgentCore Identity also supports the RFC 8693 token exchange process, which enables both the end user and agent identity to be included in downstream access tokens, while also maintaining the delegation chain. Loom implements and visualizes the full token exchange flow.
The following screenshot shows an agent invocation, which hops from agent in AgentCore Runtime to MCP server in AgentCore Runtime to REST API endpoint in Amazon API Gateway. Each of those hops uses a different access token for authorization, using the on-behalf-of token exchange process.
This ensures that chained agentic requests maintain the originating user’s identity and permissions. This way, downstream actors maintain a least privilege posture, exposing only the data and resources that the originating user is permitted to access.
As adoption of agentic capabilities grows, so does the sprawl of agentic resources, just as we saw in the proliferation of microservices. Traditionally, developer portals and service meshes have acted as discovery mechanisms for cataloging resources. Registries are acting as the central point of collating and exposing information about available and approved agentic resources.
Challenge #6. Managing the proliferation of agents, tools, and skills is a growing challenge as organizations continue to explore agentic capabilities.
Loom integrates with AWS Agent Registry, currently in public preview, for managing agent and tool records, complying with the A2A agent card specification and the MCP tool schema specification. It includes information about agent and MCP server endpoints, authorization, and capabilities. It also applies a governance process, ensuring that agents undergo a review process by some agentic review board before they can be published and made available for production usage.
This helps wrangle the agentic sprawl across the organization, giving teams visibility to what is approved and allowed for usage. It also allows review teams to act as a gate to ensure that agentic adoption is governed and secure.
As agents grow more advanced in capability and access more data systems, organizations should enable these systems in a controlled and incremental manner. Human-in-the-loop feedback can be used in early prototyping to verify that the agentic system is acting as intended builds confidence as production usage ramps and in production when allowing agents to take sensitive actions.
Challenge #7. Requiring human-in-the-loop review before taking sensitive actions is critical, as teams are wary of allowing non-deterministic systems to access and even act on systems that store business or operational data.
Loom implements three patterns of human-in-the-loop feedback, using the underlying Strands Agents hook framework and MCP elicitations to introduce human approval before invoking downstream tools. It uses hooks and interrupts in the Strands Agents framework and native MCP elicitations as defined by the MCP specification and implemented in the MCP SDK.
This ensures that sensitive actions are reviewed and approved by appropriate human users before taking said actions.
Loom is an open source project and your feedback and contributions are welcomed! You can find more details for contributing to the code repository.
Loom for AWS is a simple, opinionated, enterprise-grade agent platform. It aims to serve as a concrete example on how organizations might build their own agent platforms.
You can view the source code at https://github.com/awslabs/loom/. The repository includes additional overview documentation, the specifications used to build it, and a deployment guide to test it out yourself. The deployment guide includes information on how to clean up the resources after completing your testing and evaluation.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。