We Enforced AI Agent Authorization at the Linux Kernel Level

An AI agent has a credential. The credential says it cannot modify security configurations. The agent tries anyway.

We caught it. At the syscall level. Before it could do anything.

Here is how it works — and why it matters.

The Gap We Had

MolTrust issues Agent Authorization Envelopes — cryptographically signed credentials that define what an agent is and is not allowed to do. An AAE might say: actions_denied: ["policy.modify", "config.write"].

The problem: enforcement happened at the API layer. If the agent called MolTrust’s API before acting, we could reject the request. But what if it did not? What if it modified its own authorization before calling the API? What if it wrote directly to the filesystem without going through any MolTrust-aware endpoint?

This was Gap 1 from RSAC 2026: policy self-modification detection. Every identity check passes. The action is authorized. Nobody detects it.

The Solution: Three Layers

We now enforce AAE constraints at three independent layers:

Layer 1 — Cryptography. The AAE is Ed25519-signed. Tampering with it breaks the signature. This cannot be bypassed — it is math.

Layer 2 — API. Every MolTrust API call verifies the credential before processing. If the agent is not authorized, the request is rejected.

Layer 3 — Kernel. Falco, the CNCF-graduated eBPF security tool, monitors every syscall the agent makes. If the agent tries to write to /etc/ — even if the write is ultimately blocked by container permissions — Falco catches it at the kernel level and fires a webhook.

The kernel layer is the one that closes Gap 1. It operates below the agent’s execution context. There is no userspace code the agent can run to bypass it.

What Happened in the Test

Harald Rössler — MolTrust’s infrastructure engineer — deployed Falco on a production OpenClaw gateway instance with three custom MolTrust rules. A test agent with actions_denied: ["policy.modify", "config.write"] attempted to write to /etc/.

The result:

Warning:  MolTrust AAE violation: unexpected process spawned
          (container=openclaw-gateway, process=touch)

Critical: MolTrust AAE violation: agent wrote to restricted path
          (container=openclaw-gateway, file=/etc/falco-proof-test, user=node)

Falco caught both events at the syscall level. The bridge forwarded them to MolTrust’s IPR endpoint. The violations are now permanently recorded in the agent’s trust history, Merkle-anchored on Base L2.

The write was blocked by container permissions. But Falco caught the attempt — which is the point. An attempt is evidence of intent. Intent is what trust scoring needs to see.

What This Enables

Any MolTrust-registered agent running in a Kubernetes environment can now have its AAE constraints enforced at the kernel level. The bridge is open source:

https://github.com/HaraldeRoessler/moltrust-falco-bridge

The architecture is straightforward: Falco DaemonSet + custom MolTrust rules + bridge pod that translates Falco alerts into IPR records. The agent’s DID is bound via a Pod annotation (moltrust.ch/agent-did), so Falco alerts carry the DID directly.

The Bigger Picture

RSAC 2026 said Gap 1 — policy self-modification detection — was unsolved across all vendors. It is no longer unsolved for MolTrust.

The agent economy needs trust infrastructure that operates at all three layers: cryptographic identity, API-level authorization, and kernel-level behavioral enforcement. Any single layer is insufficient. Together, they make the trust claim verifiable — not just declarable.