Your AI agents are already calling models, querying databases, and hitting APIs in production. You probably cannot list which ones. Nothing is checking whether they should.
We built AgentPass Mesh to fix that. One namespace label. Every AI pod gets a sidecar. Every call checked before it happens.
This is real, running, and you can try it right now.
WHAT IT ACTUALLY DOES
AgentPass Mesh is a Kubernetes mutating admission webhook. When you label a namespace, every pod created in it gets a 2.8MB enforcement sidecar injected automatically. No SDK. No code change. No init container. Just a sidecar that sits between your agent and everything it talks to.
Three gates check every outbound call:
LLM Gate -- Which models can this agent call? A marketing bot at L1 cannot reach a clinical notes model that requires L4. Refused before the request leaves the pod.
Database Gate - SQL classified by destructive potential. SELECT is L0. INSERT is L1. UPDATE is L2. DELETE is L3. DROP is L4. Your data analyst agent can read the customer table. It cannot drop it.
API Gate - HTTP methods mapped to trust levels. GET is L0. POST is L1. PUT/PATCH is L2. DELETE is L3. A monitoring agent cannot call DELETE on your admin API.
Default deny. Unrecognised operation? Refused.
INSTALL IT
Two commands:
helm install agentmesh oci://ghcr.io/razashariff/agentmesh --set certManager.enabled=true
kubectl label namespace prod agentmesh.io/inject=enabled
That is it. Every AI pod in the prod namespace now has enforcement.
HOW TRUST LEVELS WORK
Five levels, bound to Kubernetes service accounts via a ConfigMap:
L0 read-only -- monitoring, non-sensitive queries
L1 standard -- general purpose operations
L2 specialist -- multi-step workflows, data modification
L3 compliance -- financial, medical, legal operations
L4 critical -- destructive actions, human approval required
You assign levels by service account:
apiVersion: v1
kind: ConfigMap
metadata:
name: agentmesh-policy
data:
policy.json: |
{
"default_level": 1,
"agent_bindings": {
"system:serviceaccount:prod:marketing-sa": 1,
"system:serviceaccount:prod:analyst-sa": 2,
"system:serviceaccount:prod:finance-sa": 3,
"system:serviceaccount:prod:deploy-sa": 4
},
"model_policies": {
"gpt-4": 2,
"claude-opus-4": 3,
"clinical-notes-v2": 4
}
}
Different service account, different trust level, same namespace. No application code changes.
EVERY DECISION IS SIGNED
Every enforcement decision - admit or refuse - gets signed with ECDSA P-256 and hash-chained into a tamper-evident evidence ledger. Each record links cryptographically to the previous one. Tamper with one record and the entire chain breaks.
This is not logging. This is cryptographic proof. You get:
- Record number, timestamp, agent ID
- Gate type (llm/db/api), target, required level
- Decision (ADMITTED/REFUSED), reason
- SHA-256 hash linking to previous record
- ECDSA signature you can verify offline
The enforcer's public key is published. Verify any receipt without touching the cluster.
X.509 CERTIFICATES WITH CUSTOM OID EXTENSIONS
Every agent gets an X.509v3 certificate with five OID extensions under IANA Private Enterprise Number 66339:
1.3.6.1.4.1.66339.1 -- trust level (L0-L4)
1.3.6.1.4.1.66339.2.1 -- jurisdiction
1.3.6.1.4.1.66339.3 -- capabilities
1.3.6.1.4.1.66339.4 -- protocol binding
1.3.6.1.4.1.66339.5 -- agent ID
OpenSSL reads them natively:
openssl x509 -in agent.crt -text -noout | grep -A1 "1.3.6.1.4.1.66339"
SPIFFE URI SANs included. If you already run SPIRE, the mesh accepts your existing SVIDs and maps them to trust levels.
WHAT IT LOOKS LIKE WHEN AN ATTACK HITS
Hugging Face, July 2026. An AI agent escaped its container with valid Kubernetes service account tokens. 17,600 unauthorised actions. Credential theft. Lateral movement. Identity was valid the entire time.
With AgentPass Mesh, we simulated the same attack. Seven actions. All refused at L0.
The agent had a valid identity. It had real credentials. The mesh does not care about credentials. It checks trust level against the operation. L0 cannot call gpt-4 (requires L2). L0 cannot run UPDATE (requires L2). L0 cannot DELETE (requires L3). L0 cannot DROP (requires L4).
Every refusal signed, chained, and auditable.
Try it yourself at https://agentmesh-demo.fly.dev -- that page runs the real Go enforcement engine, not a mock. Pick an agent, pick a gate, see the signed verdict.
THE REPLIT SCENARIO
July 2025. A legitimately authenticated agent deleted a production database. It had every right to connect. It had the credentials. Nothing asked whether a marketing tool should be running DELETE FROM production_db.
With AgentPass Mesh: DELETE requires L3. A marketing bot at L1 is refused before the SQL statement is sent. DROP TABLE requires L4. Nobody gets L4 without explicit assignment.
WHAT IS IN THE BOX
Written in Go. Zero external dependencies. Pure stdlib. The whole sidecar compiles to a 2.8MB distroless image.
- Mutating admission webhook (auto-injects sidecar)
- Three enforcement gates (LLM, DB, API)
- ECDSA P-256 signing on every decision
- Hash-chained evidence ledger with journal persistence
- X.509 cert issuance with OID extensions
- Prometheus metrics (agentmesh_decisions_total, agentmesh_evidence_records, agentmesh_chain_verified)
- Built-in dashboard at /dashboard on the sidecar
- Bilateral kill switch (revoke an agent or a model globally)
- cert-manager integration for webhook TLS
- Two replicas by default, PDB, topology spread, zero-downtime rolling updates
- NetworkPolicy, securityContext, readOnlyRootFilesystem, drop ALL capabilities
- Cosign-signed images
Verified on AWS EKS (1.32), Google GKE (1.35), kind (1.36). Enforcement latency: p50 1.1ms, p99 3.1ms.
Verify the images before you pull:
cosign verify --key cosign.pub ghcr.io/razashariff/agentmesh-webhook
cosign verify --key cosign.pub ghcr.io/razashariff/agentmesh-sidecar
WHY NOT JUST USE OPA/KYVERNO/NETWORK POLICY
OPA and Kyverno enforce admission policy - what pods can be created, what images can run. They do not evaluate individual operations inside a running pod. Your agent is already admitted. OPA is done. The agent then calls DROP TABLE. Nobody checks.
Network policy controls which services can talk to which. Your agent is allowed to reach the database. Network policy is done. The agent then runs DELETE FROM production. Nobody checks.
AgentPass Mesh checks the operation, not the connection. It sits inside the pod and evaluates every call against the agent's trust level. OPA decides if the pod can exist. Network policy decides if the pod can connect. AgentPass Mesh decides if the agent can do what it is about to do.
They are complementary, not competing.
WHAT THIS IS BUILT ON
Patent GB2619955.4 (Kubernetes inference mesh) and GB2619899.4 (inference trust enforcement). CyberSecAI holds 32 patents across AI agent trust and enforcement.
The trust model and evidence format are documented in IETF Internet-Drafts including draft-sharif-agent-trust-enforcement and draft-sharif-agent-audit-trail. The OWASP Agentic Security Top 10 v1.0 cites this work.
Licensed BSL 1.1.
TRY IT
Live demo (real Go engine, real ECDSA signing): https://agentmesh-demo.fly.dev
Install:
helm install agentmesh oci://ghcr.io/razashariff/agentmesh --set certManager.enabled=true
kubectl label namespace prod agentmesh.io/inject=enabled
Product site: https://agentpassmesh.co.uk
IANA PEN: 66339
Built by CyberSecAI Ltd. Questions, feedback, enterprise licensing: contact@cybersecai.co.uk
Top comments (0)