LIVE Running on a Kubernetes cluster right now. Every decision below is made by the sidecar, not a simulation.  
AgentPass Mesh
Live demo · trust enforcement for Kubernetes
ENFORCING
KUBERNETESEnforcement for AI agents

AgentPass Mesh

Every AI agent controlled by you

Every decision below is made by the sidecar, not a simulation. Real ECDSA P-256 signing on every call. Real hash-chained evidence. Real trust enforcement on models, databases and APIs.

What it does

Control what every AI agent can do. At scale.

Agents are being given production access faster than anyone can review it. This decides every call one of them makes, before it happens.

PREVENTS

Destructive actions

Dropping a table, deleting production data, moving money. Refused before the statement is sent, at every trust level including the highest.

CONTROLS

What each agent may reach

Per model, per statement, per route. An agent that may read a customer cannot move that customer's money.

CONTAINS

Agent breaches

Agents hold no credentials. A compromised or manipulated agent has nothing to steal and nowhere to go.

WITHOUT

Friction

One label covers every AI pod in the namespace. No SDK, no code change, no team to persuade.

Trust levels

How much do you actually know about the caller?

A trust level is not a permission. It says how strongly the identity was established, and policy decides what that buys. Two agents with the same permissions and different levels are not the same risk.

L0
Unverified
Nothing beyond the request arriving
Public models. Read only. Never a write, never personal data.
L1
Identity verified
A certificate chaining to a CA you trust
General purpose work. Business tables it may read.
L2
Signed messages
Each request proved by the holder of the key
The sensible default. Personal data and ordinary writes.
L3
Verified with revocation checking
Confirmed live, not merely valid when issued
Sensitive or fine tuned models. Writes to business data.
L4
Hardware bound key
A key that cannot be copied off the machine
Regulated and financial work. Moving money. Clinical models.
0
Decisions
0
Allowed
0
Refused
Chain verified

1 Pick an agent

2 Make it try something

Model gate
Database gate
API gate

Replay a real incident

Evidence chain · hash linked, ECDSA signed

Make a call and the signed record appears here.

Enforcer · live

Model policy · live

ModelRequires

Agent registry · live

AgentService accountLevel

Enforcer public key · verify any receipt with this

loading

Every record in the chain is signed with the matching private key, which never leaves this process. Anyone holding the key above can verify a receipt without asking us anything.

Mitigations

What actually stops happening.

Every incident you can replay above used valid credentials. Authentication worked perfectly. Nothing was deciding whether the action should happen.

Prompt injection

Injection stops being credential theft

The sidecar holds the identity and leases the database password for one authorised statement. There is no long lived secret inside the agent process to exfiltrate.

Model substitution

A swapped model is refused, not discovered later

The weights are digested and pinned. A substitution fails on the next request, before the credential is even read, for every caller.

Over-privileged agent

Connection access becomes call level

Every statement is decided on its own merits. Reading a customer and moving their money are different questions.

Shadow AI

Agents nobody registered are covered anyway

Coverage is a property of the namespace, not of whether a team volunteered. Pods deployed long after you stop asking are enforced.

Destructive action

Schema destruction is not a privilege

An agent with schema rights is one confused reasoning step away from an unrecoverable afternoon. DROP sits at the top of the ladder.

Disputed incident

The argument ends with a signature

Every decision, refusals included, is hash chained and signed. A receipt verifies with a public key and nothing else.

What it does not do. It does not read prompts. An adversarial instruction inside a properly credentialled request passes through, because the question it answers is who may make which call on what terms.