Audit & Privacy Controls

Status: Standard-only Alpha (v1.0.0-alpha.2)
Last Updated: 2026-03-07
Spec ID: ACGP-5
Normative Keywords: MUST, SHOULD, MAY (per RFC 2119 and RFC 8174)

Abstract

This specification defines security and privacy controls for governance trace handling, audit durability, data retention, field-level encryption, privacy minimization, cryptographic integrity proofs, and compliance-grade evidence. It also defines the Regulated Controls Badge as an additive conformance overlay.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

⚠️ Security Notice (Alpha): For normative identity semantics, including agent_id, agent_label, and sender_id distinctions, see ACGP-7. This specification does not define cryptographic identity proof or identity provider integration. Key lifecycle management remains out of scope for this version. See Known Limitations.

1. Scope [NORMATIVE]

ACGP-5 defines auditability and privacy controls for:

  • Governance traces, evaluation records, and intervention artifacts
  • Data classification and field-level protection
  • Audit durability, WAL behavior, and replay guarantees
  • Retention and secure deletion policies
  • Cryptographic evidence integrity
  • Compliance reporting and evidence export

ACGP-5 does not define:

  • Wire protocol mechanics (→ ACGP-2)
  • CTQ scoring or blueprint semantics (→ ACGP-3)
  • Conformance test suites (→ ACGP-6)

2. Threat and Security Baseline [NORMATIVE]

2.1 Threat Model

Implementations MUST establish controls against:

Threat Impact Mitigation
Governance bypass / policy tampering Catastrophic Blueprint integrity verification, signing
Trace / audit tampering Severe Hash-chain integrity, append-only storage
Data exfiltration Major Classification, encryption, access control
Replay attacks on governance artifacts Major Message IDs, timestamps, nonce validation
Unauthorized disclosure Moderate Field-level encryption, RBAC

2.2 Security Baseline

All ACGP implementations MUST provide:

  • Transport: TLS 1.3+ for all in-transit data
  • Signing: ES256 (ECDSA with P-256 and SHA-256) for governance messages where required by profile
  • Access control: Role-based access with least privilege
  • Administrative access: MFA for governance administration
  • Monitoring: Continuous security monitoring with alerting

2.3 Alpha Trust Bootstrap Responsibilities

ACGP v1.0 alpha standardizes governance semantics, not full deployment trust federation. Serious alpha deployments MUST define and document at least:

  • the steward trust root and how clients receive it
  • the steward signing identity and service authentication binding
  • key rotation and revocation responsibilities outside protocol scope
  • local fast-path verification or sampling controls where Tier-0 execution is enabled
  • operator override rules for ARS, Governance Tier tightening, and emergency trust actions

The repository now ships a schema-defined steward trust-root artifact and minimum rotation/revocation workflow for this profile. These responsibilities still require deployment controls, but they are no longer purely advisory. See Bootstrap Trust.

3. Data Classification [NORMATIVE]

Trace and audit data MUST be classified into at least five levels:

Level Description Protection Required Examples
Public No impact if disclosed None Documentation, schema
Internal Limited impact Access control Metrics, aggregated logs
Sensitive Moderate impact Encryption at rest Agent configs, blueprints
Restricted Severe impact HSM-backed encryption Signing keys, credentials
Secret Catastrophic impact Air-gapped storage Master keys, root certs

Implementations MUST tag all stored records with their classification level.

4. Privacy Model [NORMATIVE]

4.1 Privacy Principles

Implementations MUST enforce:

  1. Data minimization — collect only what is necessary for governance
  2. Purpose limitation — governance data used only for governance purposes
  3. Access least privilege — minimum access grants, time-bounded
  4. Secure deletion — cryptographic erasure at retention expiry

4.2 PII Handling

Where PII may appear in traces or outputs, implementations MUST:

  • Perform automatic PII detection scanning
  • Apply field-level encryption for PII fields
  • Enforce configurable retention limits (default: 90 days maximum)
  • Support secure overwrite deletion
  • Maintain audit trail of PII access

4.3 Data Redaction

Sensitive fields SHOULD be redacted before storage or transmission:

{
  "outputs": {
    "text": "User SSN: [REDACTED:SSN]",
    "redacted_fields": ["ssn", "credit_card"]
  },
  "redaction_metadata": {
    "policy": "pii_minimization_v1",
    "applied_at": "2026-01-15T10:00:00Z"
  }
}

5. Field-Level Encryption and Key Management [NORMATIVE]

5.1 Encryption Requirements

Data classified as sensitive or higher MUST be encrypted at rest.

Use Case Algorithm Key Size Rotation Period
Data at rest AES-256-GCM 256-bit 90 days
Message signing ES256 (ECDSA) 256-bit 1 year
Session keys AES-256-GCM 256-bit 24 hours
HMAC HMAC-SHA256 256-bit 30 days

