PERMISSION/PROTOCOL
← Compliance

CSA Agentic Trust Framework

The ATF requires the approval gate. This is it, with receipts.

The Agentic Trust Framework says agents must earn autonomy in four levels. At the Junior level, where most production agents live today, the rule is simple: the agent can recommend, but a human must approve before anything executes. The ATF requires that gate. It doesn't tell you how to build it, and it doesn't tell you how to prove to an auditor that it fired on every action. Permission Protocol is both: the approval gate as infrastructure, and a cryptographically signed receipt for every decision.

About this mapping

Mapped against ATF v0.9 (Public Review Draft, April 2026), published by the Cloud Security Alliance under CC BY 4.0 and maintained at github.com/massivescale-ai/agentic-trust-framework. Permission Protocol is an independent implementation and is not affiliated with or endorsed by CSA or MassiveScale.AI. Coverage claims were audited against the implementation on 2026-08-11; every implemented claim cites code in the full audit document.

The honest scorecard.

25 requirements across five elements. Permission Protocol is deliberately a point control, not a platform: it composes with your IdP, your gateway, and your runtime security.

6

Implemented

PP directly satisfies the requirement for approval-gated actions

8

Evidenced

PP produces the audit artifact that proves the requirement is operating

11

Out of scope

Belongs to another layer of your stack: IAM, runtime security, gateway

Where Permission Protocol sits in ATF.

1: Intern

Read-only agent

Not needed (no impactful actions)

2: Junior

Human approves all actions

Core: PP is the approval gate + receipt

3: Senior

Post-action notification

Evidence: receipt history justifies promotion; PP gates the exceptions

4: Principal

Strategic oversight

Fallback: demotion re-enables the PP gate (see R-5)

ATF's Junior-to-Senior promotion requires 4 weeks of operation with over 95% recommendation acceptance, and governance sign-off that criteria were “genuinely met, not just checked off.” Permission Protocol's receipt log is that evidence: every recommendation, every approval or rejection, every approver, timestamped and signed.

Element 1: Identity

“Who are you?”

I-1Unique Identifier
Evidences

Every receipt references the agent's unique ID; PP consumes identity from your IdP rather than issuing it.

I-2Credential Binding
Implements

PP binds the decider's identity inside the receipt signature: signer ID, display name, authentication method, and attribution confidence are part of the signed payload, not a database join. The human half of credential binding that agent-IAM tools don't cover.

I-3Ownership Chain
Evidences

Receipts name the decider accountable for each authorization decision, signed: partial ownership evidence. PP does not maintain the agent-to-owner registry or delegation records the requirement itself asks for; that registry gap keeps this at evidence level (it lives in your agent registry or IdP).

I-4Purpose Declaration
Evidences

The Decision Brief presented at approval time records the declared purpose of each action alongside the sign-off.

I-5Capability Manifest
Out of scope

Agent registry / IdP layer.

Element 2: Behavioral Monitoring

“What are you doing?”

B-1Structured Logging
Implements

Every gated action yields a structured, machine-parseable record: decision, reason codes, policy version, evaluation chain, exportable for audit. Decision receipts (approvals and denials) are cryptographically signed.

B-2Action Attribution
Implements

Each gated action is tied to agent identity, run context, and the decider who authorized it, with the decider bound inside the receipt signature. Deploy-gate receipts bind the individual approver; SDK execute-lane receipts bind the decider role class with the individual recorded on the approval record.

B-3Behavioral Baseline
Out of scope

Runtime monitoring layer.

B-4Anomaly Detection
Out of scope

Runtime monitoring layer. Approval-rate trends in PP can feed it.

B-5Explainability
Evidences

The Decision Brief captures the agent's reasoning and the human's decision context: retrievable rationale per action.

Element 3: Data Governance

“What are you eating? What are you serving?”

D-1 to D-4Validation / injection / PII / output
Out of scope

Gateway and content-scanning layer.

D-5Data Lineage
Evidences

The receipt chain is authorization lineage: which approved decision produced which action.

Element 4: Segmentation

“Where can you go?”

S-1Resource Allowlist
Out of scope

IAM / policy engine.

S-2Action Boundaries
Implements

PP's policy defines which action classes require human approval. The boundary between “agent may act” and “human must sign” is explicitly enumerated and enforced.

S-3Rate Limiting
Out of scope

Gateway layer.

