What Is the CSA Agentic Trust Framework and How Do You Check Conformance in Python?

April 9, 2026 · Jason Shotwell · 11 min read

Last updated: April 17, 2026

The CSA Agentic Trust Framework (ATF) is the first industry standard that defines how AI agents prove identity, declare purpose, and earn progressively more autonomy through a four-stage maturity model. Version 0.9.1 of the public review draft is already being referenced in enterprise procurement checklists. We shipped native ATF conformance support in air-trust v0.4.0, making it the first open-source library to offer a single function call that checks all five Identity Core Elements and returns an auditor-ready report.

After three enterprise buyers referenced ATF maturity levels in procurement conversations in Q1 2026 alone, the signal is clear: this framework is becoming a procurement gate, not just a nice-to-have. This guide walks through what the framework requires, how the maturity ladder works, and how to prove conformance from Python code.

What Is the CSA Agentic Trust Framework?

The CSA Agentic Trust Framework is a Cloud Security Alliance specification that answers three questions the EU AI Act leaves open: who is the agent, what is it allowed to do, and how much autonomy has it earned? The framework sits underneath compliance regimes like the EU AI Act and ISO 42001 - it does not replace them. It tells you how to identify and progressively promote individual agents so that the broader compliance machinery has something durable to attach to.

There are two structural pieces:

• Identity Core Elements. Five requirements, labeled I-1 through I-5, that describe the minimum identity surface every agent must expose.
• Maturity levels. Four progressive tiers - Intern, Junior, Senior, Principal - that gate how much autonomy an agent is trusted with. Each level raises the bar on which core elements are MUST, SHOULD, or MAY.

An agent starts at Intern, proves itself against a narrow set of MUSTs, and graduates upward. The maturity ladder borrows directly from how human organizations grant autonomy to junior employees - and it is the framework's most interesting design decision.

What Are the Five Identity Core Elements (I-1 to I-5)?

Every agent needs to expose five identity attributes before it can claim any ATF maturity level. These are the minimum identity surface the framework requires, and they map directly to fields on the AgentIdentity dataclass that air-trust already uses for Article 14 identity binding in audit chains.

I-4 and I-5 are new additions in v0.4.0 - the other three already existed to support EU AI Act Article 14 identity binding. Adding purpose and capabilities took about twenty lines of dataclass code and zero new dependencies. This is the cheapest compliance upgrade you will ever ship.

How Does the Maturity Ladder Work?

The ATF maturity ladder gates how much autonomy an agent earns based on how many of the five core elements it satisfies at the MUST level. An agent that is missing a Purpose Declaration (I-4) cannot even be an Intern. An agent with identifiers and an owner but no capability manifest is stuck at Intern. This is deliberate - it forces operators to write down what an agent does before trusting it with bigger jobs.

The promotion logic is: you cannot claim a higher level than the most restrictive set of MUSTs you satisfy. In practice, this means your CI pipeline can gate deployments on maturity level - if the agent does not meet the requirements for its target level, the deployment fails with an explicit list of what to fix.

How Do You Check ATF Conformance in Python?

Install air-trust v0.4.0, build an AgentIdentity with the two new ATF fields (purpose and capabilities), and call a single function. The URN (I-1), credential fingerprint (I-2), and ownership chain (I-3) are derived automatically from the fields you were already providing. You only write down I-4 and I-5.

from air_trust import AgentIdentity
from air_trust.atf import conformance_statement, level_compliant

identity = AgentIdentity(
    agent_name="customer-search",
    owner="[email protected]",
    agent_version="1.0.0",
    org="AIR Blackbox",
    purpose="Answer customer questions from product documentation",
    capabilities=["search:docs", "llm:respond"],
    atf_level="intern",
)

print(conformance_statement(identity))
print("Intern compliant:", level_compliant(identity, "intern"))

Running that prints a full auditor-ready report and a pass/fail summary.

How Do You Promote an Agent to a Higher Maturity Level?

Promoting an agent does not require new APIs. You change the atf_level field and re-run the conformance check. The gaps() helper returns a list of tuples identifying exactly which core elements are missing so developers know what to fix before promotion.

identity.atf_level = "principal"

