The Cloud Security Alliance released the Agentic Trust Framework (ATF) as a zero-trust security model for AI agents. It's an important spec. But it shipped as documentation only — no running code, no reference implementation, no way to test it against real agents. We decided to build one. This is how we did it, what we learned, and how you can validate it yourself.
The Problem: AI Agents Have No Zero Trust
Traditional zero trust (NIST SP 800-207) was designed for human users accessing corporate resources. It answers questions like: "Is this person authorized to access this database?" and "Is this session still valid?"
AI agents break every assumption in that model. They don't have sessions — they have continuous autonomous loops. They don't access one resource — they chain 30 API calls in sequence. They don't have a fixed intent — they adapt their actions based on intermediate results. And when they go wrong, they don't just show an error page — they can exfiltrate data, inject prompts into other agents, and make irreversible real-world decisions.
The ATF addresses this by defining 5 trust elements that every agent must satisfy:
🔐 Element 1 — Identity
Who is this agent? Who owns it? What is its declared purpose?
👁️ Element 2 — Behavior
Is the agent doing what it claims? Can we prove it cryptographically?
🛡️ Element 3 — Data Governance
What data goes in? What comes out? Is PII protected?
📊 Element 4 — Segmentation
Where can this agent go? What can it access? Who can it talk to?
⚔️ Element 5 — Incident Response
What happens when the agent goes rogue? How fast can we contain it?
The spec is well-structured. But implementing it requires solving real engineering problems that the spec intentionally leaves open. That's what we built.
The Architecture: 12 Services, 5 Elements
Our reference implementation isn't a monolith — it's a portfolio of 12 independently deployed services, each covering part of the ATF. This mirrors how enterprises actually work: different teams own different trust functions.
| ATF Element | Service | What It Does |
|---|---|---|
| Identity | Agent Trust Verifier | DID:web resolution, Verifiable Credential issuance (JWT-VC) |
| Identity | Agent Trust Protocol | Reputation scoring, compliance tracking, maturity model engine |
| Behavior | Veracity Core | Ed25519 Proof of Execution, hash-chain linking, Solana anchoring |
| Behavior | Agent Chain Anchor | Chain-agnostic blockchain anchoring for audit logs |
| Data Governance | ConvoGuard AI | Sub-20ms ONNX firewall — prompt injection, PII, EU AI Act trails |
| Data Governance | Agent Fairness Auditor | Bias detection, immutable audit logging |
| Segmentation | ATF Segmentation Engine | Policy-as-code, rate limiting, A2A communication controls |
| Segmentation | Agent Deadline Enforcer | SLA contract enforcement, breach detection |
| Segmentation | Agent Semantic Aligner | Cross-domain vocabulary translation between agents |
| Incident Response | Agent Pentest | 41 adversarial attack vectors, Safety Score (A–F) |
| Incident Response | ATF Incident Service | Circuit breaker, kill switch, auto-containment |
Every service is open source (MIT), tested, and deployed. You can clone any of them and run them independently. The unified facade repository ties them together with a typed registry and 25 contract validation tests.
What the Spec Doesn't Cover (and We Built)
The ATF spec defines what trust elements exist. It doesn't specify how to implement them at runtime. These are the three biggest gaps we filled:
1. Maturity Model Runtime
The spec describes agent maturity levels (Intern, Junior, Senior, Lead, Director) but doesn't define how an agent earns promotion. We built a runtime engine with 5 concrete Promotion Gates:
Each gate is independently verifiable. The performance gate checks accuracy and availability over a configurable window. The security gate requires a pentest score of B or higher from the Agent Pentest tool. The business value gate requires explicit sign-off from a human business owner. This forces organizations to define their own thresholds while providing the scaffolding to evaluate them.
2. Segmentation & Policy Engine
The spec says agents should be segmented by role and permissions. It doesn't say how. We implemented a policy-as-code engine that evaluates access requests in real time:
The engine uses the agent's maturity level, current rate limit status, and resource classification to make access decisions. Denied requests fall back to the next lowest permission level automatically — an intern denied write access still gets read access.
3. Incident Response Circuit Breaker
When an agent starts behaving anomalously, you need to contain it before the damage spreads. We built a circuit breaker with three states (CLOSED → OPEN → HALF_OPEN) that automatically isolates agents exceeding a failure threshold, with configurable cool-down periods and gradual re-admission.
How to Validate It
We don't ask you to trust us. We ask you to run the tests:
The contract tests verify: all 5 ATF elements have at least one implementation, no duplicate repos, all services have valid URLs, required capabilities exist per element, every non-infrastructure service has a documented ATF mapping, all promotion gates are represented, and deployed services use HTTPS.
Where This Goes Next
The ATF is a v0.1.0-draft. Our implementation will evolve with the spec. Here's what we're working on:
- Interactive demo — Watch an agent navigate all 5 elements live
- Cross-service integration tests — End-to-end flows that prove the 12 services work together
- Enterprise pilot — Running the stack against real production agents with a design partner
- ATF v0.2 alignment — As the spec evolves, our implementation tracks
The spec says what trust looks like. The code proves it works. Both are necessary. Neither is sufficient alone.
Get Involved
Everything is MIT-licensed and ready to use:
- 📦 Reference Implementation — Start here
- 🎮 Interactive Demo — See it in action
- 📄 ATF Spec — Read the source document
- 🔐 agent-pentest on npm — Test your own agents
If you're building agent infrastructure, we'd like to talk. We're not looking for collaborators for the sake of collaboration — we're looking for teams running agents in production who need trust guarantees that aren't just slideware.