S-4Transaction Limits
Implements

Approval thresholds by action impact: production deploys, production writes, irreversible actions, and protected-path changes (database migrations, CI workflows, infrastructure, secrets) are hard-gated to a human signer. Monetary and volume caps are not in scope; see the honesty section below.

S-5Blast Radius Containment
Out of scope

Architecture / network layer.

Element 5: Incident Response

“What if you go rogue?”

R-1Circuit Breaker
Evidences

Repeated rejections are the early-warning signal; PP surfaces them as repeated-denial notables in the activity digest (threshold: 3 or more per capability and reason).

R-2Kill Switch
Implements

Global, per-agent, and per-capability freeze block all PP-routed actions at the evaluation choke point: fresh decisions are denied with a signed receipt, and existing approvals cannot be redeemed while frozen (preserved, not consumed). The check is per-request and uncached, so a freeze takes effect on the next evaluation, in under a second, and every freeze or pause action is itself receipted. It terminates agency, not process: actions that do not route through PP are uncovered.

R-3Session Revocation
Out of scope

IdP layer.

R-4State Rollback
Evidences

Receipts tell responders exactly which actions were authorized, by whom, when: the map for what to roll back.

R-5Graceful Degradation
Evidences

Demotion to Junior means re-enabling human approval on every action, and PP is the gate a demoted agent lands on. Its receipts prove the agent is running gated. PP does not implement ATF's autonomy levels or automatic fallback; demotion is a policy change you make.

Honesty is the point of a conformance mapping

What Permission Protocol does not do.

Permission Protocol does not:

  • ·provision or rotate agent identities
  • ·maintain the agent-to-owner registry or delegation records an ownership chain requires
  • ·monitor runtime behavior
  • ·scan inputs and outputs
  • ·enforce network segmentation
  • ·terminate agent processes (its kill switch freezes PP-routed agency, not the process)
  • ·enforce monetary or volume transaction caps
  • ·implement autonomy levels and automatic demotion

If a vendor claims one product covers all 25 ATF requirements, ask harder questions.

Signature scope, precisely

Every decision receipt is Ed25519-signed at the moment the decision lands, with the decider bound inside the signed payload; any post-signing edit to a signed field fails verification. Attribution granularity differs by lane: deploy-gate receipts bind the approver's individual identity, authentication method, and attribution confidence. Receipts returned by the SDK's execute endpoint bind the decider as a role class (policy / human / founder); the individual approver is recorded on the approval record but is not yet bound inside the signature on that lane. Individual-identity binding on the SDK lane is the remaining attribution roadmap item.

Why this matters right now.

84%

of organizations could not pass a compliance audit focused on agent behavior or access controls, per a CSA/Strata survey. Only 23% have a formal agent identity strategy.

Rubber stamps are the named risk.

ATF's own Junior-level risk register names approval fatigue and rubber-stamping as the primary risks. Unsigned, unlogged approvals are indistinguishable from rubber stamps. Signed receipts make each approval a deliberate, attributable, auditable act.

Self-attestation needs backing.

ATF Compatible self-attestation requires documenting how each requirement is met. For the human-approval requirements, “we use Permission Protocol; here are the receipts” is a one-line answer with cryptographic backing.

Sample ATF conformance statement.

For a PP-gated deployment targeting the Junior maturity level. Adapt the bracketed fields to your stack.

Organization: [Your org]
Implementation: [Agent system] + Permission Protocol
ATF Version: 0.9.0
Target Maturity Level: Junior
Assessment Date: [Date]

Element 1 - Identity:          4/5 covered (I-5 via agent registry)
Element 2 - Behavior:          3/5 covered (B-3, B-4 via [runtime vendor])
Element 3 - Data Governance:   1/5 covered (D-1-D-4 via [gateway vendor])
Element 4 - Segmentation:      2/5 covered (S-1, S-3, S-5 via [IAM/gateway])
Element 5 - Incident Response: 4/5 covered (R-3 via [IdP])

Notes: Human approval gate and audit evidence provided by
Permission Protocol; signed receipts retained for all
approval-gated actions and available to auditors. "Covered"
counts requirements PP implements or evidences; see the
mapping for which is which.

Stand up the Junior-level gate in minutes.

The approval gate, the signed receipt, and the audit trail the ATF asks for: blocked action to signer decision to receipt, end to end.

SDK quickstart Full audit document All frameworks