# The current state of security for autonomous agents in the cloud

This post covers how different cloud providers (AWS, Azure, and GCP) productize parts of the agent runtime, and how to architect the rest yourself. Prompt injection is still intrinsic, so a hijacked plan has to hit session sandboxes, short-lived agent identity, brokered credentials, deny-by-default egress, and AuthZ outside the model before it can act. The rest of the piece is framed as stacked planes: isolation, identity, credentials, network/egress, the action broker, memory and data, observability and kill switches, tenancy, and supply chain. Each section places the control in the architecture; a later pass separates what the platform already enforces from what your app still owns.

* * *

## Prompt Injection

OWASP's LLM Top 10 2026 still puts prompt injection first. The Agentic Top 10 widens the same failure into multi-step damage: goal hijack, tool misuse, identity abuse, unexpected code execution, memory poisoning, cascading failures, and rogue agents.

The chain that matters for infra is short:

1.  Untrusted content enters context (user text, retrieved docs, tool replies, screenshots).
    
2.  The model proposes tool calls or code.
    
3.  Something in *your* stack must authorize arguments, attach credentials, and choose a network path.
    
4.  If that something is the model, or a shared god key living in the sandbox, you have already lost.
    

OWASP's prompt-injection write-up treats private data + untrusted content + external communication as a pre-deployment check. For platform design, that mix is the architecture test: wherever those three meet, you need isolation, AuthZ outside the model, and egress policy.

NIST AI 600-1 adds the ops half: go/no-go thresholds, monitoring, and the ability to **deactivate** a generative system when risk is unacceptable. Design kill switches into the runtime from the start.

* * *

## How trust actually breaks in an agent runtime

A useful mental model is two planes:

