This is a collection of resources supporting the idea that provable runtime security guarantees for agents can be intrinsically bound to agent identity, perhaps as part of a broader representation of "intent", or in a tiered trust model. TEEs, hypervisor-enforced isolation, hardware roots of trust and several Linux security primitives are instrumental to get there. We curate some of the most promising references to date including applied technologies in agent frameworks, research and risk/mitigation-focused literature on this topic.
Risk/mitigation literature that discusses the importance of agent runtime security includes:
- SAFE-MCP
- CoSAI's MCP Security document
- OWASP Top 10 for Agentic Applications
- [2512.08290] Systematization of Knowledge: Security and Safety in the Model Context Protocol Ecosystem
- [2511.20920] Securing the Model Context Protocol (MCP): Risks, Controls, and Governance
- [2504.08623] Enterprise-Grade Security for the Model Context Protocol (MCP): Frameworks and Mitigation Strategies
Several of them recommend cryptographically protecting the integrity of tools, tool descriptions, models, data sources, and tool provenance. They advise sandboxing, increasing security observability, or using server-constrained or client-bound tokens.
An observation from Meta: agents can't simultaneously process arbitrary inputs, communicate externally, and access private data.
Note: This list focuses on agent security, but runtime security is relevant for training too, as illustrated in Atlas: A Framework for ML Lifecycle Provenance & Transparency (code) and ongoing OpenSSF discussions around GPU-based model integrity and model lifecycle provenance. Also see ws1-supply-chain/signing-ml-artifacts.md at main - cosai-oasis/ws1-supply-chain.
Here's a few examples of applied compositions of Linux security technologies to the problem of agent runtime security:
- boxlite (discussed for use in goose) uses KVM virtualization via libkrun
- sandbox-runtime uses Linux namespaces and seccomp filters (which Cloudflare's lower-case sandbox also uses) via bubblewrap
- nixwrap and sandbox-run also use bubblewrap
- try (and the simpler usand) use Linux namespaces via unshare
- rstrict, island and landrun all use Landlock, a stackable Linux Security Module (LSM)
- Docker sandboxes uses namespaces and cgroups via Linux containers, with MicroVM isolation in the roadmap
- Rover's Sandbox uses Linux containers
- cua also uses Linux containers, including qemu inside Docker
- e2b isolates with Firecracker MicroVMs, and k7 adds Kata to the mix
- langchain-sandbox uses WebAssembly via Pyodide
- Other solutions include V8 Isolates, nsjail, or gVisor...
- Guides | Agent Sandbox uses gVisor and Kata
- And some tools, like setpriv or systemd's unit settings can serve as a convenient frontend for many at once!
New LF initiative worth tracking: Open Robust Compartmentalization Alliance (ORCA)!)
Tool discovery, sandboxing and isolation, tracing and observability, policy, redaction, and threat detection are all activities expected to happen at the boundary of agents. Examples include:
- cupcake (their docs are worth a read!)
- mcp-gateway
- mcp-scan
- dapr-a2a
- mcp-context-protector
- rover
- agentry
- agentgateway
- opena2a
- Virtual MCP Server
Comprehensive instrumentation is also part of agent runtime security. eBPF has a credible track record in application observability, and this year has seen some research in the form of AgentSight or [2509.07764] AgentSentinel: An End-to-End and Real-Time Security Defense Framework for Computer-Use Agents (code).
Along with [2511.03434] Inter-Agent Trust Models and the Nanda Unified Architecture (2025), the CoSAI document is more explicit than others discussing the role Trusted Execution Environments (TEEs), secure key usage, and remote attestation play in agent security. But should those proofs be part of the agent identity? There's no shortage of activity happening in this space:
- Verifiable Credentials
- RFC 9901 - Selective Disclosure for JSON Web Tokens
- Distributed PEPs and PDPs and applied IAM solutions (AuthZEN, Cedarling, casbin, Oso, Aembit and more)
- PIC
- FAPI and RAR
- Anonymous Credentials
- WIMSE
- SPIFFE and OAuth
- And the intersection with XACML that inspired Riptides
- Trustworthy Workload Identity,
- DCR
- Qualified VDRs, Trust over IP, TRQP, and Verifiable Trust
- Transaction Tokens
- Macaroons (as in L402, and the safety envelopes in EAM-SQL)
- CAEP and SSF
- ID-JAG and JWT Authorization Grants in MCP
- Token Exchange
- And discussions around:
- Delegation and Delegated Authorization
- Encoding user intent
- Continuous authorization
- Token-Based Access Control
- Ambient Mesh
- Progressive Authentication
- Chaining and nesting for lineage
- Capability negotiation
- Intersection of agents and payments identity challenges
- Security requirements proportional to agency and autonomy
- Limitations in oAuth for the agent scenario
- And the applicability of various standards
- For a general picture of how comprehensive the list of claims should be across the many possible combinations of agent interactions, take a look at this specification compendium
- The curated and rather complete restyler/awesome-sandbox
- Ikangai's Complete Guide to Sandboxing Autonomous Agents
- Section 3 (Building blocks of a sandbox) of Survey of Real-World Process Sandboxing (2024)
- Section 4 (Linux security features) of Landlock: From a security mechanism idea to a widely available implementation (2024)
- Section 3 (Container adopted security techniques) of Security Challenges in the Container Cloud (2021)
- Leveraging Kernel Security Mechanisms to Improve Container Security (2019)