A security engineer who has to explain on Friday why an agent got write access to the ticket queue on Monday needs a document she can point at. Of the five questions the Cloud Security Alliance frames as the whole of agent governance, its published post works through two: Identity, meaning a verified and auditable record of who owns an agent and what it claims to do, and Behavior, meaning continuous monitoring with anomalies flagged for review [5][6][7]. The post details controls for two of the five elements it names, leaving three without any stated controls [13].
The concrete part is the authorization ladder sitting under the identity question. Initial deployments get JWT authentication with role assignment. Agents moving up add OAuth2 or OIDC for approval workflows, attribute-based access control for dynamic authorization, and policy-as-code so the rules are auditable and testable [8]. That is a gate an operator can write into a change record: an agent does not reach the level where it acts without a human approving each action until its permissions exist as code that a test can fail.
CSA asserts that organizations can progress agents through increasing levels of autonomy with clear criteria and controls at each stage [3], but the post does not number the levels or state what passing one looks like [15]. The canonical specification and implementation guidance live in the ATF GitHub repository [2]. So the artifact a deployment gate would cite is in source control, and the announcement is the reading list.
For teams already tracking OWASP's agentic work, the useful piece is the positioning. CSA puts MAESTRO on the question of what could go wrong and ATF on the question of how control is maintained, and says ATF operationalizes mitigations from the OWASP Top 10 for Agentic Applications published in December 2025, alongside alignment with the OWASP Agentic Security Initiative and CoSAI [10]. That turns the framework choice from a bake-off into a layering exercise.
The framework draws on Zero Trust for agents, from Kindervag's original architecture and NIST 800-207, on the principle that no agent is trusted by default regardless of claimed capability and that trust is earned through observed behavior [4]. In practice, that means an identity record per agent with a named owner, structured logging, then LLM-specific tracing over prompt chains and statistical anomaly detection [6][9]. Most teams already owe an auditor the first two. What the material does not contain is any named organization running ATF, or any reported outcome from a deployment gated on it [14].
The test worth applying to your own inventory needs two columns, not a maturity chart. For every agent in production, can you produce an identity record naming its owner and purpose, and can you run a query showing what it did last week [6][9]? Sort the inventory by those two answers. Anything with neither is already operating above the first rung of a ladder whose upper rungs assume attribute-based access control and testable policy [8], and the level definitions you would use to move it back down are in the ATF GitHub repository [2].