![](https://cdn.hashnode.com/uploads/covers/63c36531502ec63755722bf4/c2a9c76f-7b82-4472-bc08-dfa12965ccc0.png align="center")

OpenAI's Agents guidance names this explicitly: the harness owns the loop, routing, approvals, and recovery; the sandbox owns files, commands, and mounts. Anthropic's computer-use docs push the same idea: dedicated low-privilege VM/container, internet allowlist, no sensitive credentials in the environment, human confirmation for consequential actions.

Cloud platforms are converging on session-scoped isolation. Amazon Bedrock AgentCore Runtime puts each user session in a dedicated microVM and tears it down when the session ends (with memory sanitization). That is strong isolation. AWS AgentCore also states that **session-to-user binding is your job**: the platform does not prove that `runtimeSessionId` belongs to the authenticated caller. If your backend accepts a client-supplied session id under a shared invoker principal, you have rebuilt session routing as an attack surface.

Inside that microVM, execution-role credentials can be readable via the metadata path. Treat "isolated session" as a hard boundary against *other tenants*. Keep long-lived cloud admin keys out of the guest.

* * *

## Isolation plane: one session, one sandbox

Pick the hard boundary from the workload.

| Boundary | When it fits | What it does not buy you |
| --- | --- | --- |
| MicroVM (Firecracker / managed equivalents) | Hostile or multi-tenant code/tool runners | Automatic user binding or secret safety inside the guest |
| gVisor (`runsc`) | Linux-container compatibility with a smaller host syscall surface | Network policy, cgroups, or hardware side-channel immunity by itself |
| WASM / WASI | Capability-deny-by-default compute with limited OS fidelity | Full Linux semantics for arbitrary agent tooling |

Firecracker's production guidance is: start instances only through the jailer (or equally tight constraints). Wasmtime's WASI context is empty by default: no env, no preopens, addresses denied until you grant them. That default matches how you want agent tool runners to behave.

Prefer destroy-on-complete over long-lived shared runners for multi-tenant execution. Durable memory belongs in a memory service with tenant filters, not in a warm sandbox that another user might reuse.

* * *

## Identity plane: agents need their own principals

Three clouds now ship first-party agent identity. Use them as principals, then still design AuthZ.

**Google Cloud Agent Identity** gives each agent a SPIFFE-based ID and an auto-managed X.509 credential. Tokens for Google APIs are bound to that cert; Context-Aware Access can require mTLS and DPoP so a stolen bearer token is harder to replay outside the trusted runtime. Certs rotate on a short horizon (docs: 24 hours). Deleting an agent does not clean up IAM bindings that still name its principal; redeploy creates a new principal.

**Amazon Bedrock AgentCore Identity** centers on workload identities plus a KMS-backed token vault for OAuth tokens, client credentials, and API keys. Prefer `GetWorkloadAccessTokenForJWT` (cryptographic user proof) over the opaque userId path when JWTs are available. Resource indicators (RFC 8707) show up in the docs for a reason: MCP-style audience binding.

**Microsoft Entra Agent ID** treats agents as their own identity class: sponsorship, blueprints, distinct audit entries, Conditional Access that can **block** agent identities, and ID Protection signals for risky agents. Conditional Access and ID Protection for AI agents require a **Microsoft Agent 365** license for each user, paired with standard Microsoft Entra ID P1 or P2 prerequisites. Blueprint count should follow trust boundaries (shared runtime, secrets, filesystem, network). Default planning guidance is one agent identity per logical agent. Distinguish autonomous operation (agent as subject) from interactive/delegated operation (user as subject, agent as actor).

SPIFFE/SPIRE remains the open workload-identity foundation when you DIY; cloud Agent ID products are the managed expression of the same idea. Deeper SPIFFE mechanics for agents live in a separate note if you need them.

* * *

## Credential plane: broker in, never bake in

OpenAI's sandbox security guide is the clearest short statement: keep application API keys outside the environment; allow outbound only to approved hosts; use a credential broker or vault proxy so third-party secrets are injected for approved destinations. Secrets injected into the sandbox env are still readable by agent-generated code.

GCP's auth-manager + gateway pattern can keep raw end-user tokens off the agent. AWS AgentCore's token vault binds credentials to authorized workload identities and encrypts at rest. MCP's HTTP authorization profile is OAuth 2.1 with PKCE and resource indicators; servers must audience-validate tokens and must not pass tokens through to upstream APIs.

Rule of thumb:

*   **User-delegated OAuth** when the tool touches a user's private resources.
    
*   **Agent service identity** when the call is machine-to-machine against shared tools or cloud APIs.
    
*   Never one "god" key shared across agents or tenants.
    

* * *

## Network plane: deny by default, then name destinations

OWASP's Agentic Top 10 mitigations for tool misuse call out outbound allowlists for sandboxed tool and code execution. Anthropic and OpenAI both document allowlisting domains for computer-use / sandbox egress. That is also how you shrink SSRF and browsing-based exfil: the agent becomes a proxy the moment you give it URL fetch or a browser.

Cloud knobs that match the same idea:

*   **Azure Foundry Agent Service** (GA private networking): BYO VNet or managed VNet, private endpoints, public access disabled by default in the private networking model. One thing worth calling out: even when the Foundry account and dependencies sit behind private endpoints, a **hosted agent endpoint URL can still stay publicly addressable**. Tenant isolation on that URL is by identity and per-user session.
    
*   **GCP Agent Runtime / Gemini Enterprise Agent Platform**: VPC Service Controls can block default public internet from the managed environment; egress must be intentional (customer VPC, proxy, NAT). Deploy into the perimeter before you rely on it.
    
*   **AWS AgentCore**: network security guidance plus IAM condition keys that can require VPC subnet/security-group constraints for runtime deployments.
    

Separate browsing/fetch runners from high-value credential namespaces. Block link-local and metadata ranges from untrusted sandboxes. Prefer allowlists over blocklists.

* * *

## Action broker: the model proposes, policy disposes

Treat tool calling as a brokered control plane:

1.  Allowlist tools per agent identity.
    
2.  Validate schemas and arguments in code, not in the prompt.
    
3.  Attach scoped credentials per call from the vault.
    
4.  Gate side effects by risk class (read vs write vs money vs identity change), with human confirmation for destructive or high-impact actions.
    
5.  Emit an audit event before and after execution.
    

That broker is where MCP OAuth, Entra/AWS AgentCore/GCP identities, and HITL meet. Dry-run or diff views before destructive approvals help humans stay real reviewers instead of rubber stamps.

* * *

## Memory and data plane: segment before retrieve

OWASP's Agentic Top 10 calls for memory segmented by user, session, and domain; encryption in transit and at rest; minimized retention; per-tenant namespaces for shared stores. AWS AgentCore is explicit that session microVM state is ephemeral; durable context belongs in a memory product with your filters applied.

Put retrieval behind a data-plane check that enforces tenant/user filters *before* chunks enter model context. Retrieved text is still untrusted for goal and tool influence. Encrypt transcripts, tool-result blobs, and memory stores with customer-managed keys where your threat model requires it. Classify prompt logs as sensitive.

* * *

## Observability and kill switches

OWASP's Agentic Top 10 letter treats strong observability as non-negotiable: what the agent did, why, and which tools it invoked. Unbounded consumption maps to rate limits, token/spend budgets, and circuit breakers. Cascading-failure guidance is why you limit fan-out between agents.

Correlate at least: `trace_id`, `agent_identity`, `user_subject` (if on-behalf-of), `session_id`, `tool_name`, `tool_args_hash`, `policy_decision`, `resource`, `model_request_id`, `egress_destination`. Prefer append-only sinks for high-assurance investigation.

Emergency revoke, practiced once before you need it:

1.  Disable or Conditional-Access-block the agent identity.
    
2.  Destroy active sandboxes/sessions.
    
3.  Revoke OAuth grants in the token vault.
    
4.  Freeze spend and rate budgets.
    
5.  Keep immutable logs.
    

That sequence is how NIST's deactivation language becomes a runbook.

* * *

## Tenancy and blast radius

AWS AgentCore's multi-tenant guidance is worth internalizing even if you are not on AWS: prefer distinct IAM principals per user or tenant for high-security designs; a shared invoker plus client-chosen session ids is fragile. Agents that share a runtime instance can share a filesystem; the isolation unit is the session, so do not co-locate agents that must not see each other in the same session.

Entra: a compromised blueprint affects every identity under it. OpenAI: separate environments (and often separate projects) for workloads that must not share data.

Assume shared model-provider infrastructure may retain prompts unless your contract says otherwise. Segregate vector indexes and cache keys by tenant. Purge memory namespaces on offboarding.

* * *

## Supply chain for agent definitions

OWASP's Agentic Top 10 treats prompts, tool manifests, and orchestration configs as supply chain artifacts: sign and attest them, pin dependencies, use curated registries for MCP servers, reject unsigned updates where you can. Pair an AIBOM (OWASP GenAI's CycloneDX-oriented generator exists for this) with ordinary SBOMs for runner images. Aim SLSA Build provenance at the images that execute tools, not only at the app container that hosts the chat UI. The LLM Top 10 supply-chain entry covers complementary model and plugin supply risks.

