Most agent “guardrails” run as application middleware — a PII filter here, a tool-permission check there — living in the same process as the agent they police. That’s the assumption AgentKernel goes after: if a prompt injection can take over the agent, it can usually route around the middleware sitting right next to it. Governance that shares a trust boundary with the thing it governs isn’t really governance.

The paper pushes identity, input mediation, memory governance, and execution control down into a non-bypassable substrate — an OS layer beneath the orchestration framework rather than another wrapper stacked on top. Four pillars (Identity, Perception, Cognition, Execution) map classic OS security principles onto semantic-plane failures: delegation abuse, prompt injection, memory poisoning, tool misuse. The information-flow-controlled memory is the piece I’d want in production first. Memory poisoning is the quiet failure mode in long-running agents, and treating retrieved context as trust-tagged rather than trusted-by-default is overdue.

The reframe worth sitting with is that they treat structural security as a capability multiplier, not a tax. A non-bypassable boundary is exactly what lets you hand an agent broader tool privileges, because misuse gets caught at enforcement time instead of hoped away at prompt time. That inverts how most teams reason about locking agents down — the instinct is always to restrict. The HF paper page has the full pillar-by-pillar breakdown. Whether this becomes a real substrate or stays an elegant architecture proposal comes down to one number nobody has shown yet: what the enforcement boundary costs per tool call once it sits inside a production latency budget.

tags: [ agentic-ai ] [ llm-ops ] [ ai-infrastructure ] [ research ]