Building Production-Ready AI Agents with Amazon Bedrock AgentCore: Runtime and Security Deep Dive

AI agents are no longer a research novelty; they're moving into production. But the moment you try to take an agent from "it works on my laptop" to "it's running for real users," you hit a familiar wall: the "ilities." Scalability. Reliability. Observability. Security. Every application has to solve these, and agentic applications are no different. Amazon Bedrock AgentCore was built specifically to handle this undifferentiated heavy lifting, so your team can focus on the agent behavior that actually differentiates your product.

 In this blog, we will share the key architectural concepts.

The Six Phases of Agent Development

Before diving into the architecture, it helps to think about the emotional arc of building an agentic system in six developer phases:

1. "Get it working": The relief when your Runtime and Gateway are connected and the agent initializes successfully.
2. "Do cool stuff": The excitement as the Code Interpreter and Browser tools let your agent actually interact with the world.
3. "Stink less": The frustration when your agent has no memory and keeps repeating itself, which Memory solves.
4. "What's it doing?": The confusion when you can't trace what decisions the agent is making, which Observability and Evaluation address.
5. "Oh no, bad guys": The panic when you realize your agent can be exploited, which Identity and Policy guard against.
6. "Ready for production": The satisfaction when everything comes together, and you're live.

AgentCore maps directly to each of these phases. Understanding which components address which phase makes the platform's architecture much easier to reason about.

AgentCore Runtime: Execution Without the Plumbing

Before you can deploy an agent, you need somewhere to run it, and that "somewhere" has historically meant provisioning infrastructure, managing containers, and worrying about session isolation yourself. Runtime is AgentCore's answer to the question: "Where does my agent actually run, and who manages it?"

It's Serverless, and That's the Point

AgentCore Runtime provisions and manages Firecracker microVMs. The critical model here is one-session-one-microVM isolation: each agent session gets a dedicated, ephemeral execution environment. This design prioritizes both performance and security. Sessions cannot bleed into each other, and the isolation boundary is enforced at the hardware-virtualization level via a Jailer barrier (seccomp, cgroup, chroot, net/pid/usr namespaces) backed by KVM.

The practical implication is that you don't control the size of the agent's execution environment directly. You control what the agent does, not the container it runs in.

Offload Heavy Computation

One of the most important design principles for AgentCore agents is to avoid the monolithic agent pattern. If your agent logic and heavy computation (data processing, model inference, etc.) all live inside the AgentCore Runtime container, you'll hit resource ceilings and get unpredictable behavior.

The correct pattern is an offloaded architecture where AgentCore Runtime acts as the manager, and heavy workloads are delegated via tool calls to AWS Batch or AWS Lambda workers. AgentCore Runtime handles orchestration, the workers handle computation, And results flow back through the tool return values.

Code Interpreter and Browser

There are two built-in tools that make agents substantially more powerful without custom integration:

• Code Interpreter executes code securely in sandbox environments across multiple languages (Python, JavaScript, TypeScript, and more). It follows the standard flow: the LLM selects the tool, a Code Interpreter Session spins up with its own filesystem and shell, telemetry flows to AgentCore Observability, and results return to the agent.
• Built-in Browser lets agents interact with the web and internal domains using secure headless browsers, compatible with popular browser automation libraries.

AgentCore Gateway: Security Architecture Hop by Hop

AgentCore Gateway is how agents access tools and external resources, and it's where most of the security architecture lives. The request flow is described as a series of “hops,” with each hop assigned a specific security responsibility.

Hop 1: Runtime Middleware

The agent's MCP server is wrapped with two critical middleware components:

• TrailingSlashMiddleware: fixes path mismatches between AgentCore's /mcp/ routing and target expectations.
• AuthCaptureMiddleware: captures the inbound JWT into an async-safe ContextVar for every request, avoiding shared-state bugs from module-level variables.

Local tools (direct HTTP to internal services) and proxied tools (auto-discovered from AgentCore Gateway at startup) are registered here, and gateway-prefixed tool names are cleaned up for the LLM.

Hop 2: Authorization Middleware

The AuthCaptureMiddleware decodes the Bearer token from the Authorization header. Notably, signature verification is intentionally skipped at this layer because Amazon Cognito and AgentCore upstream have already validated the signature. Re-verifying would require distributing public keys to every downstream service and adds latency with no security benefit.

Hop 3a: OAuth and Local Short Circuit

For tools that require OAuth (e.g., Jira, Salesforce), the agent calls a platform identity service to initiate the OAuth flow and store credentials for future use. The downstream agent then operates as the identity of the authenticated user.

Tools that don't need OAuth (internal services with IAM or JWT-based auth) short-circuit the Gateway entirely, reading the JWT directly from the ContextVar.

Hop 3b: Auth Factory for Outbound Requests

