Building an Agent Control Plane on AWS
· 13 min read
Gartner expects the average Fortune 500 company to run more than 150,000 AI agents by 2028. In 2025, the same companies ran fewer than 15. Agents and AI models have been moving faster than the controls around them. With so many agents moving to production, we need a well-defined platform to list which agents exist, what permissions they have, and what they do.
Platform teams have been shifting to accommodate exactly these problems with agent control plane implementations. Agents became the next type of workload requiring deterministic policy enforcement, sitting outside the agent’s reasoning loop.
The control plane registers them, issues their identities, brokers their credentials, authorizes each tool call, records everything, and monitors how they operate.
AWS has all the primitives we need to build a robust agent-first control plane. This post walks through the architecture.
The shape of the control plane
An agent control plane is responsible for:
- Lifecycle. Register your agents, version them, offer golden templates for common use cases and starting points, promote them, and retire them.
- Identity. Give each agent its own well-scoped identity with least privilege and short-lived credentials.
- Tool governance. Put one governed path between agents and the tools, APIs, and data they call.
- Policy enforcement. Authorize every action against explicit rules.
- Guardrails and secure execution. Monitor, inspect, and validate content in and out of agents. Run agent code in isolated and dedicated sandboxes.
- Observability and audit. Trace every agent session and make operational, behavioral, and reasoning logs available.
- Posture and detection. Inventory all the agents that exist and operate in your estate. Automatically detect misuse, flag issues, and alert and (auto)remediate.
Amazon Bedrock AgentCore covers many of these responsibilities with its component services: Runtime, Identity, Gateway, Policy, Memory, Evaluations, Code Interpreter, Browser, Optimization, and Observability.
The story is complemented by other surrounding AWS services: Amazon S3 for storage, AWS IAM for permissions, Amazon Bedrock for model access, AWS CloudTrail, AWS X-Ray, and Amazon CloudWatch for overall observability and governance, AWS Security Hub AI inventory and Amazon GuardDuty AI Protection for watching and protecting your running agents. The new Lambda MicroVMs offering can add another self-managed tier useful for code development environments and AI code execution sandboxes. A new class of managed agents, which AWS calls frontier agents, can help operate, debug, and secure the platform itself.
Diagram 1 shows the layers and the AWS services aligned:
Diagram 1: The agent control plane on AWS, with frontier agents operating it.
Lifecycle layer
AgentCore Runtime hosts the agents themselves. It is framework-agnostic, supporting any framework or model you want to bring along, such as LangGraph, CrewAI, Strands, or OpenAI Agents SDK, and each deployment gets versioned endpoints. This allows you to promote or roll back an agent safely.
The AWS Agent Registry adds the catalog listing agents, their skills, and their tools. Registration becomes the entry ticket to the platform in order to get an identity and get deployed.
To ensure that agents perform the way they should, AgentCore Evaluations offer an automatic method. Batch evaluations replay curated sessions in CI, so a prompt or model change that degrades the overall system fails the build. Online evaluations sample production traces continuously and score them with built-in evaluators for goal success, tool selection accuracy, faithfulness, and harmfulness, plus custom evaluators for your own criteria. Scores land in CloudWatch, where alarms can trigger a rollback. A/B testing splits live traffic when you want evidence before a full promotion.
New agents start with narrow tool access and a human approval step. Sustained evaluation scores widen the permissions and provide confidence to move towards autonomous agent scenarios.
Identity and least privilege
The control plane is responsible to give agents their own identity:
AgentCore Identity maintains a directory of workload identities. Each agent gets its own entry with an ARN. Alongside the directory sits a token vault, encrypted with KMS keys you can own, which stores the OAuth tokens, client credentials, and API keys agents need for external systems. Agents never hold these secrets, but they request them at run time. The vault provides the required credentials only against proof of the appropriate workload identity.
The vault can reference secrets you already manage in AWS Secrets Manager, keeping rotation in one place.
Inbound, agents and gateways authenticate callers with IAM SigV4 or with JWTs from any OIDC provider: Cognito, Okta, or Entra ID.
Outbound is where least privilege gets enforced. The On-Behalf-Of token exchange takes the inbound user token and exchanges it for a downstream token scoped to the specific resource, short-lived, and carrying both the agent’s identity and the original caller’s. Every hop downstream can authorize against both.
Two identities matter for every action: the agent’s own, and the person or system it acts for.
For AWS resources, agents assume ordinary IAM roles, so existing policy tooling applies. For external SaaS, IAM outbound identity federation lets a workload request a short-lived signed JWT from STS that asserts its AWS identity to the external service.
Diagram 2 traces the full flow from user sign-in to a scoped downstream call:
Diagram 2: Agent identity and credential flow through AgentCore Identity.
Tool governance
Tools and MCP servers offer options for agents to interact with other systems. The control plane routes everything through AgentCore Gateway.
The Gateway exposes one MCP endpoint and translates whatever sits behind it into MCP tools: Lambda functions, OpenAPI and Smithy specs, API Gateway stages, existing MCP servers, plain HTTP endpoints, and other agents.
Semantic tool selection keeps the catalog usable at scale: an agent facing thousands of registered tools receives only the handful relevant to its current request, which also keeps tool descriptions from flooding its context window.
Enforcement happens in the request path. AgentCore Policy attaches a policy engine to the Gateway. Every tool call is intercepted and evaluated before it reaches the target, outside the agent’s code and regardless of which framework or model produced it.
Temporal policies let you define stateful rules that determine authorization to AgentCore Gateway targets by evaluating the current request in the context of prior events in an agent’s trajectory.
Bedrock Guardrails can run inside policy evaluation, screening tool inputs and outputs for prompt injection and sensitive data at a layer the agent cannot reason around. Lambda interceptors handle custom validation and transformation. AWS WAF attaches to the Gateway for network-level filtering.
Coding assistants also belong behind the same gateway. Claude Code authenticates through Amazon Cognito with OAuth, and the Gateway fronts the actual MCP servers under its own IAM role with semantic search picking the tools.
The platform team owns the catalog, the credentials, and the logs. For AWS access itself, the Agent Toolkit for AWS packages the managed AWS MCP Server, which exposes AWS APIs and documentation behind SigV4 auth. Its requests carry dedicated IAM condition keys (aws:CalledViaAWSMCP), so you can write policies that treat agent-initiated AWS calls differently from human ones, such as restricting them to read-only. Everything is logged in AWS CloudTrail.
Diagram 3: Tool governance and policy enforcement at the AgentCore Gateway.
Guardrails and secure execution
Security principles for agentic AI:
- Enforcement must be deterministic
- Live in infrastructure
- And sit outside the agent’s reasoning loop.
Bedrock Guardrails can be associated with agents and offer the content control layer, and it is model-independent. Its policy types cover harmful content filters, prompt-attack detection, denied topics, PII blocking or masking, contextual grounding, and Automated Reasoning checks, which validate outputs against formal rules rather than a classifier’s judgment.
The ApplyGuardrail API runs these checks standalone, so the same guardrail configuration covers models Bedrock hosts, models you self-host, and third-party APIs.
Execution isolation comes in different tiers, powered by Firecracker microVMs. AgentCore Runtime gives each agent session a dedicated microVM, terminated and sanitized when the session ends.
AgentCore Code Interpreter and Browser do the same for running generated code and browsing the web, as managed sandboxes with per-session isolation. Lambda MicroVMs is the tier below: a raw sandbox primitive you orchestrate yourself. Each MicroVM is a dedicated Firecracker instance for one user, session, or job, sessions up to eight hours, suspend and resume with state intact, and its own HTTPS endpoint. Choose Code Interpreter when an agent needs a managed code-execution tool. Choose Lambda MicroVMs when you are building the execution layer yourself: custom runtimes and packages, coding-assistant sessions, or sandboxes for AI-generated code that runs outside any AgentCore agent.
Runtime isolation must be paired with VPC connectivity with explicit egress controls, private endpoints so agent traffic never crosses the public internet, and KMS keys. Treat the sandbox as one boundary in a stack.
Observability, audit, and detection
Agents emit OpenTelemetry spans, either through the ADOT SDK or through frameworks like Strands and LangGraph that carry instrumentation already. CloudWatch GenAI Observability organizes them into a session, trace, and span hierarchy with agent-level views of token usage, latency, and error rates, and it works across accounts, which matters once agents span an AWS organization.
The audit trail needs data from the whole setup: Gateway data events on, Bedrock invocation logging on, policy decision logs on, OTEL traces flowing.
Detection then can be performed effectively on top of these logs, traces, and events:
- GuardDuty AI Protection analyzes CloudTrail management and data events from AI services and raises findings for anomalous model invocations, cost harvesting with stolen credentials, and prompt injection attempts surfaced through its Guardrails integration.
- Security Hub AI inventory addresses the discoverability of agentic systems running in your estate. It discovers managed AI resources (Bedrock, AgentCore, SageMaker) through AWS Config, finds self-hosted models and agents on EC2, ECS, and EKS through Inspector’s SBOM analysis, and spots external AI API usage through GuardDuty’s DNS telemetry. Each discovered asset is mapped to its compute, IAM roles, and data stores and correlated with findings. This is the answer to shadow agents: the inventory can cover what teams built outside the platform, whether or not anyone registered it.
- Evaluations feed the same telemetry back into lifecycle decisions. Online evaluation samples production traces, scores them, and publishes to CloudWatch, so you can create automation flows accordingly to trigger notifications, rollbacks, or remediation.
Diagram 4: Telemetry, audit, and the detection loop.
Managed agents that help you operate
The control plane is itself infrastructure that needs review, monitoring, and cost control. AWS’s frontier agents are managed agents that can greatly help you there.
AWS Security Agent reviews designs, threat-models them with STRIDE, scans pull requests against your security policies, and runs autonomous penetration tests against deployed applications. Pointed at an agent platform, that means pentesting the Gateway endpoints and the agent-built applications behind them, and reviewing the pull requests that add new tools to the catalog. Its Claude Code plugin puts those reviews inside the same coding assistants the platform governs.
AWS DevOps Agent runs continuous incident triage and root-cause analysis across telemetry, code, and deployment data. It consumes CloudWatch alongside third-party observability stacks and extends over MCP, so the AgentCore telemetry described above is within its reach. When there are issues with agents in production, the first responder can be an agent with the full trace history available.
AWS FinOps Agent investigates cost anomalies to root cause, runs scheduled cost workflows, and posts findings to Slack or opens Jira tickets. Agent platforms earn their own FinOps attention: runtime hours, token consumption, and per-tool costs move with model behavior.
What organizations are actually building
Uber’s platform, described in its 2026 engineering posts, anchors agent identity in SPIRE-issued workload credentials, issues short-lived, audience-scoped tokens that carry the full attested actor chain, and routes tool traffic through an MCP gateway that enforces access policy and redacts PII. It supports more than 1,500 monthly active agents running 60,000 executions a week.
Block’s security team, writing about its Goose agent, argued for allowlists of vetted MCP servers and deterministic access controls over reliance on model judgment.
An MCP-gateway category formed around the same needs: IBM’s ContextForge, Docker’s MCP Gateway, Kong’s MCP Registry, Cloudflare’s MCP Server Portals, the Linux Foundation’s agentgateway, and AWS’s open-source MCP Gateway and Registry.
Registry, identity, governed gateway, policy, guardrails, telemetry, evaluations. Building on AWS primitives means buying that consensus architecture as managed parts instead of playing catch-up on building a platform across all these layers.
Loom: an opinionated implementation over the primitives
A platform is a set of decisions and connections of all the different parts that we discussed.
Such an assembly of the different parts is Loom for AWS. It is a platform implementation for building, deploying, and operating agents on AgentCore Runtime and Strands Agents. Its stated tenets are simple, opinionated, and enterprise-grade.
The architecture is three layers: a FastAPI control plane API that wraps boto3 and restricts deployments to approved parameters, a React management UI behind Cognito with navigation scoped per persona, and backend services that manage agents, memory, MCP servers, and agent-to-agent integrations. It runs on SQLite locally and PostgreSQL on RDS in production, and deploys to ECS Fargate behind an Application Load Balancer.
Access control runs in two dimensions, role-based personas crossed with attribute-based resource groups, so a builder sees only the agents, memory stores, and MCP servers tagged to their group. Tagging is mandatory: every resource carries loom:application, loom:group, and loom:owner, plus whatever custom tag profiles the platform defines, so cost attribution and inventory work from the first deployment.
Diagram 5: Loom’s paved path, an opinionated control plane API over the AWS primitives.
Loom combines some of the primitives in this post composing them into a working platform, and it supports three modes of consumption: run it as shipped, fork it and adapt, or read it as a pattern and copy the decisions into a control plane API you own.
Frequently asked questions
What is an agent control plane?
The layer that manages agents as a governed workload: it registers and versions them, issues their identities, brokers their credentials, authorizes every tool call against explicit policy, isolates their execution, and records and monitors everything they do. Enforcement is deterministic and sits outside the agent’s reasoning loop.
Which AWS services make up the control plane?
Amazon Bedrock AgentCore carries most of it: Runtime, Identity, Gateway, Policy, Memory, Evaluations, Code Interpreter, Browser, and Observability. Around it sit the AWS Agent Registry, IAM and STS, Bedrock Guardrails, CloudTrail, X-Ray, CloudWatch GenAI Observability, Security Hub AI inventory, GuardDuty AI Protection, and Lambda MicroVMs for self-managed sandboxes.
How do agents get identities and credentials?
Each agent gets a workload identity with an ARN in AgentCore Identity. A KMS-encrypted token vault holds the OAuth tokens and API keys; agents request credentials at run time against proof of identity and never hold secrets. Outbound, the On-Behalf-Of token exchange issues short-lived downstream tokens carrying both the agent’s identity and the original caller’s, so every hop can authorize against both.
How are tool calls governed?
Everything routes through AgentCore Gateway, which exposes one MCP endpoint and translates Lambda functions, API specs, MCP servers, and HTTP endpoints into tools. AgentCore Policy intercepts and evaluates every call in the request path, temporal policies factor in the agent’s prior trajectory, and Bedrock Guardrails screen inputs and outputs at a layer the agent cannot reason around.
What is Loom for AWS?
An opinionated platform implementation over these primitives for building, deploying, and operating agents on AgentCore Runtime and Strands Agents: a FastAPI control plane API, a React management UI behind Cognito, and mandatory tagging for cost attribution. Run it as shipped, fork it, or copy its decisions into a control plane you own.