if not level_compliant(identity, "principal"):
    from air_trust.atf import gaps
    for req_id, reason in gaps(identity, "principal"):
        print(f"  {req_id}: {reason}")

This is how you wire ATF checks into a CI pipeline: gate a deployment on gaps(identity, target_level) == []. If it fails, the log tells developers exactly which core element to add.

How Do You Run ATF Checks from the Command Line?

For operations teams who do not want to write Python, air-trust v0.4.0 ships a CLI subcommand. It accepts either explicit flags or a JSON config file and emits either a human-readable statement or JSON. The exit code is zero on pass and one on fail, so it works as a CI gate.

python -m air_trust atf \
    --name customer-search \
    --owner [email protected] \
    --org "AIR Blackbox" \
    --purpose "Answer customer questions from product docs" \
    --capabilities "search:docs,llm:respond" \
    --level intern

Sample output:

CSA Agentic Trust Framework (ATF) Conformance Statement
============================================================
Agent:        customer-search
URN:          urn:agent:air-blackbox:customer-search:0.0.0
Target level: intern
Actual level: principal

  I-1  Unique Identifier      [MUST  ]  PASS
  I-2  Credential Binding     [SHOULD]  PASS
  I-3  Ownership Chain        [MUST  ]  PASS
  I-4  Purpose Declaration    [MUST  ]  PASS
  I-5  Capability Manifest    [SHOULD]  PASS

All MUST requirements for 'intern' level are satisfied.

Pipe it through --format json to feed the result into a compliance dashboard or an Article 11 technical documentation bundle.

How Does ATF Layer on Top of the EU AI Act?

The two frameworks solve different problems and are designed to compose - you do not have to choose one or the other. The EU AI Act tells you what your system must do: run risk management (Article 9), govern data (Article 10), keep technical documentation (Article 11), log decisions (Article 12), provide transparency (Article 13), enable human oversight (Article 14), and stay robust (Article 15). The ATF tells you how each individual agent inside that system should identify itself and earn trust.

An EU AI Act Article 14 audit trail where every entry carries an ATF-conformant agent identity is strictly stronger than either standard alone and satisfies both regimes at once. In air-trust v0.4.0, the same AgentIdentity object that feeds the HMAC-SHA256 audit chain also carries the ATF fields. One object, two regimes. If you already had Article 14 wiring from an earlier version, you get ATF conformance almost for free - just add purpose and capabilities.

How Do External Identity Providers Work with ATF?

The ATF explicitly allows external identity binding - a local URN plus a pointer to an external registry that can attest to the agent's identity. air-trust v0.4.0 exposes this as the external_id field on AgentIdentity. The design is intentionally provider-agnostic: AgentLair handles, did:web: URIs, and custom HTTP registries all work.

identity = AgentIdentity(
    agent_name="research-bot",
    owner="[email protected]",
    org="AIR Blackbox",
    purpose="Summarize academic papers",
    capabilities=["search:arxiv", "llm:summarize"],
    external_id="[email protected]",  # external registry handle
    atf_level="junior",
)

The core conformance check does not care where the external ID resolves - it only cares that one is declared. A provider adapter module is on the roadmap.

What Are the Limits of the Current Implementation?

v0.4.0 implements the Identity core element only. The broader ATF draft also covers Agent Actions, Agent Tools, Agent Governance, and the promotion gate machinery. Those are on the roadmap for v0.5.0 and v0.6.0. The Identity element is the right place to start because every other element of the framework assumes a stable agent identity exists first.

Three reasons to implement now rather than waiting for the spec to finalize:

• The core elements are stable. I-1 through I-5 have been present since the earliest drafts. The review process is unlikely to change what a unique identifier or an ownership chain looks like.
• Conformance claims mature with the framework. A library that implements the draft today will have running code the day v1.0 lands. Libraries that wait until v1.0 will ship a quarter late.
• Enterprise procurement teams are already asking. Having a conformance statement you can attach to an Article 11 technical documentation bundle shortens the sales cycle.

None of this requires a cloud service or a subscription. The entire conformance module is local, deterministic, and open source under the same Apache 2.0 license as the rest of air-trust.