An _auth_httpx_factory injects the JWT into every outbound HTTP request automatically. It includes a fallback guard: it won't overwrite an Authorization header already set upstream. Auth becomes infrastructure; every outbound request gets JWT propagation without the tool implementation needing to think about it.

Hop 4: The Gateway Interceptor (Lambda)

This is a subtle but critical piece. The AgentCore Gateway does not propagate headers through to Lambda targets by default. A request interceptor Lambda bridges this boundary: it reads the Authorization header from the inbound gatewayRequest and injects it into the transformedGatewayRequest headers so the target Lambda can receive the caller's identity.

HTTP headers are case-insensitive by spec, so the interceptor correctly uses key.lower() == "authorization" rather than string matching.

Hop 5: Lambda Target

The Lambda target reads the JWT from context.client_context.custom["bedrockAgentCorePropagatedHeaders"], the mechanism by which the interceptor's transformed headers arrive. If no auth header is present, it returns a 401 immediately. Otherwise, it strips the Bearer prefix and passes the token to tool implementations.

Hop 6: Credential Exchange

At the final hop, the MCP tool function exchanges the platform JWT for a service-specific OAuth access token (e.g., a Jira OAuth token). The JWT itself never crosses the platform boundary into third-party services; only the exchanged access token does. A structured error response ({"error": "jira_not_connected"}) tells the LLM exactly what remediation action is needed when credentials haven't been provisioned.

Policy vs. Gateway Interceptors: Picking the Right Tool

AgentCore offers two distinct mechanisms for enforcing rules on agent behavior, and they're complementary rather than competing.

AgentCore Policy Interceptions uses Cedar (with natural language authoring support) to enforce high-level governance rules declaratively, for example, "no refunds over $500," or "this agent can only read, not write." They work natively with AgentCore Gateway and MCP, and are easy to author without writing code.

AgentCore Gateway Interceptors are Lambda functions that intercept specific API calls (InvokeTool, ListTools) and can modify requests and responses imperatively: token exchange, PII redaction, and custom header injection. They require writing and maintaining Lambda functions, but they can transform data in ways declarative policies cannot.

One capability worth flagging is Semantic Tool Selection in Gateway, where the agent searches across available tools to find the most contextually appropriate one. This raises an interesting governance question. Allowing agents to discover and invoke tools dynamically is powerful, but it also means your policy controls need to account for tools the agent might find and use without explicit pre-registration. Worth thinking through carefully before enabling in production.

When it's worth it: A research or orchestration agent that spans many domains (querying databases, calling external APIs, summarizing documents, invoking specialty models) benefits enormously from semantic selection. Cataloging every permissible tool combination in advance is impractical, and the value of the agent comes precisely from its ability to compose tools fluidly at runtime. If your governance layer does scoped authorization (the agent can only reach tools within a defined namespace or tagged set), semantic selection buys you adaptability without abandoning control.

When it isn't: A customer-facing support bot with a tightly scoped job has no business dynamically discovering tools at runtime. Every tool it can reach should be declared, reviewed, and audited. Semantic selection in that context is just scope creep with an API. You are trading a clear, auditable surface for a fuzzy one, and "the model thought this tool was contextually appropriate" is not a satisfying answer when something goes wrong in a regulated environment.

Putting It Together: The Production AI Gateway

The full production pattern combines all of these components: a Cognito User Pool authenticates users; the AgentCore Runtime hosts an MCP Server; the AI Gateway (AgentCore Gateway) mediates all tool access with token validation, policy enforcement, and token vaulting; internal MCP tools (Enterprise Knowledge Agent, identity service, enterprise data) and proxied third-party tools (Notion, GitHub, etc.) are reachable through standardized interfaces; and an Agent Skills Registry tracks available capabilities.

The result is an architecture that separates agent logic from infrastructure concerns, which is exactly what AgentCore was designed to achieve.

Conclusion

Amazon Bedrock AgentCore provides the infrastructure layer that production AI agents require: isolated execution environments, a multi-hop security architecture that propagates identity across service boundaries, composable tool access through a managed Gateway, and policy controls that can be expressed declaratively or implemented imperatively.

The hop-by-hop security model is particularly worth internalizing. Authorizations should be threaded through every boundary from the inbound JWT to the final OAuth credential exchange, rather than being an afterthought. That's what "ready for production" looks like for agentic systems.

How Caylent Can Help

Bringing these patterns into production requires more than just understanding the architecture, it requires translating them into secure, scalable systems that fit real enterprise constraints. Caylent helps organizations design and operationalize agentic platforms on AWS, from building isolated, production-grade runtimes on services like Amazon Bedrock AgentCore to implementing end-to-end security models that preserve identity across every hop. Our teams work with engineering and platform groups to define the right tool orchestration patterns, enforce governance with policy and interceptor strategies, and offload compute-heavy workloads into resilient AWS-native services. Get in touch with us today to get started.