5.2 Key Management

Implementations MUST:

  • Generate critical keys (master, signing, encryption) in HSM for restricted+ data
  • Maintain key rotation schedules per the table above
  • Archive old keys for the duration needed to decrypt retained data
  • Support emergency key revocation
  • Log all key operations to the audit trail

5.3 Encrypted Envelope

{
  "ciphertext": "base64-encoded-aes-256-gcm-ciphertext",
  "nonce": "base64-encoded-nonce",
  "tag": "base64-encoded-gcm-tag",
  "classification": "sensitive",
  "key_id": "encryption-key-identifier",
  "timestamp": "2026-01-15T10:00:00Z"
}

6. Retention and Commit-Then-Minimize [NORMATIVE]

6.1 Retention Policy

Retention MUST be explicit and auditable. Core requirements:

  1. Commit first — governance-relevant traces and evidence MUST be durably committed before any minimization
  2. Minimize after commit — apply redaction/minimization after durable commit if policy requires a reduced retained form
  3. Enforce windows — policy-defined retention windows and jurisdiction constraints
  4. Deletion evidence — provide proof of deletion or expiration for expired artifacts

6.2 Retention Windows by Profile

Data Type Standard Profile Safety-Critical Profile
TRACE records 90 days 7 years
EVAL records 90 days 7 years
INTERVENTION records 1 year 7 years
Trust debt history 1 year 7 years
Blueprint versions 2 years Indefinite
Security events 1 year 7 years

Implementations MUST declare their retention windows in conformance outputs.

6.3 Jurisdiction Constraints

For multi-region deployments, implementations SHOULD:

  • Tag data with originating jurisdiction
  • Enforce data residency requirements
  • Support cross-border transfer controls where required by law

6.4 Retention Policy Transitions

When an agent's conformance profile changes (for example, Standard → Safety-Critical), the new retention windows MUST apply to all records created after the transition.

Records created before the transition MUST retain their original retention window unless the new window is longer, in which case the longer window applies.

Implementations MUST log profile transitions as security events subject to the longest applicable retention window.

7. WAL Durability and Replay [NORMATIVE]

Audit pipelines MUST be resilient to storage outages.

If primary persistence fails, implementations MUST:

  1. Append pending records to a write-ahead log (WAL) or equivalent durable buffer
  2. Retry replay until commit succeeds
  3. Preserve ordering and idempotency semantics
  4. Expose bounded backpressure behavior when buffers near capacity
  5. Alert when WAL backlog exceeds configurable threshold

7.1 WAL Configuration

wal:
  enabled: true
  max_buffer_size_mb: 512
  flush_interval_ms: 100
  max_retry_attempts: 0        # 0 = unlimited
  backpressure_threshold: 0.8  # alert at 80% capacity
  ordering_guarantee: strict   # strict or best_effort

7.2 Recovery Semantics

On restart after failure:

  1. Scan WAL for uncommitted records
  2. Replay in original order
  3. Verify idempotency (skip already-committed records)
  4. Report recovery metrics (records replayed, time elapsed)

8. Evidence Integrity [NORMATIVE]

Evidence artifacts MUST be tamper-evident.

8.1 Hash-Chain Linkage

Implementations MUST provide cryptographic linkage between sequential audit entries:

{
  "entry_id": "uuid-v7",
  "sequence": 42,
  "timestamp": "2026-01-15T10:00:00Z",
  "payload_hash": "sha256:abc123...",
  "previous_hash": "sha256:def456...",
  "chain_hash": "sha256:ghi789..."
}

chain_hash = SHA-256(entry_id || sequence || payload_hash || previous_hash)

8.2 Merkle-Style Integrity

For high-volume deployments, implementations MAY use Merkle tree structures with verifiable roots published at configurable intervals.

8.3 Independent Verification

Integrity proofs MUST support independent verification during audits:

  • Any auditor with the chain can verify no entries were removed or modified
  • Root hashes MAY be published to external timestamping services
  • Verification tooling SHOULD be provided as part of conformance suite

8.4 Data Erasure and Regulatory Compliance [NORMATIVE]

ACGP's model is "tamper-evident sequence, redactable payload."

Crypto-shredding:

  1. payload_hash in hash chain MUST be computed over encrypted payload bytes.
  2. Erasure = destroy encryption key. Hash chain remains intact.
  3. After key destruction, annotate with redaction_event:
{
  "entry_id": "...",
  "redaction_timestamp": "...",
  "redaction_reason": "GDPR Article 17 request",
  "payload_status": "key_destroyed",
  "chain_integrity": "preserved"
}
  1. Auditors MUST accept entries where payload_status is key_destroyed.

