Proof of Continuity for Compliance: EU AI Act, SOC2, and Beyond

Security teams don’t adopt new infrastructure because it’s elegant. They adopt it because it solves problems that keep them up at night—and increasingly, those problems are regulatory.

This post maps Proof of Continuity to specific compliance requirements. Not marketing claims—actual control mappings that you can show to auditors.

EU AI Act: Article 14 and Human Oversight

The EU AI Act takes effect August 2026. Article 14 mandates “effective human oversight” for high-risk AI systems. The key requirements:

High-risk AI systems shall be designed and developed in such a way that they can be effectively overseen by natural persons during the period in which the AI system is in use.

What “effective oversight” requires:

Ability to understand the AI system’s capabilities and limitations
Ability to monitor operation and detect anomalies
Ability to interpret outputs correctly
Ability to decide not to use the system or override its outputs
Ability to interrupt or stop the system

The problem for AI agents:

Traditional apps perform ~50 operations per minute. AI agents execute 5,000+. At agent velocity, human oversight as traditionally conceived becomes impossible. By the time a human reviews an action, the agent has completed thousands more.

OpenAI’s guidance—“escalate high-risk actions to humans”—acknowledges this but doesn’t solve it. You can’t escalate 5,000 decisions per minute.

How PoC enables meaningful oversight:

Proof of Continuity shifts oversight from per-action approval to delegation chain approval.

Human oversight model with PoC:

1. Human approves delegation chain (once)
   └─ "This agent may process refunds up to $500 for order #12345"

2. Agent operates within chain constraints (autonomous)
   └─ All actions cryptographically bounded by step 1

3. Human reviews chain outcomes (async)
   └─ Full audit trail of what executed and why

The human doesn’t approve every action. The human approves the bounds within which actions occur. This is auditable, scalable oversight.

Evidence for auditors:

Requirement	PoC Evidence
Understand capabilities	Chain constraints are explicit and readable
Monitor operation	Every action includes provenance chain
Interpret outputs	Audit trail shows why each action was authorized
Override outputs	Revoke chain root to invalidate all downstream
Interrupt system	Transaction-scoped chains naturally terminate

SOC2: Trust Service Criteria

SOC2 audits evaluate controls against Trust Service Criteria. Here’s how PoC maps:

CC6.1: Logical Access Security

The entity implements logical access security software, infrastructure, and architectures over protected information assets.

Traditional approach: Role-based access control, API keys, OAuth scopes.

Problem: Roles are coarse. Scopes are static. Neither attenuates across delegation chains.

PoC mapping:

Evidence: Capability chains with cryptographic enforcement

├─ Access requires valid chain (logical access control)
├─ Chain constraints limit scope (least privilege)
├─ Each delegation is signed (accountability)
└─ Constraints only narrow, never expand (structural enforcement)

CC6.2: Access Removal

The entity removes access to protected information when no longer required.

Traditional approach: Manual deprovisioning, access reviews, token expiration.

Problem: Average credential lives 47 days past need. Manual reviews miss stale access.

PoC mapping:

Evidence: Built-in expiration and revocation

├─ expires_at: Chains expire automatically
├─ max_uses: Chains exhaust after N invocations
├─ transaction_id: Chains scoped to specific transactions
├─ revocation_id: Explicit revocation propagates instantly
└─ Root revocation: Invalidates all derived chains

CC6.3: Role-Based Access

The entity authorizes logical access based on roles with specific job functions.

PoC mapping:

Capability chains are more granular than roles but can express role-equivalent constraints:

Role: "Support Agent"
Traditional: Can access all refund APIs

PoC Chain:
├─ capabilities: [refunds:create]
├─ constraints: {
│    amount_max: 500,
│    customer_segment: "standard",
│    requires_ticket: true
│  }
└─ expires_at: "end_of_shift"

The chain expresses the role’s boundaries, not just its permissions.

CC7.2: Monitoring and Detection

The entity monitors system components for anomalies and investigates detected issues.

PoC mapping:

Every action carries its full provenance:

Audit Record:
├─ action: {refund: $450, customer: "cus_123"}
├─ executor: support_agent_pub_abc...
├─ chain: [root_block, delegation_block_1, delegation_block_2]
├─ constraint_evaluation: {amount_max: 500 → 450 ≤ 500 ✓}
└─ timestamp: 2025-01-15T10:23:49Z

Anomaly detection can operate on:

Actions exceeding typical patterns (even within constraints)
Unusual delegation chains
Chains approaching expiration or usage limits
Failed authorization attempts (mismatch between requester and designated executor)

Financial Services: OCC, FINRA, SEC

Financial regulators increasingly scrutinize AI systems. Key concerns:

Model Risk Management (OCC 2011-12)

Banks should ensure effective challenge of models and maintain comprehensive documentation.

PoC mapping:

Capability chains provide immutable documentation of what each agent was authorized to do:

For trade execution agent:
├─ Authorized by: portfolio_manager_pub_xyz...
├─ Constraints: {
│    daily_limit: 1000000,
│    asset_class: "equity",
│    approved_symbols: ["AAPL", "GOOGL", "MSFT"]
│  }
├─ Chain signature: Cryptographically verifiable
└─ All trades traceable to this authorization

Every trade can be traced to a specific authorization with specific constraints signed by a specific authorizer.

FINRA Rule 3110: Supervision

Member firms must establish and maintain a system to supervise activities of associated persons.

PoC mapping:

The delegation chain IS the supervision record:

Supervision chain:
├─ Compliance Officer → Trading Desk Head → Individual Trader Agent
├─ Each delegation signed by supervisor
├─ Constraints accumulate down chain
└─ Audit shows exactly who authorized what bounds

