Modern AI agents routinely cross trust boundaries: they ingest untrusted content, combine it with privileged instructions, persist intermediate beliefs in long-term memory, and invoke privileged tools. This creates an attack surface in which malicious payloads can enter through model inputs and cause harmful tool actions. Yet current governance stacks remain application-level middleware that share a process trust boundary with the agents they monitor. We argue that agents need an operating-system substrate providing mandatory, non-bypassable services for identity, input mediation, memory governance, and execution control. We introduce AgentKernel, a trust-native agent operating system built around the premise that security must be a first-class design constraint. AgentKernel wraps the agent lifecycle in a mandatory enforcement boundary organized into four pillars: Identity, Perception, Cognition, and Execution. Each pillar adapts classical OS security principles to failures at the semantic plane, including delegation abuse, prompt injection, memory poisoning, and tool misuse. AgentKernel treats structural security as a capability multiplier. Kernel-managed identity supports trustworthy cross-organization collaboration; graduated perception replaces brittle single-point filters; information-flow-controlled memory improves retrieval fidelity while limiting poisoning; and semantic-to-kernel enforcement permits broader tool privileges behind a non-bypassable boundary. We position AgentKernel as the missing OS layer beneath orchestration frameworks, agent runtimes, governance platforms, and execution sandboxes, and use systematic comparison and security analysis to show how a single integrated architecture can enforce security across the full agent lifecycle.
Figures & tables
Figure 1: AgentKernel ’s position in the AI agent technology stack. Agent applications (Claude Code, OpenClaw, mobile/GUI agents, etc.) sit atop AgentKernel , which mediates all interactions with LLM models, tools, and the outside world. AgentKernel and the traditional OS kernel jointly form the AI-Native OS : AgentKernel provides semantic-level services (identity, perception, cognition, execution governance) while leveraging the traditional kernel for syscall-level enforcement via eBPF hooks and process-tree monitoring.
Figure 2: Three-domain model. All inputs traverse the AgentKernel kernel before reaching the protected agent core; all outputs are identity-verified, intent-aligned, and permission-converged before leaving the kernel.
Dimension
Security Consequence
Capability Consequence
Identity
Impersonation and unauthorized multi-hop delegation without binding principals to code and authorization
Verifiable delegation chains across organizations stall; operators fall back on pairwise trust or manual approval gates
Version freezes and strict whitelists block safe participation in open third-party capability ecosystems
Perception
Prompt injection via tools, web pages, and files; untrusted content co-mingled with privileged instructions
Browser- and repository-backed toolchains are avoided or over-stripped, narrowing tasks an agent can safely cover
Encoding bypasses, jailbreaks, and spoofed UI or sensor readings that misstate device or application state
Multimodal and high-entropy pipelines require human checkpoints, capping throughput and end-to-end autonomy
Cognition
Cross-session memory poisoning; instruction–data confusion in long, multi-source context windows
Cross-session RAG and long-horizon memory cannot scale without per-entry provenance or costly write-side audits
Cross-tenant memory contamination; weak edge-side summarisation or routing exploited as a chain weak link
Shared memory pools across agents or business units are blocked; teams revert to siloed stores and manual reconciliation
Table 1: Infrastructure gaps across the agent lifecycle: missing OS services create both security vulnerabilities and capability limitations.
Figure 3: Defense-in-depth across the agent lifecycle. Each pillar independently intercepts a distinct threat class. Provenance labels flow across pillars (dashed arrows), enabling downstream pillars to make informed decisions based on upstream assessments. Compromise of one pillar does not cascade to others.
Figure 4: AgentKernel architecture. The security kernel mediates all interactions between the untrusted input world and the auditable output world. Four security pillars operate around the protected agent core, each enforcing independent invariants.
Figure 5: Identity as a kernel-managed resource. The Agent Kernel holds the private key and mediates all identity operations on behalf of the agent. Identity-derived trust signals flow into each of the other three security pillars through the kernel’s control plane, making identity the shared trust substrate for the entire security architecture.
Pillar
Invariant
Soundness Argument
Identity
I1. AIC unforgeability
Ed25519 signatures verified against GAR root at every presentation; Kpriv never leaves kernel boundary (§ 4.2 ).
All input paths traverse P1 (Source Tagger) as mandatory first stage; tags persist through P2–P4.
P2. Layered independence: bypassing one filter does not help bypass others
P1–P4 operate on orthogonal features (source identity, syntactic patterns, semantic intent, multi-turn history).
Table 2: Security invariants of the AgentKernel architecture.
Dimension
AgentKernel
AGT [ 26 ]
AIOS [ 22 ]
OpenFang [ 23 ]
SmythOS [ 24 ]
Letta [ 25 ]
nono [ 29 ]
Pillar 1: Identity (§ 4.2 )
Cryptographic workload identity
∙
∙
—
∘
—
—
∘
Multi-dimensional provenance
∙
—
—
—
—
—
—
Cross-org A2A attestation
∙
∘
—
—
—
—
—
Pillar 2: Perception (§ 4.3 )
Input provenance tagging
∙
—
—
∘
—
—
—
Table 3: Comparison of representative systems across systematic Agent OS dimensions. Rather than treating security and capability as isolated features, AgentKernel demonstrates how OS-level security primitives (e.g., identity, taint tracking) directly enable advanced agent capabilities (e.g., cross-org A2A, provenance-aware retrieval). ∙ = comprehensive support as a core design element; ∘ = partial or optional support; — = absent or not a design focus.
System
Deployment
Primary focus
Security
AIOS
HTTP server + in-proc agents
LLM scheduling
No auth; stub ACL
OpenFang
Daemon / in-proc kernel
Skill/Plugin sandbox
Mandatory for hosted; opt-in for external
SmythOS
In-proc library (npm)
Unified resources
ACL + SES sandbox
Letta
Standalone server
Memory management
Optional sandbox
AgentKernel
Form-agnostic
Security kernel
Mandatory, non-bypassable
Table 4: Agent runtime deployment models and enforcement characteristics. Deployment indicates whether the runtime runs in the same process as the agent ( in-proc ), as a separate service ( service ), or in a hybrid mode. Security enforcement indicates whether security mechanisms are mandatory or opt-in. AgentKernel is included for comparison; its deployment form is explicitly secondary to the non-bypass invariant (Principle 5).
Artificial intelligence agent security studies attacks and safeguards for tool-using, persistent, and collaborative systems across digital and physical settings.