Most production AI agents are a model, a prompt and a bag of API keys wired together in application code, with no single place where identity is checked, tool calls are authorised or actions are logged. This guide sets out a reference architecture for the agent runtime: the components between a user's request and an agent's action, the token flows that connect them, and the trust boundaries where controls belong. It draws on the Model Context Protocol authorization specification and security best practices, OAuth 2.0 Token Exchange (RFC 8693), OWASP LLM06 Excessive Agency, and the component models of two cloud agent platforms, AWS Bedrock AgentCore and Microsoft Entra Agent ID. It is for platform engineers and security architects building or approving agent platforms. For the wider AI stack (data, models, applications), see the AI Security Architecture Reference Guide; this page goes deeper on the runtime only.
Key takeaways
- Put a gateway between the agent and every tool. A tool gateway with a deterministic policy check is the one place you can authorise, rate-limit and log every action, whatever the model decides.
- Agents need their own identity and a delegation record. RFC 8693 distinguishes impersonation from delegation; a delegated token that names both the user and the agent keeps the audit trail honest.
- Never pass tokens through. The MCP specification forbids servers from accepting tokens not issued for them and from forwarding a client's token downstream; exchange it for a new, narrower one instead.
- Isolate what runs code or browses. Code execution and browser tools run in ephemeral sandboxes with no ambient credentials and an egress proxy that blocks private ranges, including cloud metadata at 169.254.0.0/16.
- Telemetry is a component, not an afterthought. Every model call, tool call, policy decision and approval should emit one correlated trace, so an incident can be rebuilt end to end.
The runtime components
Cloud agent platforms now ship these components as separate services: AWS Bedrock AgentCore, for example, lists a Runtime with session isolation, Memory, a Gateway that turns APIs and functions into MCP tools, Identity that works with existing identity providers, a Code Interpreter sandbox, a Browser, OpenTelemetry-based Observability, and a Policy service that intercepts tool calls through the Gateway before execution. Whether you buy or build, the same logical components appear.
| Component | Job | Security property it must provide |
|---|---|---|
| Agent registry | Catalogue of agents, owners, tools and permitted MCP servers | Nothing runs unless registered; every agent has an owner |
| Agent runtime (orchestrator) | Runs the agent loop: plan, call model, call tools, repeat | Session isolation per user and task; no long-lived secrets in the process |
| Model gateway | Routes model calls, applies input and output guardrails | Prompt injection screening, output filtering, data loss checks, cost limits |
| Identity and token service | Issues the agent's identity, exchanges user tokens for narrowed delegated tokens | Short-lived, audience-bound tokens that record user and agent |
| Credential vault | Holds third-party secrets the agent cannot avoid | Secrets injected at the gateway, never shown to the model |
| Tool gateway (MCP gateway) | Single entry point for tools and MCP servers | Authenticates the agent, enforces policy, validates audience, logs every call |
| Policy decision point | Evaluates allow or deny for each tool call | Deterministic rules on agent, user, tool, parameters and data scope |
| Approval service | Routes high-impact actions to a human | Approver identity and decision recorded; time-outs fail closed |
| Sandboxes | Code execution and browsing | Ephemeral, no ambient credentials, restricted file system and egress |
| Memory store | Short and long-term context | Scoped per user and tenant; writes validated; retention set |
| Egress proxy | Controls outbound network access | Destination allowlist; blocks private and link-local ranges |
| Telemetry pipeline | Traces, logs and metrics | Correlated trace ID from request to action; tamper-evident storage |
| Kill switch | Suspends agents and revokes their credentials | Works per agent, per tool and fleet-wide in under a minute |
Request flow: from user to action
- User authenticates to the agent application through the organisation's IdP and receives a token for that application.
- The runtime starts an isolated session for this user and task. MCP's guidance is that sessions must not be used for authentication, and that session state should be keyed to the user, for example as user_id:session_id.
- The agent obtains its own token from the token service. For delegated work it presents the user's token as the subject_token and its own credential as the actor_token (RFC 8693), and receives a short-lived token whose act claim names the agent.
- Model calls go through the model gateway, which screens retrieved content and tool results as well as the user prompt, because indirect prompt injection arrives through data.
- Each tool call goes to the tool gateway, which authenticates the agent, asks the policy decision point, and either forwards, denies or sends the call for approval.
- The gateway calls the tool with a new token for that tool's audience, obtained by token exchange or from the vault. It never forwards the token it received.
- Results return through the gateway, where they are logged and can be screened before re-entering the model context.
- Every step emits a span with the same trace ID, agent identity, user identity and policy decision.
Identity and token flows
Microsoft Entra Agent ID describes the two access patterns any runtime must support: autonomous access, where the agent uses rights granted to its own agent identity, and delegated access, where it acts on behalf of a user with rights the user controls. RFC 8693 gives the protocol vocabulary: impersonation (the agent becomes indistinguishable from the user) versus delegation (the agent keeps its identity and the token names both). For access control, RFC 8693 says only the top-level claims and the current actor should be considered; earlier actors in nested act claims are informational.
| Pattern | Token | Use when | Risk to manage |
|---|---|---|---|
| Autonomous | Agent identity token, client credentials or federated workload identity | Scheduled or event-driven agents with no user in the loop | Standing privilege; keep scopes narrow and review regularly |
| Delegation | Exchanged token with subject (user) and act (agent) | Agent acting for a user on business systems | Scope creep; the token should carry the intersection of user and agent rights |
| Impersonation | Exchanged token with subject only | Legacy systems that cannot read an act claim | Audit trail loses the agent; restrict to read-only or low impact |
| Static API key | Long-lived secret | Third-party APIs with no OAuth | Theft and reuse; hold in the vault, inject at the gateway, rotate |
For MCP servers specifically, the authorization specification requires clients to send an RFC 8707 resource parameter naming the server, requires servers to validate that tokens were issued for them, and forbids passthrough. Its security best practices add progressive scopes: start with a minimal scope set, elevate through targeted WWW-Authenticate scope challenges, and avoid wildcard scopes such as files:* or admin:*. See the OAuth Token Exchange and Delegation Guide and the MCP Authorisation Specification Guide.
Trust boundaries and where controls sit
| Boundary | Threat | Control at the boundary | Maps to |
|---|---|---|---|
| User to agent application | Direct prompt injection, account takeover | IdP authentication, input screening, rate limits | LLM01 |
| Retrieved data to model context | Indirect prompt injection in documents, email, web pages, tool results | Content screening, provenance tags, treating data as data | LLM01; ASI01 Agent Goal Hijack |
| Agent to tool gateway | Excessive functionality and permissions | Per-agent tool allowlist, parameter policy, approvals | LLM06; ASI02 Tool Misuse and Exploitation |
| Gateway to downstream API | Token passthrough, confused deputy | Token exchange, audience validation, per-client consent for proxies | ASI03 Identity and Privilege Abuse |
| Agent to sandbox | Unexpected code execution, credential theft from metadata services | Ephemeral sandbox, no credentials, egress proxy blocking 169.254.0.0/16 | ASI05 Unexpected Code Execution (RCE) |
| Agent to memory | Memory and context poisoning, cross-user leakage | Per-user and per-tenant scoping, write validation, expiry | ASI06 Memory & Context Poisoning |
| Agent to agent | Spoofed or manipulated peer messages | Mutual authentication, signed messages, per-hop authorisation | ASI07 Insecure Inter-Agent Communication |
| Runtime to internet | Data exfiltration through rendered links or images | Egress allowlist, URL validation in output rendering | LLM02 |
The ForcedLeak Salesforce Agentforce case shows two of these boundaries failing together: instructions hidden in a public Web-to-Lead form were followed by the agent, and CRM data left through an image URL to a domain that was still on the content security allowlist but had expired and been re-registered. Salesforce's fix enforced Trusted URLs for agent output. See the Agent Egress Control and Network Isolation Guide.
Policy, approvals and containment
- Deterministic policy, not model judgement: AWS describes AgentCore Policy as deterministic rules that intercept tool calls through the Gateway before execution, written in a Cedar-compatible language. Whatever product you use, the decision must not depend on the model agreeing. See the Policy-as-Code for Authorisation Guide.
- Policy inputs: agent identity, delegating user, tool and operation, parameter values (amount, recipient, record count), data classification and time.
- Approval gates: payments, deletions, external messages, permission changes and production changes go to a human, with the approver recorded and a time-out that denies. See the AI Agent Action Approvals and Spending Limits Guide.
- Local MCP servers: MCP requires clients offering one-click local server setup to show the exact command before running it and to get explicit consent; run local servers sandboxed with minimal privileges. See the MCP Gateway and MCP Server Governance Guide.
- Kill switch: suspend at the gateway (fastest), revoke tokens at the token service, and disable the registry entry. See the AI Agent Kill Switch and Containment Guide.
Decision guidance
| Decision | Options | Guidance |
|---|---|---|
| Managed platform or self-built runtime | Cloud agent platform; open-source framework on your own infrastructure | Managed platforms give isolation, identity and policy components quickly; self-built gives control but you must supply every component in the table yourself |
| Gateway placement | Central shared gateway; sidecar per agent | Central for consistent policy and one audit point; sidecar where latency or tenancy isolation matters |
| Agent identity source | IdP agent identities; workload identity (SPIFFE, cloud roles) | IdP identities where agents access SaaS and user data; workload identity where agents call internal services. Many estates need both, linked in the registry |
| Delegation | Delegation with act claim; impersonation | Delegation by default; impersonation only for legacy targets, read-only |
| Small team | One gateway, IdP, vault, SIEM | Start with these four; add a separate policy engine and approval service when agents write to business systems |
How to implement
- Inventory and register existing agents, their tools and credentials. Block unregistered agents from the gateway once the registry is complete.
- Stand up the tool gateway in log-only mode and route one agent's tool calls through it. Compare what the agent can call with what it does call.
- Give that agent its own identity and move its secrets into the vault, injected by the gateway.
- Enable policy in enforce mode for read operations first, then writes, with approvals for high-impact actions.
- Add sandboxes and egress control for code and browser tools.
- Test the kill switch and the incident timeline rebuild before onboarding further agents.
- Roll back by switching the gateway policy to log-only, not by bypassing the gateway, so telemetry continues.
Detection and measurement
- Telemetry: AgentCore Observability uses OpenTelemetry-compatible telemetry; whichever stack you use, capture model calls, tool calls, policy decisions, approvals and token exchanges under one trace ID. See the AI Agent Observability and Incident Response Guide.
- Alerts: denied tool calls above baseline, first use of a tool by an agent, token audience mismatches at the gateway, sandbox egress attempts to private ranges, approvals bypassed or timed out.
| Metric | Target direction |
|---|---|
| Agent tool calls passing through the gateway | 100 per cent |
| Agents with their own identity and a named owner | 100 per cent |
| Static secrets visible to agent processes | Zero |
| Granted versus used tools per agent | Ratio falling towards 1 |
| Time from kill decision to last action | Under a minute |
| Incidents where the trace could not be rebuilt end to end | Zero |
Framework mapping
| Framework | Reference | Component |
|---|---|---|
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection; LLM06 Excessive Agency | Model gateway; tool gateway and policy |
| OWASP Top 10 for Agentic Applications 2026 | ASI01, ASI02, ASI03, ASI05, ASI06, ASI07 | See trust boundaries table |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication; AC-3 Access Enforcement; AC-6 Least Privilege; AC-4 Information Flow Enforcement; SC-7 Boundary Protection; AU-2 and AU-12 logging; AU-10 Non-repudiation | Identity service, gateway, egress, telemetry |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, PR.PS-04, DE.CM-09, RS.MI-01 | Identity, permissions, logging, monitoring, containment |
Common failure patterns
- API keys in the agent's environment: anything the process can read, a prompt-injected agent can be told to reveal or use.
- Token passthrough in MCP servers: the downstream API trusts a token never meant for it, and logs show the wrong caller.
- Guardrails only on the user prompt: injection arrives through documents, tickets and tool results, as ForcedLeak showed.
- Sandboxes with credentials: code interpreters that can reach the cloud metadata service or carry the agent's own token.
- Stale egress allowlists: trusted domains that expire or change owner.
- No session binding: session IDs treated as authentication, so a guessed ID impersonates a user.
Practitioner checklist
- Route every agent tool call through one gateway with deterministic policy.
- Give each agent its own identity, owner and registry entry.
- Use RFC 8693 delegation with an act claim for agents acting for users.
- Reject tokens not issued for each MCP server and never forward client tokens.
- Keep secrets in a vault, injected at the gateway, never in the model context or agent process.
- Run code and browser tools in ephemeral sandboxes with egress blocking private and link-local ranges.
- Scope memory per user and tenant and validate writes.
- Require human approval for payments, deletions, external messages and permission changes.
- Emit one trace per request covering model, tool, policy and approval events.
- Test the kill switch quarterly against a live agent.
Standards and references
- Model Context Protocol: Authorization specification
- Model Context Protocol: Security Best Practices
- IETF: RFC 8693 OAuth 2.0 Token Exchange
- OWASP: Top 10 for LLM Applications 2025
- OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
- AWS: What is Amazon Bedrock AgentCore
- Microsoft Learn: What is Microsoft Entra Agent ID
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: AI Security Architecture Reference Guide · Agentic AI Identity Guide · AI Agent Sandboxing and Code Execution Guide · MCP Security Guide