The CSA Agentic Trust Framework, in plain terms.
The Cloud Security Alliance put a name to what agents break in zero trust: an agent is neither a user nor a service, and the old identity models don't fit it. Here is what the framework says, and what it asks you to build.
The short version
- The CSA Agentic Trust Framework (ATF) is the Cloud Security Alliance's model for applying zero trust to AI agents: verify identity, scope authority and prove behavior, per action.
- Its starting premise matches the field: an agent is neither a human user nor a static service, so human IAM and service accounts both fit it badly.
- The framework is principles, not a product. The work it implies is concrete: agent identity, least privilege per action, and an auditable record of what happened.
- In practice that lands on three things you can build: authorization before the action, signed policy, and verified evidence after.
The CSA Agentic Trust Framework is the Cloud Security Alliance's attempt to answer a question zero trust never had to face before: how do you apply "never trust, always verify" to something that acts on its own, chains tools together, and holds credentials that belong to a person or a system rather than to itself. It is a governance model for AI agents, and its value is that it names the mismatch precisely rather than bolting agents onto a human identity model.
If you are evaluating it, the useful move is to separate what the framework asserts from what it asks you to build. The assertions are sound and widely shared. The build is where most teams have nothing yet.
What problem does the framework actually address?
It addresses the fact that an agent fits none of the identity categories security teams already manage. A human has a login, sessions and an IAM role. A service has a static account and a narrow, predictable job. An agent has neither: it authenticates as something else, its behavior varies per task, and it composes actions across tools nobody pre-approved as a set. Zero trust assumes you can pin identity to a request and scope it. With agents, the identity is borrowed and the scope is emergent, which is exactly the gap the framework exists to close.
Zero trust was built for callers you can identify and scope. An agent borrows its identity and improvises its scope. That is the whole problem in one sentence.
What does zero trust mean for an agent?
It means the same three demands zero trust always made, re-expressed for something autonomous. Verify identity: know which specific agent instance is acting, and on whose behalf, not just which connection opened. Scope authority: grant the minimum capability the task needs, per action, not a blanket token that covers everything the agent might ever do. Prove behavior: keep a record that lets you reconstruct what the agent did and check it against what it was allowed to do. The framework organizes its principles around these; the language differs, the spine is this.
Where does the framework stop, and the building begin?
The framework is deliberately principles rather than implementation, which is correct for a standards body and insufficient for a team on a deadline. "Scope authority per action" is the right instruction; it does not tell you that OAuth scopes attach to operators rather than operations, or that a shared service-account token in a file is the thing you have to kill first. The framework points; you build.
Three concrete pieces carry most of the weight, and each maps to work we have written up in detail:
- Authorization before the action. Decide what an agent may do before it acts, deterministically, with no model in the enforcement path. This is the difference between governing agents and watching them, covered in Detection versus authorization.
- Signed, verifiable policy. The rules an agent runs under have to be tamper-resistant and provable, or "we scoped it" is just a claim. See why policy for agents must be signed.
- Verified evidence after. A per-action record of what happened, checked against the policy that was in force, is how "prove behavior" becomes real. See agent work needs evidence, not trust.
How does the ATF sit next to OWASP and the protocol work?
It complements them rather than competing. The OWASP work on agentic applications catalogs what goes wrong; the CSA framework organizes how to govern against it; the protocol layer (MCP's authorization hardening, A2A's signed Agent Cards) supplies primitives, mapped in the identity stack for AI agents. A team adopting agents does not pick one. The framework gives you the governance vocabulary to explain the controls the other two make buildable.
The takeaway
The CSA Agentic Trust Framework is worth reading because it states the agent identity problem cleanly and gives you the governance language for it. Treat it as the map, not the vehicle: verify identity, scope authority per action, prove behavior, and then go build the authorization, signed policy and evidence that turn those principles into something an auditor can check.
Oktsec runs that loop for approved agent environments: authorization before the action, signed policy, verified evidence back. See Control →