8.5 Agent Identity Correlation [NORMATIVE]

Audit records MUST preserve the governed principal keying required by ACGP-7.

This section is a summary only. The authoritative normative definition is in ACGP-7 §5.

For normative identity semantics, including agent_id, agent_label, and sender_id distinctions, see ACGP-7.

Profile requirements:

  • Safety-Critical: MUST support crypto-shredding for PII.
  • Standard: SHOULD support. If not, MUST document and MUST NOT claim GDPR compliance.
  • Implementations MUST NOT use "immutable" to describe payload data. Correct: "tamper-evident sequence with redactable payloads."

9. Access Control [NORMATIVE]

9.1 Role-Based Access

Role Permissions MFA Required Session Timeout
Super Admin All operations Yes 15 minutes
Governance Admin Blueprint CRUD, agent suspend, registry Yes 30 minutes
Operator View agents, review interventions, ack alerts No 2 hours
Auditor Read logs, generate reports (read-only) No 8 hours

9.2 Zero Trust Principles

Implementations SHOULD apply zero-trust principles:

  • Verify every transaction regardless of network location
  • Default deny all; explicit allow only
  • Time-bound access grants with regular privilege audits
  • Continuous validation of security posture

10. Compliance and Reporting Controls [NORMATIVE]

10.1 Compliance Evidence

Implementations MUST support generation of machine-readable compliance evidence:

  • Control status and coverage reports
  • Retention and deletion evidence
  • Integrity verification outcomes
  • Security event and incident audit trails

10.2 Framework Mapping

Compliance reports SHOULD map ACGP controls to target frameworks without changing normative semantics:

Framework Relevant ACGP Controls
GDPR Privacy model (Section 4), retention (Section 6), deletion evidence
HIPAA Encryption (Section 5), access control (Section 9), audit trail (Section 8)
SOC 2 All controls; evidence integrity (Section 8), monitoring
ISO 27001 Security baseline (Section 2), key management (Section 5), RBAC (Section 9)
EU AI Act Transparency, audit trail, human oversight evidence

11. Regulated Controls Badge [NORMATIVE]

The Regulated Controls Badge is additive and orthogonal to profile conformance. In v1.0.0-alpha.2, it combines with the active Standard claim surface defined in ACGP-6.

11.1 Badge Control Families

Family Description Key Requirements
Audit Durability WAL, replay, ordering guarantees Section 7 compliance
Privacy & Minimization PII detection, redaction, consent Section 4 compliance
Retention & Jurisdiction Windows, deletion evidence, residency Section 6 compliance
Reproducibility & Export Evidence export, reproducible evaluations Machine-readable outputs
Cryptographic Integrity Hash-chain, Merkle proofs, verification Section 8 compliance

11.2 Claiming the Badge

Badge claims MUST be backed by passing the Regulated Controls test suite defined in ACGP-6. The badge is independent of profile level — a Standard profile implementation MAY claim the badge if it passes the suite.

11.3 Cross-Profile Control Matrix [NORMATIVE]

The claim-level control matrix is owned by ACGP-6. This specification explains audit, privacy, and implementation implications and does not redefine claim obligations.

12. Conformance Requirements

The profile and badge control obligations in Section 11.3 are normative and MUST align with the conformance suites and claim rules defined in ACGP-6.

This specification defines the controls themselves. Whether a control is REQUIRED, RECOMMENDED, or OPTIONAL for a given claim surface is determined by:

  1. the active profile claim defined in ACGP-6, and
  2. any additive badge claim defined in ACGP-6.

Accordingly:

  • all implementations claiming ACGP conformance MUST implement the controls required by their claimed profile and badge suites;
  • Standard profile implementations MUST satisfy the Standard obligations defined in ACGP-6 §3.2;
  • implementations claiming the Regulated Controls Badge MUST satisfy the badge obligations defined in ACGP-6 and Section 11.3 of this specification;
  • Safety-Critical control material is retained for future profile activation, but is not claimable in v1.0.0-alpha.2.

Normative References

  • RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
  • RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
  • RFC 3339 — Date and Time on the Internet: Timestamps
  • RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
  • RFC 8785 — JSON Canonicalization Scheme (JCS)
  • ACGP-1 — Core Concepts & Terminology, v1.0, 2026
  • ACGP-2 — Messages & Wire Protocol, v1.0, 2026
  • ACGP-3 — Blueprints, Traces & Evaluation, v1.0, 2026
  • ACGP-4 — Tripwires & Safety Semantics, v1.0, 2026
  • ACGP-5 — Audit & Privacy Controls, v1.0, 2026
  • ACGP-6 — Conformance, v1.0, 2026