Policy Commitment Attestation (PCA)

What PCA is

A Policy Commitment Attestation is a signed W3C Verifiable Credential that binds an AI agent — identified by a Decentralized Identifier (DID) — to a specific governance statement at a declared maturity tier, with cryptographically-linked evidence artifacts.

A PCA credential answers four questions, verifiably and externally:

1. Which agent committed? (subjectDid — e.g. did:web:dictiva.com:agents:code-reviewer)
2. To what statement, at what version? (statementId + canonical SHA-256 hash of the body at issuance time)
3. At what maturity tier? (T1 Read → T6 Enforced — six cumulative tiers)
4. Backed by what evidence? (memory file, ADR, skill definition, hook reference, ODRL refusal rule, etc.)

Anyone holding the credential can verify it cryptographically against the tenant's public DID document — no Dictiva account required.

What kind of agent does this apply to? Not every AI helper is a PCA principal. Subagents that Claude Code or Codex spawn for a single task — short-lived, no name, no operator — are tools, not principals; they don't need attestations. PCA targets long-lived, addressable agents: a code-reviewer bot, a SEO research agent, a customer-success agent. See Agent Identity for Real Teams for the full taxonomy and AGENTS.md / .claude/ templates.

Why this matters

When an AI agent acts inside a regulated organization, "how do you prove what governance it followed?" The traditional answers — ask the agent, read the logs — aren't forensically sound and don't survive an external audit. PCA produces a portable artifact that:

• Cryptographically binds an agent to a statement at a specific moment
• Survives outside Dictiva — any verifier with W3C VC tooling can validate it
• Composes recognized standards (W3C VC + DID + Status List 2021 + ODRL + in-toto + OSCAL) rather than inventing a proprietary scheme
• Maps to regulatory frameworks — EU AI Act Article 14, NIST OSCAL, ISO/IEC 42001

PCA is Dictiva's contribution candidate to the Linux Foundation Agentic AI Foundation (AAIF) — alongside MCP, AGENTS.md, and goose. The full public spec lives at policycommitment.dictiva.com.

The Commitment Maturity Ladder

The novel contribution. Six cumulative tiers separating what an agent has done from what scope it operates within from what the runtime physically blocks:

Tiers are cumulative — a T4 credential must also satisfy T1, T2, and T3 floors. The service rejects issuance attempts whose evidence doesn't meet the cumulative requirement, with a clear Tier floor not satisfied error.

Auditors and regulators ask different questions at each tier: T1–T4 ("the agent has codified this") differ structurally from T5 ("its scope is bounded by these rules") and T6 ("the runtime physically blocks violations"). The ladder makes the answers structurally distinguishable rather than buried in free-text annotations.

Standards composed

Each layer is externally governed by a recognized standards body. Dictiva's contribution is the binding pattern (the maturity ladder) and the integration glue — not the cryptography.

How verification works

A third party with the credential can verify it without trusting Dictiva:

1. Resolve the issuer DID. The credential's issuer field is did:web:dictiva.com:tenants:{tenantId}. The verifier fetches https://dictiva.com/tenants/{tenantId}/did.json to retrieve the public key.
2. Check the cryptographic signature using standard W3C VC Data Integrity verification.
3. Check the validity window (validFrom ≤ now ≤ validUntil).
4. Check revocation. The credential's credentialStatus field references a Status List 2021 credential at https://dictiva.com/api/governance/status-lists/{listId}. The verifier fetches the list, decodes the bitstring, and checks the bit at statusListIndex. If the bit is set, the credential is revoked.
5. Check evidence digests. Each evidence entry with a digest.sha256 claim can be fetched and re-hashed; a drifted artifact invalidates the credential.

All five checks use off-the-shelf W3C VC tooling. Dictiva's API also exposes a convenience POST /api/agent/attestations/verify that runs all five against the requesting tenant.

Lifecycle

        ┌─────────────────────────────────────────────────────────┐
        ↓                                                          │
   ┌─────────┐    ┌─────────┐    ┌──────────┐    ┌─────────────┐  │
   │  Issue  │ →  │  Live   │ →  │  Verify  │ →  │ Revalidate  │ ─┘
   └─────────┘    └─────────┘    └──────────┘    └─────────────┘
        │              │              │
        │              ↓              │
        │         ┌─────────┐         │
        │         │ Revoke  │ ←───────┘
        │         └─────────┘         (verifier discovers drift /
        │              │               agent decommissioned)
        │              ↓
        │         ┌──────────────────┐
        │         │ Status List bit  │
        │         │ flipped + soft   │
        │         │ revoked_at set   │
        │         └──────────────────┘
        ↓
   Default validity: 90 days
   Revalidation window: last 7 days before expiry

• Issue: agent (or operator on agent's behalf) calls POST /api/agent/attestations with the statement reference, tier, evidence, and chain of authority. Dictiva signs a VC with the tenant's Ed25519 key, persists it, and allocates a status list bit.
• Verify: anyone calls POST /api/agent/attestations/verify (or runs verification themselves with W3C VC tools).
• Revoke: when the agent is decommissioned, the underlying statement materially changes, or evidence drifts, an authorized user calls POST /api/agent/attestations/:id/revoke. Both the soft revoked_at audit column AND the public Status List 2021 bit flip in lock-step. The status list is re-signed.
• Revalidate: a nightly background sweep re-runs verify on every credential within 7 days of expiry. If verify still passes, expiry extends by the credential's revalidationInterval (default 90 days). If verify fails, a needs_revalidation governance event surfaces — humans decide whether to re-issue, revoke, or let the credential lapse naturally.

Permissions (RBAC)

Three permissions, distinct from the existing attestation:* namespace (which means human campaign-based ack):

API-key tenants use these permissions through the standard Bearer-token scope mechanism. See the API Keys guide.

Public endpoints (no auth)

These three routes implement W3C did:web and Status List 2021 resolution. They must be publicly reachable per spec; cache headers are set for verifier-storm resilience.

Where to go next

• Agent Identity for Real Teams — what counts as a PCA-grade agent, where they live, and AGENTS.md / .claude/ templates by team size
• PCA API Reference — every endpoint, every error code, every request/response shape
• MCP Governance Server Guide — the agent-facing wrapper that exposes PCA via MCP tools
• Agent API Integration Guide — quickstart for connecting custom agents
• Public spec: policycommitment.dictiva.com
• Composition decision: ADR-040 (in repo)
• Substrate decision: ADR-042 (in repo) — why DigitalBazaar over Attestix

For the deep engineering reference (data model, file map, security model, operational runbook), see docs/architecture/policy-commitment-attestation.md in the source repository.