* * *

## What platforms give you vs what you still own

| Layer | Often productized now | Still your design |
| --- | --- | --- |
| Isolation | AWS AgentCore per-session microVMs; provider sandbox docs | Session↔user binding; what secrets enter the guest |
| Identity | GCP Agent Identity, Entra Agent ID, AWS AgentCore Identity | On-behalf-of (user-delegated) vs autonomous mode; blueprint/trust-boundary layout; Agent 365 + Entra P1/P2 for CA / ID Protection |
| Credentials | Token vaults, auth managers, MCP OAuth profiles | No god keys; audience binding; broker wiring |
| Network | Foundry private networking (GA); VPC-SC + PSC; VPC condition keys | Allowlist content; fetch-runner separation; hosted agent URL may remain public |
| Ops | Cloud audit integrations, risky-agent signals | Correlated app logs, budgets, practiced kill switch |

### Bedrock Agents vs AWS AgentCore

Do not conflate these AWS surfaces.

**Amazon Bedrock Agents** (now labeled **Agents Classic** in AWS docs) is a managed orchestration product: you configure an agent, action groups (often Lambda + OpenAPI schemas), optional knowledge bases, aliases, and optional Guardrails. AWS manages prompting and invocation plumbing. The security story is mostly IAM: a least-privilege agent service role (model invoke, S3 schemas, knowledge-base query, optional `bedrock:ApplyGuardrail`), resource policies so only your agent can invoke those Lambdas, and callers restricted to specific agent-alias ARNs for `InvokeAgent`. That is real shared-responsibility work on IAM and Guardrails. Per-session microVM isolation for custom agent code is AWS AgentCore's documented model. AWS also states Agents Classic is **no longer open to new customers** (existing customers continue; new work is pointed at AWS AgentCore).