Reg SCI: Systems Compliance and Integrity

Entities must have policies to ensure operational capacity and security of systems.

PoC mapping:

Operational capacity: Gateway-side enforcement, not agent-side; agents can scale horizontally
Security: Cryptographic enforcement of constraints; see attack taxonomy
Integrity: Hash-linked chains; tampering breaks verification

Healthcare: HIPAA

Access Controls (§ 164.312(a)(1))

Implement technical policies and procedures for electronic information systems that maintain electronic protected health information.

PoC mapping:

Healthcare agent capability chain:
├─ capabilities: [patient_records:read]
├─ constraints: {
│    patient_id: "specific_patient_mrn",
│    purpose: "treatment",
│    minimum_necessary: true,
│    no_export: true
│  }
├─ expires_at: "end_of_encounter"
└─ audit_required: true

Access is:

Patient-specific (not blanket access to all records)
Purpose-limited (treatment, not research or marketing)
Time-bounded (encounter-scoped)
Auditable (every access logged with full chain)

Audit Controls (§ 164.312(b))

Implement hardware, software, and/or procedural mechanisms that record and examine activity.

PoC mapping:

The chain itself is the audit record. Every access includes:

Who authorized the access (chain signers)
What constraints applied (chain constraints)
Why access was granted (constraint evaluation)
When it occurred (timestamps)
What was accessed (action record)

No separate audit system required—the authorization IS the audit.

Transmission Security (§ 164.312(e)(1))

Implement technical security measures to guard against unauthorized access to electronic protected health information being transmitted.

PoC mapping:

Capability chains are self-contained proofs. Even if intercepted:

Attacker cannot use chain (not designated executor)
Attacker cannot modify chain (signatures break)
Attacker cannot extend chain (not designated to delegate)

See Token Replay attack for details.

Cross-Industry: ISO 27001

A.9.2.3: Management of Privileged Access Rights

The allocation and use of privileged access rights shall be restricted and controlled.

PoC mapping:

Privileged access in PoC:
├─ Root capabilities held by gateway (not agents)
├─ Agents receive attenuated chains (least privilege by design)
├─ Each delegation explicitly scoped
├─ No ambient authority accumulation
└─ Privilege escalation cryptographically impossible

A.12.4.1: Event Logging

Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed.

PoC mapping:

Every gateway verification produces a complete event record:

Event Log Entry:
├─ event_type: AUTHORIZATION_CHECK
├─ result: GRANTED | DENIED
├─ chain_id: "chain_abc123..."
├─ chain_root: "gateway_pub_xyz..."
├─ designated_executor: "agent_pub_def..."
├─ actual_requester: "agent_pub_def..."
├─ action_requested: {type: "refund", amount: 450}
├─ constraints_evaluated: [{amount_max: 500, result: PASS}]
├─ timestamp: "2025-01-15T10:23:49Z"
└─ verification_duration_ms: 3

A.9.4.1: Information Access Restriction

Access to information and application system functions shall be restricted in accordance with the access control policy.

PoC mapping:

Access control policy is encoded in chain constraints, not external policy engines:

Policy: "Support agents may refund up to $500"

Traditional: Policy engine evaluates at runtime
Problem: Policy can be bypassed, misconfigured, or out of sync

PoC: Constraint embedded in chain
├─ constraints: {amount_max: 500}
├─ Signed by authorizer
├─ Cannot be modified without breaking signature
└─ Gateway enforces at execution time

What Auditors Actually Need

When preparing for an audit involving AI agents with Proof of Continuity, prepare:

1. Architecture Documentation

┌─────────────────────────────────────────────────────────┐
│                    AUTHORIZATION FLOW                    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ┌──────────┐    chain    ┌──────────┐    chain        │
│  │ Human    │ ──────────► │ Agent A  │ ──────────►     │
│  │ Approval │             │          │             │    │
│  └──────────┘             └──────────┘             │    │
│                                                    ▼    │
│                           ┌──────────┐    ┌──────────┐ │
│                           │ Gateway  │ ◄──│ Agent B  │ │
│                           │ (verify) │    │          │ │
│                           └────┬─────┘    └──────────┘ │
│                                │                        │
│                                ▼                        │
│                           ┌──────────┐                 │
│                           │ Protected│                 │
│                           │ Resource │                 │
│                           └──────────┘                 │
│                                                         │
│  Key: Credentials live at Gateway, never at Agents     │
└─────────────────────────────────────────────────────────┘

2. Sample Chain with Annotations

Provide a real capability chain with explanations of each field and how it maps to controls.

3. Verification Logs

Show actual gateway logs demonstrating:

Successful authorizations (with constraint evaluation)
Rejected authorizations (with reason)
Chain expiration enforcement
Revocation enforcement

4. Key Management Procedures

Document:

How agent keypairs are generated
How public keys are registered
How private keys are protected
Rotation procedures
Compromise response procedures

5. Revocation Procedures

Document:

How to revoke a specific chain
How to revoke all chains from a compromised agent
How to revoke all chains from a compromised gateway
Time to propagation

The Compliance Advantage

Traditional authorization creates compliance friction:

Auditors ask “who can access what?”
Answer requires correlating roles, policies, tokens, logs
Documentation often stale or incomplete

Proof of Continuity simplifies:

Auditors ask “who can access what?”
Answer: “Look at the chains”
Every authorization is self-documenting
Every action carries its provenance

Compliance by construction, not compliance by documentation.

For the threat model that PoC addresses, see Agent Attack Taxonomy.