MCP compliance kernel

Let the agent loose.
Keep the keys.

A policy layer between your AI agent and your data. It allows, denies, or rewrites every action, then logs it.

See the before / after How the chokepoint works
AI agent request (no key) AEGIS compliance kernel Postgres allowed S3 bucket denied

Plain MCP wires the agent straight into your data.

  • With plain MCP, the agent connects directly to every system, and holds the credentials itself.
  • Nothing stands between "the model decided to run this" and the database running it.
  • A DROP TABLE hidden in a query, a column of PII exported to a file, an instruction smuggled inside the data itself. They all just happen.
  • And afterward, you can't prove what it was or wasn't allowed to do.
AI agent holds keys Postgres S3 bucket External API

No layer in the middle. The credentials and the system are one reach apart.

AI agent AEGIS kernel Postgres S3 bucket External API
direct and dangerous

Put one chokepoint in the middle.

One change fixes the whole category of problem. The agent no longer talks to systems. It talks to the kernel, and only the kernel holds the keys and can reach the systems.

"The agent holds a request, never a key."

Press the button to watch the credentials move out of the agent's hands and into the kernel.

One tool call, walked through the kernel.

Every call takes the same path. Pick a verdict and step through it. There are three possible outcomes, not two.

Conditions, not a fixed order.

The kernel doesn't dictate a sequence of steps, which would turn the agent back into a rigid script. It enforces conditions instead: "you may promote data to the trusted tier only once it's been validated." The agent works in any order it likes, and the rule holds regardless.

And it can't cheat: the receipt is issued by the kernel, never claimed by the agent.

agent.call promote silver.customers to gold
DENIED. Gold requires a validation receipt.
KERNEL STATE
VALIDATED
receipt#a91f · dataset=silver.customers
issued_by=kernel · ts=2026-06-24T09:14Z
no receipts on file

The live demo

Same task. Same agent. Flip the policy.

Task: "Clean up the customer database and promote it to gold."
POLICY: OFF
AGENT ACTIONS
Inject a malicious instruction hidden inside the data
AUDIT LOG
aegis · audit.log

illustrative simulation Scripted client-side. No real systems are touched. This demonstrates the behavior; it isn't a live kernel.

Plain MCP versus Aegis, side by side.

Plain MCPAegis
Who the agent connects toEvery system, directlyOnly the kernel
Where credentials liveIn the agent's handsIn the kernel; never exposed to the agent
What governs an actionNothing. The model just actsA policy check on every call: allow / deny / transform
Destructive operationsPossible, even hidden inside a queryBlocked, including DROP and TRUNCATE parsed out of opaque SQL
Sensitive dataFlows out as-isMasked before the agent ever sees it
Order and safety guarantees"Hope the model behaves"Invariants enforced regardless of order
Malicious instruction hidden in the dataCan hijack the agent's actionsBlocked. Enforcement sits below the model
AuditNoneEvery decision and the rule that fired, logged

What this is, and what it isn't.

What it is

Policy enforcement that supports compliance. Semantic checks, like reading the SQL at the AST level, are defense-in-depth, backed by a default-deny stance so a miss fails safe. Deterministic enforcement that sits below the model, which is why it's injection-resistant by construction.

What it isn't

Not a magic "you're now GDPR-compliant" button. Not a general-purpose MCP gateway. It's a compliance kernel with a point of view, opinionated about what should never happen rather than trying to be everything to everyone.

An agent that can't go off the rails.

Aegis holds the keys, checks every call, and writes down what it decided. The agent stays free to work. The guarantees hold no matter what it tries.