**Amazon Bedrock AgentCore** is the runtime/control-plane set for custom agent code and tools: Runtime (per-session microVM isolation), Identity (workload identities + token vault), plus Memory, Gateway, and related services. You bring the agent framework; AWS AgentCore hosts and operates the isolation and credential edges. Session-to-user binding, execution-role blast radius inside the guest, and your tool broker remain yours.

If you are reviewing an existing Agents Classic deployment, keep reviewing action-group IAM and Guardrails. If you are designing new autonomous infra on AWS, design against AWS AgentCore's isolation and identity model, then still add the broker, egress, and kill-switch planes above.

* * *

## Putting it together

If you can only harden two seams this quarter, ship the **tool broker** (AuthZ and schema checks outside the model, scoped creds per call) and a **practiced kill switch** (identity disable, session destroy, vault revoke, budget freeze, logs retained). Isolation and egress decide how far a bad plan can travel; the broker and the kill switch decide whether you can stop it.

Prompt hardening still helps for quality and soft guardrails. Runtime trust still sits in code, identity, network, and ops.

* * *

## References

*   OWASP Top 10 for Agentic Applications 2026: [https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
    
*   OWASP GenAI LLM Top 10 2026: [https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)
    
*   OWASP prompt injection (LLM Top 10 2026, canonical): [https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM01\_PromptInjection.md](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/final/LLM01_PromptInjection.md)
    
*   NIST AI 600-1: [https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)
    
*   Firecracker design / prod host setup: [https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md](https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md)
    
*   gVisor security model: [https://gvisor.dev/docs/architecture\_guide/security/](https://gvisor.dev/docs/architecture_guide/security/)
    
*   Wasmtime WASI context defaults: [https://docs.wasmtime.dev/api/wasmtime\_wasi/struct.WasiCtxBuilder.html](https://docs.wasmtime.dev/api/wasmtime_wasi/struct.WasiCtxBuilder.html)
    
*   Amazon Bedrock Agents (Agents Classic): [https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html](https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html)
    
*   Bedrock Agents service role / permissions: [https://docs.aws.amazon.com/bedrock/latest/userguide/agents-permissions.html](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-permissions.html)
    
*   Amazon Bedrock AgentCore Runtime security: [https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-security-best-practices.html](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-security-best-practices.html)
    
*   AWS AgentCore Identity: [https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html)
    
*   Google Cloud Agent Identity: [https://docs.cloud.google.com/iam/docs/agent-identity-overview](https://docs.cloud.google.com/iam/docs/agent-identity-overview)
    
*   Microsoft Entra Agent ID architecture: [https://learn.microsoft.com/en-us/entra/agent-id/how-to-plan-agent-identity-architecture](https://learn.microsoft.com/en-us/entra/agent-id/how-to-plan-agent-identity-architecture)
    
*   Conditional Access for agents (Agent 365 + Entra P1/P2): [https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id](https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id)
    
*   ID Protection for agents: [https://learn.microsoft.com/en-us/entra/id-protection/concept-risky-agents](https://learn.microsoft.com/en-us/entra/id-protection/concept-risky-agents)
    
*   Azure Foundry agent private networking: [https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/virtual-networks](https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/virtual-networks)
    
*   GCP VPC Service Controls (Vertex / agent platform): [https://cloud.google.com/vertex-ai/docs/general/vpc-service-controls](https://cloud.google.com/vertex-ai/docs/general/vpc-service-controls)
    
*   MCP authorization: [https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)
    
*   MCP security best practices: [https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security\_best\_practices](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices)
    
*   OpenAI sandbox security: [https://developers.openai.com/api/docs/guides/agents-api/environments/security](https://developers.openai.com/api/docs/guides/agents-api/environments/security)
    
*   Anthropic computer use: [https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/computer-use-tool](https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/computer-use-tool)
    
*   SLSA levels: [https://slsa.dev/spec/v1.0/levels](https://slsa.dev/spec/v1.0/levels)
    
*   OWASP AIBOM generator: [https://github.com/GenAI-Security-Project/aibom-generator](https://github.com/GenAI-Security-Project/aibom-generator)
    

*Research for this post was assisted by AI agents.*