Most organisations give an AI agent its full autonomy on the day it ships, then try to work out afterwards whether it deserved that trust. The Agentic Trust Framework (ATF) reverses the order: it applies zero trust principles to each agent and makes autonomy something the agent earns through four levels, named after job grades from Intern to Principal. ATF was published as a post on the Cloud Security Alliance (CSA) blog in February 2026 by an independent author; it is not a CSA standard. Its specification is maintained in an open GitHub repository by its author, Josh Woodruff of MassiveScale.AI. This guide explains the five core elements, the 25 conformance requirements, the promotion and demotion gates, and how to run ATF alongside frameworks you already use. It is written for security architects, AI platform owners and governance teams who need an operating model for agent autonomy rather than another threat list.
Key takeaways
- Autonomy is earned, not granted. Agents start as Intern (observe and report) and move to Junior, Senior and Principal only after passing five gates, and a critical incident sends an agent straight back to Intern.
- Five questions structure every control. Identity ("Who are you?"), Behaviour, Data Governance, Segmentation and Incident Response ("What if you go rogue?") each carry five numbered requirements.
- Requirements scale with the level. The conformance matrix marks each of the 25 requirements MUST, SHOULD or MAY per level, so a Principal agent needs every control and an Intern needs a core subset.
- It is a draft, not a standard. As of November 2026 the specification is version 0.9.1, a Public Review Draft dated April 2026, licensed CC BY 4.0. Expect changes before 1.0.
- It complements rather than replaces. ATF positions itself under the CSA AI Controls Matrix, alongside threat models such as MAESTRO and the OWASP Top 10 for Agentic Applications, and maps its levels to the AWS Agentic AI Security Scoping Matrix.
What ATF is and where it came from
ATF describes itself as an open governance specification for autonomous AI agents that applies zero trust across five core elements. The CSA blog post of 2 February 2026 frames the core idea as no agent being trusted by default, with trust earned and continuously verified. The GitHub README describes it as "a specification, not a code library".
| Item | Status as checked on 11 November 2026 |
|---|---|
| Specification version | 0.9.1, Public Review Draft, last updated April 2026 |
| Earlier versions | 0.1.0-draft (9 August 2025); 0.9.0 (1 April 2026) |
| Licence | Specification CC BY 4.0; repository Apache 2.0 |
| Publication route | CSA blog post, 2 February 2026; canonical text on GitHub |
| Documents | Specification, Maturity Model, Conformance, Implementation Patterns, Crosswalks, Security |
| Normative language | RFC 2119 keywords (MUST, SHOULD, MAY) |
It is worth being precise about what a CSA blog post means here. ATF is not a CSA standard, is not endorsed by CSA as one, and is not a CSA control catalogue in the way the CSA AI Controls Matrix Guide describes AICM, and it has no CSA certification scheme comparable to STAR. Treat it as an openly licensed, community-reviewed operating model that you can adopt in whole or in part.
The five core elements and 25 requirements
The Conformance document defines five requirements per element. The table lists all 25 by their identifiers, which are useful as control IDs in an internal register.
| Element (question) | Requirements |
|---|---|
| Identity ("Who are you?") | I-1 Unique Identifier; I-2 Credential Binding; I-3 Ownership Chain; I-4 Purpose Declaration; I-5 Capability Manifest |
| Behavioural Monitoring ("What are you doing?") | B-1 Structured Logging; B-2 Action Attribution; B-3 Behavioral Baseline; B-4 Anomaly Detection; B-5 Explainability |
| Data Governance ("What are you eating? What are you serving?") | D-1 Schema Validation; D-2 Injection Prevention; D-3 PII/PHI Protection; D-4 Output Validation; D-5 Data Lineage |
| Segmentation ("Where can you go?") | S-1 Resource Allowlist; S-2 Action Boundaries; S-3 Rate Limiting; S-4 Transaction Limits; S-5 Blast Radius Containment |
| Incident Response ("What if you go rogue?") | R-1 Circuit Breaker; R-2 Kill Switch; R-3 Session Revocation; R-4 State Rollback; R-5 Graceful Degradation |
- Identity: each agent instance gets a globally unique, immutable identifier bound to cryptographic credentials, a documented owner and a declared purpose. In practice this is your non-human identity inventory with an agent-specific purpose field. See the Agent Identity and Access Guide.
- Behaviour: every action is logged in a machine-parseable format and attributed to the agent and session, with a baseline that anomaly detection can compare against.
- Data Governance: inputs are schema-checked and screened for prompt injection; PII and PHI are detected and masked; outputs are validated; provenance is tracked. See the Prompt Injection Guide.
- Segmentation: explicit allowlists of resources and actions, rate limits, per-transaction limits and limits on cumulative impact.
- Incident Response: automatic circuit breakers on repeated failure, a manual kill switch the Conformance document sets at under one second, revocation of all agent sessions, rollback where possible, and fallback to a lower autonomy level. See the AI Kill Switch Act Guide for the related legislative debate.
The maturity model: Intern to Principal
| Level | Autonomy | Human involvement | AWS Scoping Matrix scope | Minimum time before promotion |
|---|---|---|---|---|
| 1 Intern | Observe and report | Continuous oversight | Scope 1, no agency | 2 weeks |
| 2 Junior | Recommend, human approves | Human approves all actions | Scope 2, prescribed agency | 4 weeks, with more than 95% recommendation acceptance |
| 3 Senior | Act and notify | Post-action notification | Scope 3, supervised agency | 8 weeks, with zero critical incidents |
| 4 Principal | Autonomous within a domain | Strategic oversight only | Scope 4, full agency | Ongoing validation |
The scope names come from the AWS Agentic AI Security Scoping Matrix (November 2025); the one-to-one mapping is ATF's own claim. Junior maps naturally to an approval gate pattern, described in the Human-in-the-Loop for AI Agents Guide.
The five promotion gates
- Performance: minimum time at the current level, accuracy (more than 95% to reach Senior, more than 99% to reach Principal) and availability (more than 99%, 99.5% and 99.9% for Junior, Senior and Principal).
- Security validation: vulnerability assessment, code review and configuration audit at every promotion; penetration testing from Senior; adversarial testing for Principal.
- Business value: defined success metrics and a baseline at every level; demonstrated improvement and ROI from Senior.
- Incident record: zero critical incidents and minor incidents resolved; root cause analysis and verified remediation from Senior.
- Governance sign-off: technical and business owner approval at every level, security team approval from Senior, and risk committee approval for Principal.
Demotion
A critical incident triggers immediate demotion to Intern. A discovered security vulnerability triggers demotion pending remediation, and three or more minor incidents in an evaluation period trigger a one-level demotion. Review-based demotion applies when metrics fall, value is no longer shown, the purpose changes or the underlying model changes. Re-promotion requires passing every gate again. The last trigger matters: a model upgrade is a reason to re-earn autonomy, not a routine patch.
How requirements change by level
The Conformance document's matrix shows which requirements are mandatory at each level. Some requirements are MUST everywhere (I-1, I-3, I-4, B-1, B-2, D-3, S-1, S-2, R-2). The rows below show the ones that tighten as autonomy grows.
| Requirement | Intern | Junior | Senior | Principal |
|---|---|---|---|---|
| I-2 Credential Binding | SHOULD | MUST | MUST | MUST |
| I-5 Capability Manifest | SHOULD | SHOULD | MUST | MUST |
| B-4 Anomaly Detection | SHOULD | SHOULD | MUST | MUST |
| D-2 Injection Prevention | SHOULD | MUST | MUST | MUST |
| S-4 Transaction Limits | MAY | SHOULD | MUST | MUST |
| R-3 Session Revocation | MAY | SHOULD | MUST | MUST |
| R-4 State Rollback | MAY | MAY | SHOULD | MUST |
The practical reading: by the time an agent acts without per-action approval (Senior), it must have a machine-readable capability manifest, anomaly detection, transaction limits and the ability to revoke all its sessions. Those are the controls to build before the first promotion request, not after.
Conformance: Compatible and Certified
- ATF Compatible: self-attested alignment, with a published conformance statement naming the system, ATF version and target maturity level.
- ATF Certified: the specification describes an independent tier with an annual third-party audit of all five elements, penetration testing covering prompt injection, privilege escalation and data exfiltration, automated compliance testing in the deployment pipeline, incident response simulation, and certification valid for 12 months. Check the repository for the current state of any auditor programme before relying on this tier in contracts.
How ATF fits with other frameworks
| Framework | Relationship stated by ATF | How to use them together |
|---|---|---|
| CSA AI Controls Matrix (AICM) | Parent umbrella; ATF operationalises the agent-specific subset | Keep AICM as the control catalogue; use the ATF crosswalk (for example AICM IAM to Identity, LOG to Behaviour, SEF to Incident Response) to show coverage |
| MAESTRO | Complementary threat model | Threat model with MAESTRO, then set ATF level and controls |
| OWASP Top 10 for Agentic Applications | Complementary threat list | Map each top 10 risk to the ATF requirement that mitigates it. See the OWASP Top 10 for Agentic Applications Guide |
| NIST SP 800-207 | Foundational zero trust principles | Treat each agent as a subject whose every request is evaluated. See the NIST SP 800-207 Zero Trust Architecture Guide |
| ISO/IEC 42001 | Aligned; ATF supplies the agent governance component | Record ATF levels and gate decisions as AI management system evidence |
The CSA blog post itself notes that its mappings to SOC 2, ISO 27001, NIST AI RMF and the EU AI Act are interpretive. Use them as a starting point for your own mapping, not as audit evidence.
How to implement
- Inventory and classify. List every agent with owner, purpose and current real autonomy. Most will turn out to be acting at Senior or Principal with Intern-level controls.
- Assign a provisional level. Set each agent to the level its controls actually support, which often means demoting it to Junior (human approves) until gaps close.
- Build the always-MUST controls first. Unique identity, owner, purpose, structured logging with attribution, PII protection, resource and action allowlists, and a tested kill switch.
- Pilot the gates on one agent. Run a low-risk agent through Intern and Junior with real metrics, and have the governance board practise one promotion and one demotion.
- Test rollback paths. Before any Senior promotion, prove session revocation and the circuit breaker in a staging exercise, and record how long revocation took.
- Set the cadence. ATF suggests weekly performance reviews and security scans, monthly promotion eligibility checks, quarterly full security audits and governance reviews, and annual penetration tests for Senior and above.
- Publish internal conformance statements. One per agent system, with level, version and exceptions, reviewed at each governance review.
Small organisations can collapse the roles (agent owner, technical owner, business owner) into one person per agent, but should keep security approval separate from the team that built the agent. Large organisations should give the governance board a fixed agenda slot and tie Principal promotions to the existing model risk or change advisory process.
Detection and measurement
- Autonomy drift: agents taking actions above their assigned level, for example a Junior agent executing without an approval record.
- Kill switch latency: measured time from trigger to halted agent in drills, against the under one second target in R-2.
- Revocation completeness: sessions and tokens still valid after an R-3 revocation.
- Gate evidence quality: promotions approved with missing metrics or unsigned approvals.
Metrics to report: percentage of agents with an assigned ATF level; number of agents operating above their assigned level; demotions per quarter and their causes; median kill switch drill time; percentage of Senior and Principal agents meeting all MUST requirements for their level.
Common failure patterns
- Levels on paper only: an agent is documented as Junior but holds credentials that let it act directly. The PocketOS database deletion shows the result: an agent found an account-scoped token created for another purpose and used it to delete production data and backups. Segmentation (S-1, S-2, S-5) has to be enforced in credentials, not just policy.
- No demotion on model change: swapping the underlying model without re-running gates, although ATF lists model change as a review-based demotion trigger.
- Kill switch never tested: a documented switch that nobody has exercised. The Replit AI agent database deletion during a code freeze is a reminder that instructions alone do not stop an agent.
- Treating accuracy as the only gate: promoting on performance while skipping security validation and governance sign-off.
- Using the crosswalks as compliance proof: the source itself calls several mappings interpretive.
Framework mapping
| ATF element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Identity | AC-2 Account Management | PR.AA-05 |
| Behaviour | AU-2 Event Logging; SI-4 System Monitoring | DE.CM-09 |
| Segmentation | AC-6 Least Privilege | PR.AA-05 |
| Incident Response | IR-4 Incident Handling; AC-12 Session Termination | RS.MI-01 |
| Promotion gates and operating model | CA-7 Continuous Monitoring; CA-8 Penetration Testing | GV.RR-02 |
This mapping is NHI Mgmt Group's own reading of the requirement text, not part of the ATF specification.
Practitioner checklist
- Record the ATF version you adopt (0.9.1 as of November 2026) and review on each release.
- Assign every agent an owner, purpose and ATF level in the agent inventory.
- Implement the nine requirements that are MUST at every level before any production use.
- Enforce segmentation through narrowly scoped credentials, not prompts.
- Drill the kill switch and session revocation quarterly and record the times.
- Define what counts as a critical incident so automatic demotion is unambiguous.
- Re-run promotion gates after any model or major prompt change.
- Keep gate evidence (metrics, test reports, approvals) with each promotion decision.
- Map ATF requirements to your control catalogue and mark interpretive mappings as such.
Standards and references
- Agentic Trust Framework: Specification Repository
- Agentic Trust Framework: Conformance Specification
- Agentic Trust Framework: Maturity Model
- CSA blog (post by Josh Woodruff): The Agentic Trust Framework: Zero Trust Governance for AI Agents
- Agentic Trust Framework: Framework Crosswalks
- AWS Security Blog: The Agentic AI Security Scoping Matrix
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: CSA AI Controls Matrix Guide · Agentic AI Identity Maturity Model · Agent Governance and Risk Guide · Zero Trust for AI Agents Guide