AEG: Zero-Trust Agent Security Middleware

A lightweight, pluggable middleware that stages, inspects, approves, and safely commits every AI agent side effect.

Comment

AEG: Zero-Trust Agent Security Middleware

Inspiration

AI agents can write code, modify files, call tools, and interact with external services. A single run may contain both useful work and a dangerous side effect. Runtime logs only describe what the agent claims to have done; they do not provide authorization or prove what actually changed.

We wanted to bring zero-trust and defense-in-depth principles into the agent era. Every persistent effect should be measured, evaluated, attributable, and reversible before it crosses the trust boundary.

That led us to build Agent Effect Gateway (AEG): lightweight security middleware placed between an untrusted agent runtime and durable system state.

What it does

AEG routes every agent run through five security checkpoints:

  1. Intake — scans the prompt for secrets and optional model-detected risk.
  2. Runtime — executes the agent inside a run-specific disposable workspace.
  3. Effect Review — measures the actual filesystem and declared HTTP effects, then evaluates them against deterministic policy and enabled security modules.
  4. Approval — pauses sensitive actions for exact, digest-bound human approval.
  5. Execute / Commit — revalidates the effects and either commits them or rolls back the complete run.

The trusted kernel owns staging, hashing, hard-deny rules, approval digests, commit, rollback, and evidence generation. These controls cannot be disabled through configuration.

Around the kernel is a typed, pluggable module system. Modules can inspect events or make a decision stricter, but they cannot weaken a decision already made by the kernel or another module.

AEG currently includes modules for:

  • Per-Agent policy profiles
  • Secret and prompt scanning
  • Local SingGuard-NSFA model analysis
  • Scoped Run identity and delegation
  • Digest-bound approval
  • Declared HTTP action mediation
  • Trace correlation
  • Tamper-evident security evidence

Security Center

We added a dedicated Security Center while preserving the original Agent Launchpad workflow.

Security operators can:

  • Monitor Agents, sessions, and individual Runs
  • Follow each Run across all five checkpoints
  • Inspect measured effects and the modules behind each decision
  • Review and approve exact pending manifests
  • Configure per-Agent policies and templates
  • Enable, disable, and configure pluggable modules
  • Simulate file and HTTP policy decisions before saving a policy
  • Verify the HMAC-chained security event ledger
  • Explore the trusted and untrusted boundaries through an interactive architecture diagram

The normal Playground only presents concise security notifications. Detailed policy, trace, identity, and evidence information stays in Security Center.

How we built it

AEG extends the provided Agent Launchpad rather than replacing it. The implementation uses TypeScript, React, Fastify, Vite, Docker, the Codex Runtime, and Volcano Engine Ark.

For every Run, the trusted control plane:

  1. Copies the Agent workspace and session state into an isolated staging area.
  2. Verifies that the staged baseline matches the protected workspace.
  3. Runs the Agent against staging only.
  4. Computes a canonical manifest from measured filesystem changes.
  5. Evaluates all kernel rules and module contributions using deny > require approval > allow.
  6. Binds an approval to the manifest digest, policy version, workspace before-state, and expiration time.
  7. Revalidates the effect immediately before execution.
  8. Atomically applies the approved result or restores the original state.
  9. Records correlated, redacted evidence in an HMAC-chained ledger.

The optional SingGuard-NSFA module runs locally through llama.cpp. Its classification is treated as a probabilistic security signal. If the model becomes unavailable, AEG records the degradation while deterministic kernel controls remain active.

Per-Agent HTTP rules may narrow the platform allowlist. Declared external actions are canonicalized and executed by a trusted gateway only after policy evaluation or approval.

Challenges we faced

Trusting effects instead of agent narration

Agent traces are useful for investigation, but the runtime producing those traces is inside the untrusted domain. We therefore built enforcement around hashes and filesystem facts measured independently by the control plane.

Preventing approval replacement attacks

A human approval can become unsafe if the content, policy, or workspace changes afterward. We bind approval to the complete manifest digest, policy version, before-state, and TTL, then verify all of them again before commit.

Keeping plugins configurable without weakening security

A flexible module system can accidentally allow a plugin to override platform protections. Our registry combines contributions using the most restrictive result, while hard-deny rules and commit controls remain locked inside the kernel.

Making security observable without exposing secrets

Security evidence needs enough context for investigation while avoiding prompt or credential leakage. Events are normalized, correlated by Agent, session, and Run, redacted before storage, and protected by an HMAC chain.

Accomplishments

  • A complete frontend-to-Agent-to-middleware execution path
  • Normal commit, human approval, denial, rollback, and degraded-model cases
  • Per-Agent policy configuration and real-time policy simulation
  • Exact before/after workspace hash evidence
  • Digest-bound approval and replacement-attack protection
  • A modular analyzer interface with local SingGuard-NSFA support
  • An interactive architecture and Run trace experience
  • 51 automated security and integration tests
  • Successful TypeScript checks and production builds
  • Zero production dependency vulnerabilities reported by npm audit --omit=dev
  • Real Docker and Ark acceptance tests for both commit and rollback scenarios

What we learned

Agent security needs controls at the effect boundary as well as the prompt boundary. Deterministic policy, transactional execution, human judgment, model-based detection, and observable evidence each solve a different part of the problem.

We also learned that model-based guardrails work best as replaceable sensors. The trusted kernel must remain effective when a classifier is unavailable, misconfigured, or uncertain.

What's next

The current project is a reproducible single-control-plane prototype. The next production steps are:

  • Enterprise identity and multi-tenant authorization
  • KMS-backed evidence signing
  • Durable database and distributed control-plane support
  • Hardened tenant sandboxing
  • Transparent L3 egress enforcement
  • Additional analyzer and policy-module integrations

AEG demonstrates a general middleware architecture in which agents can remain useful and extensible while persistent effects stay governed, observable, and reversible.

Built With

Share this project:

Updates

Submission history