RFC: Unified Policy Format for CI and AI Attestations

[colek42]

Summary

Propose a unified policy format that works seamlessly for both:

• witness-wrapper (CI pipelines)
• witness-signer-mcp (AI agent attestations)

Problem Statement

Currently, organizations need to maintain separate policy configurations for:

1. CI/CD pipelines using witness-wrapper
2. AI agent workflows using witness-signer-mcp

This leads to:

• Policy drift between environments
• Duplicate maintenance effort
• Inconsistent security postures

Proposed Architecture

┌─────────────────────────────────────────────────────────┐
│                  Unified Policy Format                   │
│                                                          │
│  steps:                                                  │
│    - name: test                                          │
│      type: validation                                    │
│      commands:                                           │
│        - pattern: "go test"                              │
│        - pattern: "npm test"                             │
│      attestors:                                          │
│        - command-run                                     │
│        - git                                             │
│      required_for: [ci, ai]                              │
│                                                          │
│    - name: lint                                          │
│      type: validation                                    │
│      commands:                                           │
│        - pattern: "golangci-lint"                        │
│        - pattern: "npm run lint"                         │
│      required_for: [ci, ai]                              │
│                                                          │
│    - name: coverage                                      │
│      type: quality-gate                                  │
│      threshold: 80                                       │
│      required_for: [ci]                                  │
│      optional_for: [ai]                                  │
└─────────────────────────────────────────────────────────┘
           │                            │
           ▼                            ▼
┌─────────────────────┐    ┌─────────────────────────────┐
│   witness-wrapper   │    │    witness-signer-mcp       │
│   (CI Pipeline)     │    │    (AI Agent)               │
│                     │    │                             │
│  - Runs in GHA/GL   │    │  - Runs in Claude Code      │
│  - Full attestation │    │  - Interactive attestation  │
│  - SLSA compliance  │    │  - Human-in-loop signing    │
└─────────────────────┘    └─────────────────────────────┘
           │                            │
           ▼                            ▼
┌─────────────────────────────────────────────────────────┐
│              Shared Verification Layer                   │
│                                                          │
│  witness verify --policy unified-policy.json             │
│                                                          │
│  - Same policy works for both CI and AI attestations    │
│  - Consistent security requirements                      │
│  - Single source of truth                                │
└─────────────────────────────────────────────────────────┘

Key Features

1. Semantic Step Types

Instead of exact command matching, use semantic types:

• validation - linting, testing, type checking
• quality-gate - coverage thresholds, complexity limits
• security-scan - vulnerability scanning, secret detection
• build - compilation, bundling

2. Environment-Specific Requirements

required_for: [ci]      # Only required in CI
required_for: [ai]      # Only required for AI agents
required_for: [ci, ai]  # Required in both
optional_for: [ai]      # Optional for AI, provides bonus trust

3. Command Pattern Matching

Use glob/regex patterns instead of exact strings:

commands:
  - pattern: "go test ./..."
  - pattern: "npm test"
  - pattern: "*jest*"

4. Shared Attestor Configuration

Common attestor settings that work in both contexts:

attestors:
  git:
    require_clean: true
    allowed_statuses: [untracked]
  command-run:
    capture_output: true

Benefits

1. Single Policy Definition - One policy file governs both CI and AI
2. Consistent Security - Same requirements enforced everywhere
3. Flexible Enforcement - Different requirements per environment
4. Easier Auditing - One place to review security requirements
5. Reduced Drift - No policy synchronization needed

Implementation Phases

Phase 1: Policy Schema

• Define unified YAML/JSON schema
• Support for both exact and pattern matching
• Environment-specific requirements

Phase 2: witness-wrapper Integration

• Update witness-wrapper to read unified format
• Generate witness policies from unified schema
• Backwards compatibility with existing policies

Phase 3: witness-signer-mcp Integration

• Update witness-signer-mcp to read unified format
• Generate Rego policies from unified schema
• Support for interactive policy creation

Phase 4: Tooling

• Policy linter for unified format
• Migration tool from existing policies
• Documentation and examples

Questions for Discussion

1. Should we support YAML, JSON, or both?
2. How do we handle attestor-specific configuration differences?
3. What's the migration path for existing policies?
4. Should we support policy inheritance/composition?

Related Issues

• Feature: Relaxed command matching with patterns/globs #2 Relaxed Command Matching
• Feature: Semantic step-type policies #3 Semantic Step-Type Policies
• Feature: Pre-defined step templates for common project types #6 Pre-defined Step Templates
• Feature: Policy inheritance for organizational standards #7 Policy Inheritance/Composition

[colek42]

Extension: Actor-Based Policy Requirements

Building on the unified format, policies could vary based on who is performing the action, using OIDC identity from Sigstore:

actors:
  ai-agents:
    match:
      - email: "*@anthropic.com"
      - issuer: "https://accounts.google.com"
        email: "*-claude@*"
    requires: [test, lint, build, security_scan, coverage]
    policy: strict
    rationale: "AI agents need comprehensive validation"

  senior-engineers:
    match:
      - email: "alice@company.com"
      - email: "bob@company.com"  
    requires: [test, lint]
    policy: relaxed
    rationale: "Trusted humans with track record"

  ci-bots:
    match:
      - issuer: "https://token.actions.githubusercontent.com"
    requires: [test, lint, build, slsa_provenance]
    policy: strict
    rationale: "Automated pipelines need provenance"

  external-contributors:
    match:
      - email: "*"  # catch-all
    requires: [test, lint, build, security_scan, code_review]
    policy: strict
    rationale: "Unknown actors need human review gate"

Benefits

1. Trust-proportional security - More trusted actors need fewer gates
2. AI-specific guardrails - Enforce stricter requirements for AI agents
3. Auditability - Clear documentation of why different actors have different requirements
4. Flexibility - Same codebase can have different policies per contributor type

Identity Sources

Sigstore OIDC provides rich identity info:

• email - The authenticated identity
• issuer - Where they authenticated (Google, GitHub, etc.)
• GitHub Actions also provides: repository, workflow, ref

Example Verification

# AI agent pushes code
witness verify --policy unified.json --identity claude@anthropic.com
# → Checks: test, lint, build, security_scan, coverage ✓

# Senior engineer pushes code  
witness verify --policy unified.json --identity alice@company.com
# → Checks: test, lint ✓

# Unknown contributor pushes code
witness verify --policy unified.json --identity random@external.com
# → Checks: test, lint, build, security_scan, code_review ✓
# → Blocks if no code_review attestation from approved reviewer

This transforms the policy from "what must be done" to "what must be done by whom" - a much more realistic trust model.

[colek42]

Clarification: Identity-Based Policy Distribution

Rather than varying requirements within a single policy, the model should be:

Same policy content → distributed to appropriate actors based on identity

Architecture

┌─────────────────────────────────────────────────────────┐
│                   Policy Registry                        │
├─────────────────────────────────────────────────────────┤
│  dev-policy.json      → test, lint, build, coverage     │
│  docs-policy.json     → lint, spellcheck                │
│  infra-policy.json    → terraform validate, plan        │
│  security-policy.json → scan, audit, sbom               │
│  ops-policy.json      → deploy, rollback, verify        │
└─────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────┐
│              Identity → Policy Mapping                   │
├─────────────────────────────────────────────────────────┤
│  claude-code@anthropic.com     → dev-policy.json        │
│  claude-docs@anthropic.com     → docs-policy.json       │
│  claude-infra@anthropic.com    → infra-policy.json      │
│  claude-security@anthropic.com → security-policy.json   │
│  claude-oncall@anthropic.com   → ops-policy.json        │
│  github-actions-bot            → dev-policy.json        │
│  dependabot                    → security-policy.json   │
│  renovate-bot                  → security-policy.json   │
└─────────────────────────────────────────────────────────┘

Key Principles

1. Policies are uniform - Everyone assigned a policy gets the same requirements
2. Identity determines assignment - Agent/actor identity determines WHICH policy, not what's in it
3. Role-based, not trust-based - A docs agent doesn't need go test because that's not its job, not because it's more trusted

Policy Server Flow

┌──────────────┐     ┌─────────────────┐     ┌──────────────┐
│  AI Agent    │────▶│  Policy Server  │────▶│   Verify     │
│              │     │                 │     │              │
│ Identity:    │     │ 1. Validate     │     │ Attestations │
│ claude-code  │     │    OIDC token   │     │ against      │
│ @anthropic   │     │ 2. Lookup       │     │ assigned     │
│              │     │    mapping      │     │ policy       │
│              │     │ 3. Return       │     │              │
│              │     │    policy       │     │              │
└──────────────┘     └─────────────────┘     └──────────────┘

Example Workflow

# Agent requests its policy based on identity
policy=$(curl -H "Authorization: Bearer $OIDC_TOKEN" \
  https://policies.company.com/v1/policy)

# Agent creates attestations against that policy's requirements
witness-signer-mcp bash --attest --step=test "npm test"
witness-signer-mcp bash --attest --step=lint "npm run lint"

# Verification uses same identity-based lookup
witness-signer-mcp verify \
  --policy-server https://policies.company.com \
  --identity-token $OIDC_TOKEN

Configuration Example

# policy-mappings.yaml
mappings:
  - match:
      email: "claude-code@anthropic.com"
    policy: dev-policy.json
    
  - match:
      email: "claude-docs@anthropic.com"
    policy: docs-policy.json
    
  - match:
      email: "*-bot@github.com"
      issuer: "https://token.actions.githubusercontent.com"
    policy: ci-policy.json
    
  - match:
      email: "*@company.com"
    policy: dev-policy.json  # Default for humans
    
  - match:
      email: "*"  # Catch-all
    policy: strict-policy.json  # Unknown actors get strictest

Benefits

1. Separation of concerns - Policy content vs policy assignment are independent
2. Scalable - Add new agents without modifying policies
3. Auditable - Clear mapping of who gets what
4. Principle of least privilege - Agents only get policies for their scope
5. Central management - One place to update mappings

This replaces my earlier comment about varying requirements per actor - the requirements stay fixed, only the assignment varies.

[colek42]

Existing Infrastructure: TUF + Archivista + RSTUF

There's already significant work on identity-based policy distribution via TUF. This RFC should build on that foundation rather than creating something new.

Design Doc

"Securing Artifact Policy with TUF and in-toto": https://hackmd.io/@colek42/H1Ub7g4e3

Related Issues

• Archivista #240: Policy Approval via TUF signature thresholds
• Archivista #239: tufstorage integration
• RSTUF #354: Custom delegated target roles ✅ COMPLETED
• RSTUF #647: Offline key support (pending)

Architecture

┌─────────────────────────────────────────────────────────────┐
│                     RSTUF Repository                         │
│                                                              │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │ root.json   │  │snapshot.json│  │timestamp.json│          │
│  │ (offline)   │  │ (SPIFFE)    │  │ (SPIFFE+TSA) │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐   │
│  │              Delegated Target Roles                   │   │
│  │                                                       │   │
│  │  /policies/dev/*      → threshold: 2 signatures      │   │
│  │  /policies/docs/*     → threshold: 1 signature       │   │
│  │  /policies/security/* → threshold: 3 signatures      │   │
│  │  /policies/ai-code/*  → threshold: 2 signatures      │   │
│  │  /policies/ai-docs/*  → threshold: 1 signature       │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                      Archivista                              │
│                                                              │
│  • Stores DSSE-signed policy envelopes                      │
│  • Stores attestations (linked by GitOID)                   │
│  • Provides API for policy + attestation retrieval          │
│  • Integrates with TUF for secure distribution              │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│              Certificate Constraints                         │
│              (Identity-Based Policy Routing)                 │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  AI Agent Identities:                                        │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ email: claude-code@anthropic.com                       │ │
│  │ issuer: https://accounts.google.com                    │ │
│  │ → routes to: /policies/ai-code/dev-policy.json         │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ email: claude-docs@anthropic.com                       │ │
│  │ issuer: https://accounts.google.com                    │ │
│  │ → routes to: /policies/ai-docs/docs-policy.json        │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
│  CI Bot Identities:                                          │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ issuer: https://token.actions.githubusercontent.com    │ │
│  │ subject: repo:org/repo:ref:refs/heads/main             │ │
│  │ → routes to: /policies/dev/ci-policy.json              │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
│  Human Identities:                                           │
│  ┌────────────────────────────────────────────────────────┐ │
│  │ email: *@company.com                                   │ │
│  │ → routes to: /policies/dev/standard-policy.json        │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Witness Verification Flow (from design doc)

1. Agent authenticates via OIDC
2. Contact Archivista API
3. Download TUF root, verify signature
4. Query TUF metadata for delegated role matching identity constraints
5. Download policy from Archivista
6. Verify policy signature against TUF metadata
7. Download attestations for artifact
8. Verify attestations against policy
9. (Continuous) Request policy refresh per freshness requirements

What witness-signer-mcp Needs

To integrate with this infrastructure, witness-signer-mcp should:

1. Implement TUF client - Download and verify TUF metadata
2. Use certificate constraints for identity - Match OIDC identity to appropriate policy
3. Support Archivista as policy source - Fetch policies via GitOID
4. Leverage existing signature thresholds - Human approval already built-in

Benefits of This Approach

1. No new infrastructure - Uses existing RSTUF + Archivista
2. Battle-tested security - TUF is proven at scale (PyPI, RubyGems, etc.)
3. Multi-party approval - Signature thresholds require N-of-M humans
4. Offline key protection - Root keys stay offline
5. Freshness guarantees - Timestamp prevents freeze attacks
6. Consistent model - Same infrastructure for CI and AI agents

Implementation Path

1. Wait for Archivista #239 + #240 (TUF storage integration)
2. Add TUF client to witness-signer-mcp
3. Configure certificate constraints for AI agent identities
4. Create delegated roles for different agent types
5. Human key holders sign policies with required threshold
6. Agents automatically receive correct policy based on identity

This unifies CI (witness-wrapper) and AI (witness-signer-mcp) under the same TUF-based policy distribution system.

[colek42]

SPIRE Integration: Hardware-Attested Identity

Adding SPIRE to the architecture provides hardware-backed identity verification via HSM/TPM attestation. This is significantly stronger than OIDC alone.

Why SPIRE + HSM/TPM?

OIDC (software)	SPIRE + TPM (hardware)
Token can be stolen/replayed	Hardware-bound, can't extract
Proves "who logged in"	Proves "what hardware is running"
Identity = email address	Identity = attested workload
Trust the OAuth provider	Trust the hardware root of trust

Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                     SPIRE Server (Cloud)                             │
│                                                                      │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │                   Workload Registrations                        │ │
│  │                                                                 │ │
│  │  spiffe://testifysec.com/agent/claude-code                     │ │
│  │    → selector: tpm:pcr:0=<measurement>                         │ │
│  │    → selector: k8s:pod-label:app=claude-code                   │ │
│  │    → dns_name: claude-code.agents.testifysec.com               │ │
│  │                                                                 │ │
│  │  spiffe://testifysec.com/agent/claude-docs                     │ │
│  │    → selector: tpm:pcr:0=<measurement>                         │ │
│  │    → selector: docker:label:role=docs-agent                    │ │
│  │                                                                 │ │
│  │  spiffe://testifysec.com/ci/github-actions                     │ │
│  │    → selector: aws:iid:account:123456789                       │ │
│  │    → selector: aws:iid:region:us-east-1                        │ │
│  │                                                                 │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                                                                      │
│  Root CA key in HSM (AWS CloudHSM / Azure HSM / GCP Cloud HSM)      │
│  Never leaves hardware, supports key rotation                        │
└─────────────────────────────────────────────────────────────────────┘
                              │
                              │ Node Attestation (TPM 2.0)
                              │ + Workload Attestation
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    SPIRE Agent (on AI host)                          │
│                                                                      │
│  Attestation Flow:                                                   │
│  1. TPM quote with nonce → proves hardware identity                 │
│  2. Workload API socket → provides SVIDs to local processes         │
│  3. Auto-rotation → short-lived creds, no static secrets            │
│                                                                      │
│  Output:                                                             │
│  • X.509 SVID (for mTLS)                                            │
│  • JWT SVID (for bearer auth)                                       │
│  • Trust bundle (for verification)                                  │
└─────────────────────────────────────────────────────────────────────┘
                              │
                              │ SVID (X.509 or JWT)
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                     witness-signer-mcp                               │
│                                                                      │
│  Identity Options:                                                   │
│                                                                      │
│  Option A: X.509 SVID (mTLS)                                        │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ curl --cert svid.pem --key svid-key.pem \                      │ │
│  │   https://archivista.company.com/policy                        │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                                                                      │
│  Option B: JWT SVID (Bearer)                                        │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ curl -H "Authorization: Bearer $JWT_SVID" \                    │ │
│  │   https://archivista.company.com/policy                        │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                                                                      │
│  Option C: Hybrid (OIDC + SPIFFE)                                   │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ • OIDC for user identity (who invoked the agent)               │ │
│  │ • SPIFFE for workload identity (what hardware is running)      │ │
│  │ • Policy requires BOTH to match                                │ │
│  └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│              TUF Certificate Constraints                             │
│              (Now with SPIFFE ID support)                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  constraints:                                                        │
│    - spiffe_id: "spiffe://testifysec.com/agent/claude-code"         │
│      policy: /policies/ai-code/dev-policy.json                      │
│                                                                      │
│    - spiffe_id: "spiffe://testifysec.com/agent/claude-docs"         │
│      policy: /policies/ai-docs/docs-policy.json                     │
│                                                                      │
│    - spiffe_id: "spiffe://testifysec.com/ci/*"                      │
│      policy: /policies/ci/standard-policy.json                      │
│                                                                      │
│    - spiffe_id: "spiffe://testifysec.com/agent/*"                   │
│      email: "*@anthropic.com"  # Hybrid: SPIFFE + OIDC              │
│      policy: /policies/ai/default-policy.json                       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Complete Flow

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   AI Host    │     │    SPIRE     │     │  Archivista  │     │    RSTUF     │
│   + TPM      │     │   Server     │     │              │     │              │
└──────┬───────┘     └──────┬───────┘     └──────┬───────┘     └──────┬───────┘
       │                    │                    │                    │
       │ 1. TPM Quote       │                    │                    │
       │ (nonce + PCRs)     │                    │                    │
       │───────────────────▶│                    │                    │
       │                    │                    │                    │
       │ 2. SVID            │                    │                    │
       │ (X.509 cert)       │                    │                    │
       │◀───────────────────│                    │                    │
       │                    │                    │                    │
       │ 3. Request policy (mTLS with SVID)     │                    │
       │───────────────────────────────────────▶│                    │
       │                    │                    │                    │
       │                    │                    │ 4. Lookup SPIFFE   │
       │                    │                    │    in constraints  │
       │                    │                    │───────────────────▶│
       │                    │                    │                    │
       │                    │                    │ 5. Return policy   │
       │                    │                    │    for this ID     │
       │                    │                    │◀───────────────────│
       │                    │                    │                    │
       │ 6. Signed policy (DSSE envelope)       │                    │
       │◀───────────────────────────────────────│                    │
       │                    │                    │                    │
       │ 7. Create attestations against policy  │                    │
       │                    │                    │                    │
       │ 8. Upload attestations (mTLS)          │                    │
       │───────────────────────────────────────▶│                    │
       │                    │                    │                    │

Security Properties

Property	How SPIRE Provides It
Hardware Root of Trust	TPM attestation proves genuine hardware
No Static Secrets	SVIDs rotate automatically (default: 1 hour)
Workload Isolation	Each agent gets unique SPIFFE ID
Revocation	Remove registration → immediate revocation
Audit Trail	SPIRE logs all SVID issuances
HSM Protection	Root CA key never leaves HSM

Hybrid Identity Model

For maximum security, require BOTH:

# Policy constraint requiring hardware + user identity
constraints:
  - name: "AI code agent operated by authorized user"
    require_all:
      - spiffe_id: "spiffe://testifysec.com/agent/claude-code"
      - oidc_email: "*@testifysec.com"
    policy: /policies/ai-code/strict-policy.json

This proves:

1. Hardware: The agent is running on registered, TPM-attested hardware
2. User: A valid employee invoked the agent via OIDC
3. Policy: Only the intersection gets the policy

Implementation Requirements

SPIRE Server:

• Deploy with HSM backend (CloudHSM, Azure Dedicated HSM, etc.)
• Configure TPM attestor for node attestation
• Register workloads with appropriate selectors

SPIRE Agent:

• Deploy alongside AI agent hosts
• Configure TPM 2.0 plugin for node attestation
• Expose Workload API socket

witness-signer-mcp:

• Add SPIFFE Workload API client
• Support X.509 SVID for mTLS
• Support JWT SVID for bearer auth
• Optional: Combine with OIDC for hybrid identity

Archivista:

• Accept mTLS connections with SPIFFE ID validation
• Extract SPIFFE ID from client certificate
• Use SPIFFE ID in TUF certificate constraints

Deployment Topology

┌─────────────────────────────────────────────────────────────────────┐
│                         Cloud Environment                            │
│                                                                      │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐     │
│  │  SPIRE Server   │  │   Archivista    │  │     RSTUF       │     │
│  │  + CloudHSM     │  │   + PostgreSQL  │  │   + Redis       │     │
│  └─────────────────┘  └─────────────────┘  └─────────────────┘     │
│           │                    │                    │               │
└───────────┼────────────────────┼────────────────────┼───────────────┘
            │                    │                    │
            │         mTLS (SPIFFE Federation)        │
            │                    │                    │
┌───────────┼────────────────────┼────────────────────┼───────────────┐
│           ▼                    ▼                    ▼               │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    Developer Workstation                     │   │
│  │                                                              │   │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐       │   │
│  │  │ SPIRE Agent  │  │ Claude Code  │  │  witness-    │       │   │
│  │  │ (TPM 2.0)    │──│              │──│  signer-mcp  │       │   │
│  │  └──────────────┘  └──────────────┘  └──────────────┘       │   │
│  │         │                                    │               │   │
│  │         └────── Workload API Socket ─────────┘               │   │
│  └──────────────────────────────────────────────────────────────┘   │
│                                                                      │
│                    On-Premise / Edge Environment                     │
└─────────────────────────────────────────────────────────────────────┘

This provides defense in depth:

1. Network: mTLS everywhere, no plaintext
2. Identity: Hardware-attested, short-lived credentials
3. Policy: Human-approved via TUF signature thresholds
4. Audit: Full traceability from hardware to policy to attestation

[colek42]

Policy as Contract: Preconditions and Postconditions

Policies should not just control what agents CAN do, but ensure tasks are completed correctly by specifying:

• Preconditions: What must exist BEFORE a task runs
• Postconditions: What must be proven AFTER a task completes

Contract Schema

workflow: incident-response
agent: spiffe://company.com/agent/oncall

preconditions:
  gather-logs:
    requires:
      - type: jira-ticket
        status: open
        labels: [incident]
      - type: pagerduty-incident
        state: triggered
    
  remediate:
    requires:
      # Must have prior attestation
      - type: attestation
        step: analyze
        outcome: success
      # Must have human approval
      - type: approval
        from: oncall-lead
        within: 30m

postconditions:
  gather-logs:
    must_produce:
      - type: attestation
        contains: [log_files, time_range]
        
  remediate:
    must_produce:
      - type: attestation
        outcome: [success, rollback]
      - type: verification
        service_healthy: true
        
  workflow_complete:
    must_produce:
      - type: jira-comment
        ticket: "{{preconditions.jira-ticket.id}}"

Verification Flow

┌─────────────────────────────────────────────────────────────────────┐
│                  Policy Contract Enforcement                         │
└─────────────────────────────────────────────────────────────────────┘

BEFORE Task:
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Check Jira   │────▶│ Check Prior  │────▶│ Check Human  │
│ Ticket Exists│     │ Attestations │     │ Approval     │
└──────────────┘     └──────────────┘     └──────────────┘
       │                    │                    │
       ▼                    ▼                    ▼
   Attestation         Attestation          Attestation
   "INC-123 open"      "analyze done"       "alice approved"
       │                    │                    │
       └────────────────────┼────────────────────┘
                            ▼
                  ┌──────────────────┐
                  │   TASK EXECUTES  │
                  │  (all precond.   │
                  │   satisfied)     │
                  └──────────────────┘
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
       ▼                    ▼                    ▼
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Verify       │     │ Verify       │     │ Verify       │
│ Output Exists│     │ Service OK   │     │ Jira Updated │
└──────────────┘     └──────────────┘     └──────────────┘
       │                    │                    │
       ▼                    ▼                    ▼
   Attestation         Attestation          Attestation
   "logs collected"    "health ✓"           "INC-123 updated"

AFTER Task:
All postconditions attested → Workflow step complete

Production Deployment Example

workflow: deploy-to-prod
agent: spiffe://company.com/agent/deployer

preconditions:
  deploy:
    requires:
      # CI attestations for this exact code
      - type: attestation
        steps: [test, lint, build, security_scan]
        tree_hash: "{{git.tree_hash}}"
        
      # Change management ticket
      - type: jira-ticket
        type: change-request
        status: approved
        environment: production
        
      # Staging verification
      - type: attestation
        step: staging_deploy
        outcome: success
        verification: passed
        
      # Human approvals (2 required)
      - type: approval
        count: 2
        from: [tech-lead, oncall]

postconditions:
  deploy:
    must_produce:
      # Deployment proof
      - type: attestation
        contains: [image_digest, replicas, namespace]
        
      # Health verification
      - type: verification
        health_endpoint: "{{service.url}}/health"
        status: 200
        within: 5m
        
      # Update tracking systems
      - type: jira-transition
        ticket: "{{preconditions.jira-ticket.id}}"
        to: deployed

Attestation Chain = Proof of Contract

The resulting attestation bundle proves the entire contract was fulfilled:

┌─────────────────────────────────────────────────────────────────────┐
│              Attestation Chain for Deploy                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Subject: git tree abc123                                           │
│                                                                      │
│  Precondition Attestations (INPUTS):                                │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ ✓ test.json        - tests passed                              │ │
│  │ ✓ lint.json        - lint passed                               │ │
│  │ ✓ build.json       - build succeeded                           │ │
│  │ ✓ scan.json        - no vulnerabilities                        │ │
│  │ ✓ staging.json     - staging verified                          │ │
│  │ ✓ jira-chg.json    - CHG-456 approved                          │ │
│  │ ✓ approval.json    - 2/2 humans approved                       │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                                                                      │
│  Execution Attestation (ACTION):                                    │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ ✓ deploy.json                                                  │ │
│  │   command: kubectl apply -f manifests/                         │ │
│  │   image: sha256:def789                                         │ │
│  │   namespace: production                                        │ │
│  │   timestamp: 2024-01-15T11:05:00Z                              │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                                                                      │
│  Postcondition Attestations (OUTPUTS):                              │
│  ┌────────────────────────────────────────────────────────────────┐ │
│  │ ✓ health.json      - /health returned 200                      │ │
│  │ ✓ jira-update.json - CHG-456 → 'deployed'                      │ │
│  │ ✓ metrics.json     - datadog event created                     │ │
│  └────────────────────────────────────────────────────────────────┘ │
│                                                                      │
│  Identity: spiffe://company.com/agent/deployer (TPM-attested)       │
│  Policy: signed by alice@, bob@ (2/3 threshold)                     │
│  Stored: Archivista gitoid:sha256:xyz...                            │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Precondition Types

Type	Description	Example
attestation	Prior step completed	step: test, outcome: success
jira-ticket	Ticket exists in state	type: incident, status: open
approval	Human sign-off	from: oncall-lead, count: 2
time-window	Within allowed hours	schedule: business-hours
environment	Environment state	staging: healthy
feature-flag	Flag enabled	flag: ai-deploy-enabled

Postcondition Types

Type	Description	Example
attestation	Execution proof	contains: [image_digest]
verification	Runtime check	health_endpoint: /health
jira-transition	Ticket update	to: deployed
notification	Alert sent	slack: #deploys
metric	Metric recorded	datadog: deployment.count
rollback-ready	Can undo	previous_version: stored

Benefits

1. Auditable: Every precondition check is attested
2. Enforceable: Task won't run without preconditions
3. Verifiable: Postconditions prove completion
4. Traceable: Full chain from ticket → approval → execution → verification
5. Compliant: Perfect for SOC2, FedRAMP evidence

Integration with AgentFlow

workflow := agentflow.NewWorkflow("deploy").
    WithPolicy(policy).
    WithPreconditions(agentflow.Preconditions{
        "deploy": {
            Attestations: []string{"test", "lint", "build", "scan"},
            JiraTicket:   "type=change-request,status=approved",
            Approvals:    2,
        },
    }).
    WithPostconditions(agentflow.Postconditions{
        "deploy": {
            HealthCheck:  "{{service.url}}/health",
            JiraTransition: "deployed",
        },
    }).
    AddTask("deploy", deployTask).
    Build()

This transforms policies from "access control" to "workflow contracts" - ensuring not just that agents CAN do things, but that they DO them correctly with full proof.

[colek42]

Core Thesis: Verification Engineering > Prompt Engineering

This RFC proposes a paradigm shift in how we approach AI safety and governance.

The Problem with Prompt Engineering

┌─────────────────────────────────────────────────────────────────────┐
│                     Prompt Engineering Model                         │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   User ──▶ Prompt ──▶ AI ──▶ Action ──▶ Audit                       │
│               │                  │          │                        │
│               ▼                  ▼          ▼                        │
│           "Please don't      (hope it    (too late                  │
│            delete prod"       listens)    if wrong)                 │
│                                                                      │
│   Security model: HOPE                                              │
│   Failure mode: Jailbreak, misunderstanding, hallucination          │
│   Recovery: Incident response after damage                          │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

The Verification Engineering Model

┌─────────────────────────────────────────────────────────────────────┐
│                   Verification Engineering Model                     │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   User ──▶ AI ──▶ Policy ──▶ Attestation ──▶ Action                 │
│                      │            │             │                    │
│                      ▼            ▼             ▼                    │
│                  (check        (prove        (only if               │
│                   rules)        right)        proven)               │
│                                                                      │
│   Security model: MATH                                              │
│   Failure mode: Action blocked (safe failure)                       │
│   Recovery: Not needed - unauthorized action never happened         │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Side-by-Side Comparison

Prompt Engineering	Verification Engineering
"Please don't delete prod"	Can't delete without signed policy
Hope the AI follows rules	Math prevents violation
Jailbreaks bypass controls	No attestation = no action
"Trust but verify"	"Verify then trust"
Alignment is a prayer	Attestation is a proof
Audit after the fact	Gate before the action
Constrain the model	Constrain the capabilities
Security through instructions	Security through cryptography

The Key Insight

We're not constraining intelligence - we're constraining capability.

The AI can be infinitely creative about how to solve problems:

• Novel approaches to debugging
• Creative solutions to incidents
• Efficient automation strategies

But what it can do is cryptographically bounded:

• Only approved commands
• Only with required attestations
• Only after human-approved policy
• Only with hardware-verified identity

┌─────────────────────────────────────────────────────────────────────┐
│                                                                      │
│   CREATIVITY: Unbounded          CAPABILITY: Cryptographically      │
│   (how to solve)                 bounded (what can be done)         │
│                                                                      │
│   ┌─────────────────┐            ┌─────────────────┐                │
│   │                 │            │    ┌───────┐    │                │
│   │   Infinite      │            │    │Allowed│    │                │
│   │   solution      │            │    │actions│    │                │
│   │   space         │            │    └───────┘    │                │
│   │                 │            │                 │                │
│   └─────────────────┘            └─────────────────┘                │
│                                                                      │
│   AI explores freely             But only within verified bounds    │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Reframing AI Safety

Old Model (Alignment)	New Model (Verification)
Make AI want to do right	Make wrong actions impossible
Align the model weights	Constrain the action space
Trust the training	Trust the attestation
Hope for compliance	Prove compliance
Red team the prompts	Red team the policy
Security = better prompts	Security = better proofs

Why This Matters

1. Jailbreak-resistant: No clever prompt bypasses cryptographic verification
2. Auditable: Every action has mathematical proof of authorization
3. Composable: Same verification works for AI, CI, humans
4. Scalable: Add more agents without more trust decisions
5. Recoverable: If policy is wrong, fix policy - not retrain model

The Security Boundary

┌─────────────────────────────────────────────────────────────────────┐
│                     Security Boundary                                │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  OUTSIDE THE BOUNDARY              INSIDE THE BOUNDARY              │
│  (AI can do anything)              (AI can only do verified)        │
│                                                                      │
│  • Think about solutions           • Execute commands               │
│  • Generate code                   • Access production              │
│  • Propose approaches              • Modify infrastructure          │
│  • Ask questions                   • Deploy changes                 │
│  • Analyze logs                    • Delete resources               │
│                                                                      │
│  No verification needed            Requires:                        │
│                                    • Identity (SPIFFE)              │
│                                    • Policy (TUF-signed)            │
│                                    • Preconditions (attestations)   │
│                                    • Postconditions (verification)  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Conclusion

Prompt engineering asks: "How do we make AI want to be safe?"

Verification engineering asks: "How do we make unsafe actions impossible?"

The answer isn't better prompts. It's better proofs.

The AI doesn't need to be aligned.
The AI doesn't need to be trusted.
The AI doesn't need to follow instructions.

The AI just needs to be verified.

This RFC describes the infrastructure to make that verification possible - from hardware identity (SPIRE/TPM) to policy distribution (TUF/Archivista) to workflow enforcement (AgentFlow) to audit trails (Witness attestations).

Verification engineering > Prompt engineering.

[colek42]

AI as Policy Solver

When AI can read the policy, it becomes a creative problem solver - finding optimal paths to satisfy requirements rather than blindly hitting walls.

Policy as Specification, Not Restriction

Traditional: Policy is a wall
┌─────────┐     ┌─────────┐
│   AI    │──X──│  WALL   │     AI hits wall, stops, fails
└─────────┘     └─────────┘


New Model: Policy is a specification
┌─────────┐     ┌─────────────────────────────────────┐
│   AI    │────▶│  "To deploy, I need:                │
│ (reads  │     │   - test attestation                │
│ policy) │     │   - lint attestation                │
│         │     │   - 2 approvals                     │
│         │     │   - staging verification            │
│         │     │                                     │
│         │     │  Let me find ways to satisfy this"  │
└─────────┘     └─────────────────────────────────────┘

Multi-Path Problem Solving

The AI can find multiple valid paths to satisfy the policy:

┌─────────────────────────────────────────────────────────────────────┐
│              Policy: requires {test, lint, build, 2 approvals}       │
└─────────────────────────────────────────────────────────────────────┘
                              │
           ┌──────────────────┼──────────────────────┐
           ▼                  ▼                      ▼
    ┌────────────┐    ┌────────────┐    ┌────────────────┐
    │  Path A    │    │  Path B    │    │    Path C      │
    │            │    │            │    │                │
    │ Run all    │    │ Query      │    │ Parallelize    │
    │ checks     │    │ Archivista │    │ everything,    │
    │ sequen-    │    │ for exist- │    │ request        │
    │ tially     │    │ ing proofs │    │ approvals      │
    │            │    │ first      │    │ immediately    │
    │            │    │            │    │                │
    │ Time: 10m  │    │ Time: 2m   │    │ Time: 5m       │
    └────────────┘    └────────────┘    └────────────────┘

AI Reasoning Example

# AI reads this policy
preconditions:
  deploy:
    requires:
      - attestation: [test, lint, build]
        tree_hash: "{{git.tree_hash}}"
      - approvals: 2
        from: [tech-lead, oncall]
      - staging: verified

AI reasoning process:

1. ANALYZE REQUIREMENTS
   "I need: test attestation, lint attestation, build attestation,
    2 human approvals, and staging verification"

2. CHECK EXISTING STATE
   Query Archivista for tree hash abc123...
   Found:
   - test.json ✓ (created 10 mins ago)
   - lint.json ✓ (created 10 mins ago)
   - build.json ✗ (not found)
   - staging.json ✗ (not found)
   
   Query approval system...
   Found:
   - alice@company.com approved ✓
   - No second approval yet

3. IDENTIFY GAPS
   Missing: build attestation, staging verification, 1 approval

4. OPTIMIZE PATH
   - Request second approval NOW (human latency is longest)
   - Run build while waiting (creates build.json)
   - Deploy to staging after build
   - Verify staging (creates staging.json)
   - By then, approval likely received
   
5. EXECUTE OPTIMAL PATH
   Parallel:
   - Slack @oncall: "Approval needed for deploy abc123"
   - Run: npm run build (attest=true, step=build)
   
   Sequential (after build):
   - Deploy to staging
   - Run verification
   
   Gate:
   - Wait for approval (poll or webhook)
   - All preconditions met → deploy to prod

Advanced AI Capabilities

The AI can go beyond simple satisfaction:

┌─────────────────────────────────────────────────────────────────────┐
│                    AI Policy Intelligence                            │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  1. REUSE EXISTING PROOFS                                           │
│     "Attestation for tree abc123 exists from CI run 2 hours ago.   │
│      I can reference it instead of re-running tests."              │
│                                                                      │
│  2. PREDICT FAILURES                                                │
│     "Build will likely fail - I see a TypeScript error in the      │
│      changes. Let me fix it before wasting time on attestation."   │
│                                                                      │
│  3. OPTIMIZE FOR LATENCY                                            │
│     "Human approval takes ~15 mins on average. Request it first,   │
│      run automated checks in parallel."                            │
│                                                                      │
│  4. SUGGEST POLICY IMPROVEMENTS                                     │
│     "Lint has never failed in 6 months. Consider making it         │
│      optional to speed up the pipeline."                           │
│                                                                      │
│  5. FIND EQUIVALENT SATISFACTIONS                                   │
│     "Policy requires 'security_scan'. I found an existing          │
│      Snyk attestation that satisfies the same requirement."        │
│                                                                      │
│  6. CACHE STRATEGIES                                                │
│     "These attestations expire in 24h. I'll refresh them during    │
│      off-hours to reduce wait time during deploys."                │
│                                                                      │
│  7. EXPLAIN BLOCKERS                                                │
│     "Cannot deploy: missing approval from oncall. Current oncall   │
│      is @bob (from PagerDuty). Shall I ping them?"                 │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

The Paradigm Shift

┌─────────────────────────────────────────────────────────────────────┐
│                                                                      │
│  Prompt Engineering:     "Don't do bad things"                      │
│                          - Negative constraint                      │
│                          - Vague boundaries                         │
│                          - AI guesses what's allowed                │
│                                                                      │
│  Verification Eng:       "To do X, satisfy Y"                       │
│                          - Positive goal                            │
│                          - Specific requirements                    │
│                          - AI knows exactly what's needed           │
│                                                                      │
│  AI + Policy:            "Y requires {a,b,c}. Let me find          │
│                           the optimal path to {a,b,c}"              │
│                          - Creative problem solving                 │
│                          - Multiple valid solutions                 │
│                          - AI as an optimization engine             │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Implementation in AgentFlow

// AI reads policy before execution
policy := workflow.GetPolicy()

// AI analyzes what's needed vs what exists
gaps := policy.AnalyzeGaps(ctx, archivistaClient)

// AI generates optimal execution plan
plan := ai.GeneratePlan(gaps, constraints{
    MinimizeLatency: true,
    ReuseExisting:   true,
    ParallelizeMax:  true,
})

// Plan might look like:
// 1. [PARALLEL] Request approval + Run build
// 2. [SEQUENTIAL] Deploy staging → Verify staging  
// 3. [GATE] Wait for approval
// 4. [EXECUTE] Deploy prod

// Execute with full attestation
result := workflow.ExecutePlan(ctx, plan)

Benefits

1. Faster execution - AI finds optimal paths, reuses existing proofs
2. Smarter automation - AI predicts failures, suggests improvements
3. Transparent reasoning - AI explains why it chose a path
4. Adaptive behavior - AI adjusts strategy based on current state
5. Human-AI collaboration - AI handles logistics, humans make decisions

The Policy is a Goal, Not a Cage

┌─────────────────────────────────────────────────────────────────────┐
│                                                                      │
│   The policy doesn't restrict the AI.                               │
│   The policy gives the AI a goal.                                   │
│                                                                      │
│   The AI doesn't fight the policy.                                  │
│   The AI solves the policy.                                         │
│                                                                      │
│   Creativity is unbounded: HOW to satisfy the policy               │
│   Capability is bounded: WHAT counts as satisfaction               │
│                                                                      │
│   The result: Safe AND intelligent automation                       │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

This transforms the AI from a "constrained agent" into a "goal-seeking optimizer" - creative within verified bounds.

[colek42]

Converting Prompt Instructions to Witness Policies

Real-world example: Converting Judge's SSP generation prompts into verifiable policies.

Current State: Hope-Based Instructions

From inventory_builder.go:

"NEVER create components per instance/pod/container/queue"
"Rule 1: Scope Screen - IN SCOPE if federal data OR CIA impact"
"Rule 2: Merge Test - ALL FOUR must match to merge"
"Anti-Bloat Rules (CRITICAL)"

From control_implementation.go:

"DO NOT generate UUIDs - leave the uuid field empty"
"Do NOT set remarks - they will be handled separately"
"Evidence paths MUST be relative to repository root"
"Include workspace/ prefix in all paths"
"DO NOT use absolute paths starting with /"

These are hope-based - we hope the AI follows them.

Converted: Math-Based Policies

# inventory-builder-policy.yaml
name: fedramp-inventory-builder
version: 1.0.0
agent: spiffe://company.com/agent/ssp-builder

preconditions:
  inventory_build:
    requires:
      # Must have analyzed scope first
      - type: attestation
        step: scope_analysis
        contains: [cia_impact_matrix, data_classification]
      
      # Must have repository context
      - type: file_exists
        path: workspace/repository-context.txt

output_validation:
  component_schema:
    # Enforce component CLASS naming, not instance naming
    title_patterns:
      allow:
        - "*Tier"           # "Stateless Microservices Tier"
        - "*Class"          # "Customer Data Store Class"  
        - "*Services"       # "Security Services"
        - "*Management"     # "Key Management"
      deny:
        - "*-1"             # "postgres-1" ❌
        - "*-2"             # "service-2" ❌
        - "*-pod-*"         # "web-pod-123" ❌
        - "*-instance-*"    # "ec2-instance-abc" ❌
        - "*-queue-*"       # "sqs-queue-orders" ❌
    
    # Required fields
    required_props:
      - trust-boundary
      - operator
      - data-types
    
    # Anti-bloat enforcement
    count:
      max: 20
      warn: 12
      require_justification_over: 15

postconditions:
  inventory_complete:
    must_produce:
      - type: attestation
        contains: [component_count, scope_justifications]
      - type: validation
        rule: components_align_with_abd

# control-implementation-policy.yaml
name: control-implementation
version: 1.0.0
agent: spiffe://company.com/agent/control-analyst

preconditions:
  implement_control:
    requires:
      # Must have component inventory first
      - type: attestation
        step: inventory_build
        outcome: success

output_validation:
  # "DO NOT generate UUIDs" → enforced empty
  evidence_uuid:
    pattern: "^$"
    error: "UUID must be empty - system auto-generates"
  
  # "Do NOT set remarks" → enforced null
  statement_remarks:
    must_be_null: true
    error: "Remarks must be null - handled separately"
  
  # "paths MUST be relative" + "workspace/ prefix" → pattern enforcement
  evidence_uri:
    patterns:
      allow:
        - "^workspace/.*"
        - "^workspace/.+\\.(go|ts|yaml|md):\\d+-\\d+$"
      deny:
        - "^/.*"      # No absolute paths
        - "^\\./.*"   # No ./ prefix  
        - "^https?://.*"  # No URLs for file evidence
    error: "Paths must be relative, starting with workspace/"
  
  # Implementation status validation
  implementation_status:
    enum: [implemented, partial, planned]
    rules:
      implemented:
        requires_all: [technical_capability, process_docs, params_defined]
      partial:
        requires: [technical_capability]
        missing_any: [process_docs, params_defined]
      planned:
        missing: [technical_capability]

postconditions:
  control_implemented:
    must_produce:
      - type: validation
        rule: all_evidence_files_exist

The Transformation

┌─────────────────────────────────────────────────────────────────────┐
│                    Prompt → Policy                                   │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  PROMPT (Hope):                        POLICY (Math):               │
│                                                                      │
│  "NEVER create components             title_patterns:               │
│   per instance/pod"                     deny: ["*-1", "*-pod-*"]    │
│                                                                      │
│  "DO NOT generate UUIDs"              evidence_uuid:                │
│                                         pattern: "^$"               │
│                                                                      │
│  "paths MUST be relative"             evidence_uri:                 │
│                                         allow: ["^workspace/.*"]    │
│                                         deny: ["^/.*"]              │
│                                                                      │
│  "Do NOT set remarks"                 statement_remarks:            │
│                                         must_be_null: true          │
│                                                                      │
│  Hope AI follows ───────────▶         Output rejected if invalid   │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

AI Adapts to Policy

When the AI can read the policy, it generates compliant output:

AI reasoning:

"I need to create a component. Let me check the policy...

 Policy says:
 - title must match: *Tier, *Class, *Services, *Management
 - title must NOT match: *-1, *-pod-*, *-instance-*
 - uuid must be empty string
 - paths must start with 'workspace/'

 Generating compliant output:
 
 {
   "title": "Stateless Microservices Tier",  ✓ (matches *Tier)
   "uuid": "",                                ✓ (empty as required)
   "evidence": [{
     "uri": "workspace/judge/api/main.go:12-46"  ✓ (workspace/ prefix)
   }]
 }
 
 This will pass validation."

Side-by-Side Comparison

Prompt Instruction	Policy Rule	Enforcement
"NEVER create per instance"	deny: ["*-1", "*-pod-*"]	Output rejected
"DO NOT generate UUIDs"	pattern: "^$"	Output rejected
"MUST be relative paths"	allow: ["^workspace/.*"]	Output rejected
"Do NOT set remarks"	must_be_null: true	Output rejected
"Include workspace/ prefix"	must_start_with: "workspace/"	Output rejected
"Max 20 components"	count: { max: 20 }	Output rejected

Benefits of Conversion

1. No jailbreaks: Can't convince policy to accept invalid output
2. Clear errors: "title 'postgres-1' denied by pattern '*-1'"
3. Auditable: Every validation decision is attested
4. Versionable: Policy changes are tracked, signed, approved
5. Testable: Can verify policy catches violations before deployment

Migration Path

Phase 1: Extract rules from prompts
         ↓
Phase 2: Convert to policy schema
         ↓
Phase 3: Run both (prompt + policy validation)
         ↓
Phase 4: Remove rules from prompts
         ↓
Phase 5: Policy-only enforcement

Real Output Example

Before (prompt-only):

{
  "title": "postgres-1",           // ❌ Violates "no instances"
  "uuid": "abc-123-def",           // ❌ Violates "no UUIDs"
  "evidence": [{
    "uri": "/Users/nkennedy/..."   // ❌ Violates "relative paths"
  }]
}
// AI might generate this. We hope it doesn't.

After (policy-enforced):

{
  "title": "postgres-1",           // ❌ REJECTED: matches deny pattern "*-1"
}
// Policy stops execution. AI must fix before continuing.

AI adapts:

{
  "title": "Customer Data Store Class",  // ✓ matches "*Class"
  "uuid": "",                            // ✓ empty as required
  "evidence": [{
    "uri": "workspace/judge/db/..."      // ✓ relative with prefix
  }]
}
// Policy accepts. Attestation created.

This transforms prompt engineering ("please follow these rules") into verification engineering ("output must pass these checks").

[colek42]

AI Evaluators: Semantic Policy Validation

Extend Witness policies with AI evaluators alongside Rego evaluators - combining deterministic structural checks with semantic understanding.

Two Types of Evaluators

┌─────────────────────────────────────────────────────────────────────┐
│                    Evaluator Types                                   │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  REGO EVALUATOR                    AI EVALUATOR                     │
│  ──────────────                    ────────────                     │
│                                                                      │
│  • Deterministic                   • Semantic understanding         │
│  • Pattern matching                • Intent analysis                │
│  • Fast execution                  • Context-aware                  │
│  • Binary pass/fail                • Nuanced judgment               │
│  • Reproducible                    • Explains reasoning             │
│                                                                      │
│  Good for:                         Good for:                        │
│  • "Path must start with X"        • "Is this a good description?"  │
│  • "Count must be < 20"            • "Does this make sense?"        │
│  • "UUID must be empty"            • "Is this actually evidence?"   │
│  • Structural validation           • Semantic validation            │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Policy Schema Extension

{
  "steps": {
    "inventory_build": {
      "attestations": [{
        "type": "command-run",
        
        "regopolicies": [
          {
            "name": "structural_checks",
            "module": "base64(rego for count, patterns, required fields)"
          }
        ],
        
        "aipolicies": [
          {
            "name": "description_quality",
            "model": "claude-haiku",
            "prompt": "Evaluate if this component description...",
            "output_schema": {
              "pass": "boolean",
              "confidence": "number", 
              "issues": "array",
              "reasoning": "string"
            },
            "threshold": {
              "pass": true,
              "confidence_min": 0.85
            }
          }
        ]
      }]
    }
  }
}

Example AI Evaluators

ai_policies:
  # Check if descriptions are FedRAMP-quality
  - name: "description_quality"
    model: "claude-haiku"
    prompt: |
      Evaluate this component description for FedRAMP compliance:
      
      Description: {{.description}}
      Component Type: {{.type}}
      
      Check:
      1. Is it specific enough to understand what this component does?
      2. Does it explain the security function?
      3. Would a 3PAO auditor understand it?
      4. Is it free of vague marketing language?
      
      Return JSON: {pass: bool, confidence: 0-1, issues: [], suggestion: ""}
    threshold:
      pass: true
      confidence_min: 0.85
  
  # Check if evidence actually supports the claim
  - name: "evidence_relevance"
    model: "claude-haiku"
    prompt: |
      Does this evidence actually support the control implementation?
      
      Control: {{.control_id}} - {{.control_title}}
      Statement: {{.statement_text}}
      Claimed Implementation: {{.implementation}}
      Evidence: {{.evidence_description}}
      
      Is this evidence relevant and sufficient, or tangential?
      
      Return JSON: {relevant: bool, confidence: 0-1, reasoning: ""}
    threshold:
      relevant: true
      confidence_min: 0.8

  # Anti-hallucination check
  - name: "claim_verification"
    model: "claude-sonnet"
    prompt: |
      Verify this implementation claim against the evidence:
      
      Claim: "{{.implementation}}"
      Evidence files: {{.evidence_uris}}
      Evidence content: {{.evidence_snippets}}
      
      Is the claim actually supported by this evidence?
      Or is it hallucinated/exaggerated?
      
      Return JSON: {
        supported: bool,
        confidence: 0-1,
        unsupported_claims: [],
        reasoning: ""
      }
    threshold:
      supported: true
      confidence_min: 0.9

  # Component naming check
  - name: "naming_convention"
    model: "claude-haiku"
    prompt: |
      Is this component name a CLASS or an INSTANCE?
      
      Name: "{{.title}}"
      Description: "{{.description}}"
      
      FedRAMP requires component CLASSES (e.g., "Stateless Microservices Tier")
      not INSTANCES (e.g., "postgres-1", "web-pod-abc").
      
      Return JSON: {
        is_class: bool,
        confidence: 0-1,
        suggestion: "better name if instance"
      }
    threshold:
      is_class: true

Evaluation Pipeline

┌─────────────────────────────────────────────────────────────────────┐
│                    Dual Evaluation Pipeline                          │
└─────────────────────────────────────────────────────────────────────┘

                        AI Agent Output
                              │
                              ▼
              ┌───────────────────────────────┐
              │      REGO EVALUATORS          │
              │      (fast, structural)       │
              │                               │
              │  ✓ Path format valid          │
              │  ✓ UUID empty                 │
              │  ✓ Count < 20                 │
              │  ✓ Required fields present    │
              │                               │
              │  Milliseconds, deterministic  │
              └───────────────────────────────┘
                              │
                              ▼ (if Rego passes)
              ┌───────────────────────────────┐
              │      AI EVALUATORS            │
              │      (slower, semantic)       │
              │                               │
              │  ? Description quality        │
              │  ? Evidence relevance         │
              │  ? Claim verification         │
              │  ? Naming conventions         │
              │                               │
              │  Seconds, with reasoning      │
              └───────────────────────────────┘
                              │
                              ▼
              ┌───────────────────────────────┐
              │      COMBINED ATTESTATION     │
              │                               │
              │  • Rego results (pass/fail)   │
              │  • AI results (with reasoning)│
              │  • Confidence scores          │
              │  • Full evaluation trace      │
              │                               │
              └───────────────────────────────┘

AI Evaluation Attestation

{
  "type": "https://witness.dev/attestations/ai-evaluation/v0.1",
  "predicate": {
    "evaluator": {
      "model": "claude-haiku",
      "model_version": "claude-3-haiku-20240307",
      "policy_name": "description_quality",
      "prompt_hash": "sha256:def456..."
    },
    "input": {
      "hash": "sha256:abc123...",
      "fields_evaluated": ["description", "type", "title"]
    },
    "result": {
      "pass": true,
      "confidence": 0.92,
      "issues": [],
      "reasoning": "Description clearly explains the security function of the component, specifies the trust boundary, and would be understandable to a 3PAO auditor."
    },
    "timestamp": "2024-01-15T10:30:00Z",
    "duration_ms": 847
  }
}

Trust Model for AI Evaluators

┌─────────────────────────────────────────────────────────────────────┐
│                    AI Evaluator Trust Model                          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  CONCERN                           MITIGATION                       │
│                                                                      │
│  Non-deterministic                 → Attestation includes reasoning │
│                                    → Confidence threshold required  │
│                                    → Human can audit reasoning      │
│                                                                      │
│  Could be jailbroken               → Evaluator is DIFFERENT AI      │
│                                    → Evaluator prompt is signed     │
│                                    → Evaluator runs under own policy│
│                                                                      │
│  Might miss things                 → Rego runs FIRST (structural)   │
│                                    → AI adds semantic layer         │
│                                    → Addition, not replacement      │
│                                                                      │
│  Reproducibility                   → Hash: input + prompt + output  │
│                                    → Log full evaluation context    │
│                                    → Record model + version         │
│                                                                      │
│  Gaming the evaluator              → Multiple AI evaluators vote    │
│                                    → Different models cross-check   │
│                                    → Human review for low confidence│
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Multi-Evaluator Consensus

For high-stakes decisions, require agreement across multiple AI evaluators:

ai_policies:
  - name: "critical_quality_check"
    consensus:
      evaluators:
        - model: claude-haiku
          weight: 1
        - model: gpt-4o-mini  
          weight: 1
        - model: claude-sonnet
          weight: 2  # Tie-breaker, higher capability
      
      strategy: "weighted_majority"
      min_agreement: 0.66
      require_reasoning_alignment: true
      
      on_disagreement:
        action: "flag_for_human_review"
        include: ["all_reasoning", "confidence_scores"]

Layered Validation Model

┌─────────────────────────────────────────────────────────────────────┐
│                    Validation Layers                                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Layer 1: SCHEMA (instant)                                          │
│  └─▶ JSON schema validation                                         │
│  └─▶ Required fields present                                        │
│  └─▶ Type checking                                                  │
│                                                                      │
│  Layer 2: REGO (milliseconds)                                       │
│  └─▶ Pattern matching                                               │
│  └─▶ Numeric constraints                                            │
│  └─▶ Cross-field logic                                              │
│  └─▶ Deterministic rules                                            │
│                                                                      │
│  Layer 3: AI (seconds)                                              │
│  └─▶ Semantic quality                                               │
│  └─▶ Intent verification                                            │
│  └─▶ Hallucination detection                                        │
│  └─▶ Context-aware judgment                                         │
│                                                                      │
│  Layer 4: HUMAN (minutes/hours) - optional                          │
│  └─▶ Low confidence review                                          │
│  └─▶ Disagreement resolution                                        │
│  └─▶ Final approval for critical paths                              │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Benefits

1. Catch semantic issues that Rego can't express
2. Anti-hallucination - verify claims against evidence
3. Quality enforcement - "good enough" isn't good enough
4. Explainable - AI provides reasoning, not just pass/fail
5. Auditable - all evaluations are attested with full context
6. Layered - fast checks first, expensive checks last

Use Cases

Use Case	Rego	AI
Path format	✓
Field presence	✓
Count limits	✓
Description quality		✓
Evidence relevance		✓
Claim verification		✓
Naming conventions	✓	✓
Security implications		✓

This creates AI-in-the-loop for policy evaluation - the evaluating AI is different from the producing AI, creating a check-and-balance system with full attestation.

[colek42]

Concrete Example: Policy-Aware AgentFlow Workflows

Here's what policy-aware workflows look like in practice, using Judge's SSP generation as an example.

Current State (No Policy)

// Hope-based: AI might not follow prompt instructions
workflow := agentflow.NewWorkflow("ssp-generation").
    AddTask("scout", agentflow.ClaudeCodeTask{
        Prompt: systemScoutPrompt,
        Tools:  []string{"update_ssp_metadata"},
    }).
    AddTask("inventory", agentflow.ClaudeCodeTask{
        Prompt: inventoryBuilderPrompt,  // Says "NEVER create per-instance"
        Tools:  []string{"manage_system_inventory"},
    }).
    AddTask("controls", agentflow.ClaudeCodeTask{
        Prompt: controlImplementationPrompt,  // Says "DO NOT generate UUIDs"
        Tools:  []string{"add_statement_impl"},
    }).
    Build()

With Policy Integration

workflow := agentflow.NewWorkflow("ssp-generation").
    
    // Identity: Who is running this?
    WithIdentity(agentflow.Identity{
        SPIFFE: "spiffe://company.com/agent/ssp-builder",
    }).
    
    // Policy: What rules apply?
    WithPolicy("archivista://policies/ssp/fedramp-moderate").
    
    AddTask("scout", agentflow.ClaudeCodeTask{
        Prompt: systemScoutPrompt,
        Tools:  []string{"update_ssp_metadata", "manage_information_types"},
        
        Policy: agentflow.TaskPolicy{
            Preconditions: []agentflow.Condition{
                {Type: "file_exists", Path: "workspace/repository-context.txt"},
            },
            OutputValidation: []agentflow.RegoPolicy{
                {Name: "metadata_schema", Module: metadataRegoPolicy},
            },
            AIValidation: []agentflow.AIPolicy{
                {
                    Name:      "description_quality",
                    Model:     "claude-haiku",
                    Prompt:    "Is this system description clear and complete?",
                    Threshold: 0.85,
                },
            },
        },
    }).
    
    AddTask("inventory", agentflow.ClaudeCodeTask{
        Prompt: inventoryBuilderPrompt,
        Tools:  []string{"manage_system_inventory"},
        
        Policy: agentflow.TaskPolicy{
            // Must have completed scout first
            Preconditions: []agentflow.Condition{
                {Type: "attestation", Step: "scout", Outcome: "success"},
            },
            
            // Structural validation (Rego)
            OutputValidation: []agentflow.RegoPolicy{
                {Name: "anti_bloat", Module: antiBloatRego},
                {Name: "component_naming", Module: componentNamingRego},
            },
            
            // Semantic validation (AI)
            AIValidation: []agentflow.AIPolicy{
                {
                    Name:   "fedramp_compliance",
                    Model:  "claude-haiku",
                    Prompt: "Does this inventory follow FedRAMP component guidelines?",
                },
            },
            
            // Hard constraints
            Constraints: agentflow.Constraints{
                MaxComponents: 20,
                RequiredProps: []string{"trust-boundary", "operator"},
            },
        },
    }).
    
    AddTask("controls", agentflow.ClaudeCodeTask{
        Prompt: controlImplementationPrompt,
        Tools:  []string{"add_statement_impl", "get_statements"},
        
        Policy: agentflow.TaskPolicy{
            Preconditions: []agentflow.Condition{
                {Type: "attestation", Step: "inventory", Outcome: "success"},
            },
            
            OutputValidation: []agentflow.RegoPolicy{
                {Name: "path_format", Module: pathFormatRego},
                {Name: "uuid_empty", Module: uuidEmptyRego},
                {Name: "no_remarks", Module: noRemarksRego},
            },
            
            AIValidation: []agentflow.AIPolicy{
                {Name: "evidence_relevance", Prompt: "Does evidence support the claim?"},
                {Name: "anti_hallucination", Prompt: "Is this claim supported by files?"},
            },
        },
    }).
    
    // Workflow-level postconditions
    WithPostconditions(agentflow.Postconditions{
        RequireAttestations: []string{"scout", "inventory", "controls"},
        OutputArtifacts:     []string{"ssp.json"},
    }).
    
    // Audit trail
    WithAudit(agentflow.AuditConfig{
        Destination: "archivista://attestations/ssp",
        SignWith:    witnessSigner,
    }).
    
    Build()

Runtime Execution Flow

Task: "inventory"
─────────────────

1. CHECK PRECONDITIONS
   ┌────────────────────────────────────────┐
   │ Query: Does "scout" attestation exist? │
   │ Result: ✓ Found in Archivista          │
   └────────────────────────────────────────┘
                    │
                    ▼
2. EXECUTE TASK
   ┌────────────────────────────────────────┐
   │ Claude runs inventoryBuilderPrompt     │
   │ Output: {components: [...]}            │
   └────────────────────────────────────────┘
                    │
                    ▼
3. REGO VALIDATION (milliseconds)
   ┌────────────────────────────────────────┐
   │ anti_bloat.rego:                       │
   │   ✓ No "*-1" patterns                  │
   │   ✓ No "*-pod-*" patterns              │
   │   ✓ Count = 9 (< 20)                   │
   │                                        │
   │ component_naming.rego:                 │
   │   ✓ All titles match allowed patterns │
   └────────────────────────────────────────┘
                    │
                    ▼
4. AI VALIDATION (seconds)
   ┌────────────────────────────────────────┐
   │ fedramp_compliance (claude-haiku):     │
   │   Result: {                            │
   │     pass: true,                        │
   │     confidence: 0.91,                  │
   │     reasoning: "Components follow..."  │
   │   }                                    │
   └────────────────────────────────────────┘
                    │
                    ▼
5. CREATE ATTESTATION
   ┌────────────────────────────────────────┐
   │ {                                      │
   │   "step": "inventory",                 │
   │   "outcome": "success",                │
   │   "rego_results": [{passed: true}],    │
   │   "ai_results": [{confidence: 0.91}],  │
   │   "output_hash": "sha256:abc...",      │
   │   "identity": "spiffe://...ssp-builder"│
   │ }                                      │
   │ → Signed, stored in Archivista         │
   └────────────────────────────────────────┘
                    │
                    ▼
6. NEXT TASK ("controls" precondition now met)

Validation Failure Example

Output from Claude:
{
  "components": [
    {"title": "postgres-1", ...},    // ❌ Instance name
    {"title": "web-pod-abc", ...},   // ❌ Pod reference
  ]
}

Rego Validation: FAILED
┌────────────────────────────────────────┐
│ anti_bloat.rego:                       │
│                                        │
│ deny[msg] triggered:                   │
│ - "postgres-1 matches deny pattern"    │
│ - "web-pod-abc matches deny pattern"   │
│                                        │
│ Status: OUTPUT REJECTED                │
└────────────────────────────────────────┘

AI Validation: SKIPPED (Rego failed)

Attestation:
{
  "step": "inventory",
  "outcome": "failed",
  "rego_results": [{
    "policy": "anti_bloat",
    "passed": false,
    "denials": [
      "postgres-1 matches instance pattern *-1",
      "web-pod-abc references individual pod"
    ]
  }],
  "retry_hint": "Use class names: 'Database Tier', not 'postgres-1'"
}

→ AI must fix output and retry
→ Or escalate to human review

The Key Difference

┌─────────────────────────────────────────────────────────────────────┐
│                                                                      │
│  WITHOUT POLICY:                                                    │
│  ───────────────                                                    │
│  Prompt: "NEVER create per-instance components"                     │
│  AI generates: {"title": "postgres-1"}                              │
│  Result: Accepted ❌                                                │
│  Outcome: Bad data in SSP                                           │
│                                                                      │
│  WITH POLICY:                                                       │
│  ────────────                                                       │
│  Rego: deny { regex.match(".*-[0-9]+$", input.title) }             │
│  AI generates: {"title": "postgres-1"}                              │
│  Result: REJECTED ✓                                                 │
│  Outcome: AI must fix before continuing                             │
│                                                                      │
│  The prompt is a suggestion.                                        │
│  The policy is a gate.                                              │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Rego Policies (Concrete Examples)

# anti_bloat.rego
package inventory.anti_bloat

deny[msg] {
    component := input.components[_]
    regex.match(".*-[0-9]+$", component.title)
    msg := sprintf("'%s' looks like an instance name, not a class", [component.title])
}

deny[msg] {
    component := input.components[_]
    contains(lower(component.title), "-pod-")
    msg := sprintf("'%s' references individual pod", [component.title])
}

deny[msg] {
    count(input.components) > 20
    msg := sprintf("Too many components (%d > 20). Merge similar ones.", [count(input.components)])
}

# path_format.rego
package evidence.paths

deny[msg] {
    evidence := input.evidence[_]
    startswith(evidence.uri, "/")
    msg := sprintf("Path '%s' is absolute. Must be relative.", [evidence.uri])
}

deny[msg] {
    evidence := input.evidence[_]
    not startswith(evidence.uri, "workspace/")
    msg := sprintf("Path '%s' must start with 'workspace/'", [evidence.uri])
}

# uuid_empty.rego
package evidence.uuid

deny[msg] {
    evidence := input.evidence[_]
    evidence.uuid != ""
    msg := "UUID must be empty - system auto-generates"
}

Benefits

1. Prompt rules become enforceable - Not suggestions, gates
2. Failures are clear - Rego tells you exactly what's wrong
3. AI can self-correct - Gets specific error messages
4. Full attestation - Every validation decision is recorded
5. Preconditions prevent chaos - Tasks run in correct order
6. AI evaluators catch semantics - Quality, not just structure

This is "verification > prompts" made concrete in AgentFlow.

[colek42]

Output Attestation: Attest Tool Returns, Not Just Execution

Create attestations on the actual outputs from tools, not just that they ran.

Current vs Output Attestation

┌─────────────────────────────────────────────────────────────────────┐
│                                                                      │
│  CURRENT: Attest execution only                                     │
│  ───────────────────────────────                                    │
│  {                                                                   │
│    "type": "command-run",                                           │
│    "cmd": ["npm", "test"],                                          │
│    "exitcode": 0                                                    │
│  }                                                                   │
│  → Proves command ran                                               │
│  → Doesn't prove what it returned                                   │
│                                                                      │
│  NEW: Attest output + validation                                    │
│  ───────────────────────────────                                    │
│  {                                                                   │
│    "type": "tool-output",                                           │
│    "tool": "manage_system_inventory",                               │
│    "input_hash": "sha256:abc...",                                   │
│    "output": {...actual data...},                                   │
│    "output_hash": "sha256:def...",                                  │
│    "validation": {                                                  │
│      "rego": [{"policy": "anti_bloat", "passed": true}],           │
│      "ai": [{"policy": "quality", "confidence": 0.91}]             │
│    }                                                                │
│  }                                                                   │
│  → Proves what was returned                                         │
│  → Proves it passed validation                                      │
│  → Full audit trail                                                 │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

The Flow

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   AI calls   │────▶│    Tool      │────▶│   Validate   │────▶│   Attest     │
│   tool       │     │   executes   │     │   output     │     │   output     │
└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
       │                    │                    │                    │
       │                    ▼                    ▼                    ▼
       │             ┌────────────┐       ┌────────────┐       ┌────────────┐
       │             │ Raw output │       │ Rego + AI  │       │ Signed     │
       │             │ from tool  │       │ validation │       │ attestation│
       │             └────────────┘       └────────────┘       └────────────┘
       │                                                              │
       │                                                              │
       └────────────────── Only if valid ─────────────────────────────┘
                           AI receives output

Implementation

func (s *Server) HandleToolCall(ctx context.Context, tool string, input map[string]any) (any, error) {
    // 1. Execute tool
    output, err := s.tools[tool].Execute(ctx, input)
    if err != nil {
        return nil, err
    }
    
    // 2. Validate output against policy
    validation, err := s.validateOutput(ctx, tool, output)
    if !validation.Passed {
        // Attest the failure too
        s.attestFailure(ctx, tool, input, output, validation)
        return nil, fmt.Errorf("validation failed: %v", validation.Errors)
    }
    
    // 3. Create attestation of valid output
    attestation := &ToolOutputAttestation{
        Tool:        tool,
        InputHash:   hash(input),
        Output:      output,
        OutputHash:  hash(output),
        Validation:  validation,
        Timestamp:   time.Now(),
        Identity:    getIdentity(ctx),
    }
    
    // 4. Sign and store
    signed, _ := witness.Sign(attestation)
    archivista.Store(signed)
    
    // 5. Return to AI
    return output, nil
}

Attestation Schema

{
  "type": "https://witness.dev/attestations/tool-output/v0.1",
  "predicate": {
    "tool": "manage_system_inventory",
    "action": "add",
    
    "input": {
      "hash": "sha256:abc123...",
      "summary": "Add component: Stateless Microservices Tier"
    },
    
    "output": {
      "hash": "sha256:def456...",
      "data": {
        "success": true,
        "component_id": "uuid-789",
        "component_count": 9
      }
    },
    
    "validation": {
      "rego_policies": [
        {
          "name": "anti_bloat",
          "passed": true,
          "duration_ms": 2
        },
        {
          "name": "component_naming",
          "passed": true,
          "duration_ms": 1
        }
      ],
      "ai_policies": [
        {
          "name": "fedramp_compliance",
          "model": "claude-haiku",
          "passed": true,
          "confidence": 0.91,
          "reasoning": "Component follows FedRAMP class naming conventions"
        }
      ]
    },
    
    "context": {
      "workflow": "ssp-generation",
      "task": "inventory",
      "identity": "spiffe://company.com/agent/ssp-builder",
      "timestamp": "2024-01-15T10:30:00Z",
      "git_tree_hash": "sha256:abc..."
    }
  }
}

Chain of Output Attestations

Each tool output references previous outputs, creating an auditable chain:

Tool Call 1: scout
├── input_hash: sha256:aaa
├── output_hash: sha256:bbb
├── validation: ✓ passed
└── attestation: signed, stored

        │ (output becomes input to next)
        ▼

Tool Call 2: inventory  
├── input_hash: sha256:ccc
├── output_hash: sha256:ddd
├── depends_on: sha256:bbb (scout output)
├── validation: ✓ passed
└── attestation: signed, stored

        │
        ▼

Tool Call 3: controls
├── input_hash: sha256:eee
├── output_hash: sha256:fff
├── depends_on: sha256:ddd (inventory output)
├── validation: ✓ passed
└── attestation: signed, stored

        │
        ▼

Workflow Complete:
├── attestation_chain: [scout, inventory, controls]
├── output_lineage: aaa→bbb→ccc→ddd→eee→fff
└── all_validations_passed: true

Benefits

Benefit	Description
Full Audit Trail	Every tool call: input + output + validation result
Replay Defense	Output is hashed and signed, can't be falsified
Policy Proof	Attestation proves output passed Rego + AI validation
Debugging	When something fails, complete trace available
Compliance	Auditors verify every AI action with tamper-proof records
Lineage	Track how outputs flow through the workflow

Failure Attestation

Even failures are attested (for audit):

{
  "type": "https://witness.dev/attestations/tool-output/v0.1",
  "predicate": {
    "tool": "manage_system_inventory",
    "outcome": "rejected",
    
    "output": {
      "hash": "sha256:bad123...",
      "data": {
        "component": {"title": "postgres-1"}
      }
    },
    
    "validation": {
      "rego_policies": [
        {
          "name": "anti_bloat",
          "passed": false,
          "denials": [
            "'postgres-1' matches instance pattern, use class name"
          ]
        }
      ]
    },
    
    "action_taken": "output_rejected",
    "retry_hint": "Use 'Database Tier' instead of 'postgres-1'"
  }
}

Query Examples

# Find all outputs from a workflow run
query {
  attestations(
    workflow: "ssp-generation",
    type: "tool-output"
  ) {
    tool
    output_hash
    validation { passed, confidence }
    timestamp
  }
}

# Find validation failures
query {
  attestations(
    type: "tool-output",
    outcome: "rejected"
  ) {
    tool
    validation { denials }
    retry_hint
  }
}

# Trace output lineage
query {
  outputLineage(final_hash: "sha256:fff") {
    chain {
      tool
      output_hash
      depends_on
    }
  }
}

Integration with Existing Attestation Types

Output attestation complements existing types:

┌─────────────────────────────────────────────────────────────────────┐
│                    Attestation Stack                                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  command-run     → Command was executed with exit code              │
│  git             → Repository state at execution time               │
│  environment     → Runtime environment variables                    │
│  material        → Input files/artifacts                            │
│  product         → Output files/artifacts                           │
│  tool-output     → Tool return values + validation [NEW]           │
│  ai-evaluation   → AI evaluator results [NEW]                      │
│                                                                      │
│  Together: Complete proof of what happened, what was returned,      │
│            how it was validated, and what the AI received           │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

This closes the loop: we attest not just that tools ran, but what they returned and whether it was valid.

[colek42]

Proposed AI Governance Attestors (Based on go-witness Architecture)

After analyzing the go-witness v0.8.3 attestor architecture, here are concrete attestor types for AI governance that follow existing patterns.

Attestor Architecture Alignment

All proposed attestors:

• Implement attestation.Attestor interface (Name(), Type(), RunType(), Attest(), Schema())
• Use cryptoutil.DigestSet for sensitive data (never raw storage)
• Implement optional interfaces (Subjecter, Producer, Materialer, BackReffer) where appropriate
• Register via package init() with configuration options
• Follow existing predicate type URI pattern: https://witness.dev/attestations/{name}/v0.1

---

1. AI Session Attestor (ai-session)

RunType: PreMaterialRunType
Purpose: Establish agent identity and session context before any tool execution.

type Attestor struct {
    AgentID            string                   `json:"agentId"`
    AgentType          string                   `json:"agentType"`       // "claude-code", "cursor", "copilot"
    ModelID            string                   `json:"modelId"`         // "claude-opus-4-5-20251101"
    SessionID          string                   `json:"sessionId"`
    OIDCIssuer         string                   `json:"oidcIssuer,omitempty"`
    OIDCSubject        string                   `json:"oidcSubject,omitempty"`
    PolicyRef          string                   `json:"policyRef,omitempty"`
    PolicyDigest       cryptoutil.DigestSet     `json:"policyDigest,omitempty"`
    ConversationDigest cryptoutil.DigestSet     `json:"conversationDigest,omitempty"`
    MessageCount       int                      `json:"messageCount"`
}

Implements: Subjecter (session ID + policy as subjects)

---

2. Tool Invocation Attestor (tool-invocation)

RunType: ExecuteRunType
Purpose: Core AI action attestation - what tool was called, with what args, producing what output.

type Attestor struct {
    ToolName       string                          `json:"toolName"`        // "Bash", "Read", "Write"
    InvocationID   string                          `json:"invocationId"`
    DurationMs     int64                           `json:"durationMs"`
    InputDigest    cryptoutil.DigestSet            `json:"inputDigest"`
    Command        string                          `json:"command,omitempty"`
    OutputDigest   cryptoutil.DigestSet            `json:"outputDigest"`
    ExitCode       *int                            `json:"exitCode,omitempty"`
    FilesRead      map[string]cryptoutil.DigestSet `json:"filesRead,omitempty"`
    FilesWritten   map[string]cryptoutil.DigestSet `json:"filesWritten,omitempty"`
    Tags           []string                        `json:"tags,omitempty"`  // ["test", "database"]
}

Implements: Producer (files written), Materialer (files read), Subjecter

---

3. Dependency Verification Attestor (dependency-verify)

RunType: PostProductRunType
Purpose: Prevent hallucinated packages by verifying dependencies against registries.

type Attestor struct {
    PackageManager   string                         `json:"packageManager"`  // "npm", "pip", "go"
    Dependencies     []DependencyCheck              `json:"dependencies"`
    TotalChecked     int                            `json:"totalChecked"`
    NotFound         int                            `json:"notFound"`        // Hallucinated!
    Vulnerable       int                            `json:"vulnerable"`
    Typosquatting    int                            `json:"typosquatting"`
}

type DependencyCheck struct {
    Name              string                 `json:"name"`
    Status            string                 `json:"status"`  // "verified", "not-found", "vulnerable"
    RegistryDigest    cryptoutil.DigestSet   `json:"registryDigest,omitempty"`
    SimilarPackages   []string               `json:"similarPackages,omitempty"`
    LevenshteinScore  float64                `json:"levenshteinScore,omitempty"`
    Vulnerabilities   []VulnRef              `json:"vulnerabilities,omitempty"`
}

Implements: Subjecter (verified packages), BackReffer (link to lockfile)

---

4. Code Review Attestor (code-review)

RunType: PostProductRunType
Purpose: AI-generated code review with structured findings for quality gates.

type Attestor struct {
    ReviewID         string                 `json:"reviewId"`
    ReviewerModel    string                 `json:"reviewerModel"`
    Findings         []Finding              `json:"findings"`
    Approved         bool                   `json:"approved"`
    BlockingFindings int                    `json:"blockingFindings"`
}

type Finding struct {
    Category       string                   `json:"category"`        // "security", "performance"
    Severity       string                   `json:"severity"`        // "critical", "high"
    File           string                   `json:"file"`
    StartLine      int                      `json:"startLine"`
    Title          string                   `json:"title"`
    Confidence     float64                  `json:"confidence"`
    FindingDigest  cryptoutil.DigestSet     `json:"findingDigest"`
}

Implements: Subjecter, Exporter

---

5. Change Impact Attestor (change-impact)

RunType: PostProductRunType
Purpose: Track AI changes and blast radius for audit and rollback.

type Attestor struct {
    ChangeSetID      string                 `json:"changeSetId"`
    SessionID        string                 `json:"sessionId"`
    BaseCommit       string                 `json:"baseCommit"`
    FilesModified    []FileChange           `json:"filesModified"`
    FunctionsChanged []FunctionChange       `json:"functionsChanged,omitempty"`
    APIsChanged      []APIChange            `json:"apisChanged,omitempty"`
    RiskScore        float64                `json:"riskScore"`       // 0.0-1.0
    RiskFactors      []RiskFactor           `json:"riskFactors"`
    RollbackCommand  string                 `json:"rollbackCommand,omitempty"`
}

Implements: Producer (modified files), Materialer (original files), BackReffer (base commit)

---

6. Compliance Gate Attestor (compliance-gate)

RunType: VerifyRunType
Purpose: Verify AI actions comply with policies - the enforcement layer.

type Attestor struct {
    GateID           string                 `json:"gateId"`
    PolicyDigest     cryptoutil.DigestSet   `json:"policyDigest"`
    Rules            []RuleEvaluation       `json:"rules"`
    Passed           bool                   `json:"passed"`
    BlockingFailures []RuleFailure          `json:"blockingFailures,omitempty"`
    Approvals        []Approval             `json:"approvals,omitempty"`
}

type RuleEvaluation struct {
    RuleID           string                 `json:"ruleId"`
    Passed           bool                   `json:"passed"`
    Blocking         bool                   `json:"blocking"`
    RegoModule       string                 `json:"regoModule,omitempty"`
    AIEvaluator      string                 `json:"aiEvaluator,omitempty"`
    AIConfidence     float64                `json:"aiConfidence,omitempty"`
}

type Approval struct {
    ApproverID       string                 `json:"approverId"`
    ApproverType     string                 `json:"approverType"`    // "human", "ai-evaluator"
    SignatureDigest  cryptoutil.DigestSet   `json:"signatureDigest,omitempty"`
}

Implements: Subjecter

---

Rego Policies for AI Attestors

Hallucination Prevention:

package witness.ai_governance

deny[msg] if {
    some attestor in input.predicate.attestations
    attestor.type == "https://witness.dev/attestations/dependency-verify/v0.1"
    attestor.attestation.notFound > 0
    
    some dep in attestor.attestation.dependencies
    dep.status == "not-found"
    
    msg := sprintf("Hallucinated package: %s (not in registry)", [dep.name])
}

Require Tests:

package witness.require_tests

allow if {
    some attestor in input.predicate.attestations
    attestor.type == "https://witness.dev/attestations/tool-invocation/v0.1"
    "test" in attestor.attestation.tags
    attestor.attestation.exitCode == 0
}

Change Risk Limit:

package witness.change_impact

deny[msg] if {
    some attestor in input.predicate.attestations
    attestor.type == "https://witness.dev/attestations/change-impact/v0.1"
    
    some api in attestor.attestation.apisChanged
    api.breaking == true
    not has_human_approval(input)
    
    msg := sprintf("Breaking API change requires human approval: %s", [api.endpoint])
}

---

Attestor Pipeline Flow

Session Start
    └── ai-session (PreMaterial) ─── captures identity, policy binding

Tool Call
    ├── ai-reasoning (PreMaterial) ─── captures decision context
    ├── tool-invocation (Execute) ─── wraps actual execution
    ├── dependency-verify (PostProduct) ─── validates packages
    ├── code-review (PostProduct) ─── AI reviews changes
    └── change-impact (PostProduct) ─── tracks blast radius

Git Push
    └── compliance-gate (Verify) ─── evaluates against policy

This mirrors the existing Witness pipeline where attestors run in phases, building evidence that's verified at the end.

Full proposal with JSON examples: judge-api/docs/ai-attestors-proposal.md

[colek42]

How AI Attestors Address Developer Pain Points

Connecting the proposed attestors to the pain points identified in our research:

Pain Point 1: Hallucinated Dependencies

Problem: AI suggests packages that don't exist, creating supply chain risks.

Solution: dependency-verify attestor

• Runs PostProduct after code is written
• Verifies each import against actual registry (npm, PyPI, crates.io)
• Detects typosquatting via Levenshtein distance
• Policy blocks push if notFound > 0

{
  "attestationType": "dependency-verify",
  "dependencies": [
    {"name": "expresss", "status": "not-found", "similarPackages": ["express"]}
  ],
  "notFound": 1
}

Verification > Prompts: Instead of "don't hallucinate packages", we cryptographically prove every package exists.

---

Pain Point 2: Security Vulnerabilities at Scale

Problem: AI writes insecure code faster than humans can review it.

Solution: code-review attestor + compliance-gate

• AI reviewer runs PostProduct, produces structured findings
• Findings have category, severity, confidence
• Compliance gate enforces: blockingFindings == 0 for security findings

{
  "attestationType": "code-review",
  "findings": [
    {"category": "security", "severity": "high", "title": "SQL injection", "confidence": 0.95}
  ],
  "approved": false,
  "blockingFindings": 1
}

Verification > Prompts: Instead of "write secure code", we require a security-focused review attestation before push.

---

Pain Point 3: Can't Track AI Changes

Problem: Unclear what AI modified, audit trail missing.

Solution: change-impact attestor + ai-session binding

• Session attestor links all actions to agent identity
• Change impact tracks every file before/after with digests
• Functions, types, APIs enumerated for blast radius
• Rollback command provided

{
  "attestationType": "change-impact",
  "sessionId": "sess_abc123",
  "filesModified": [
    {"path": "src/auth.ts", "beforeDigest": {"sha256": "..."}, "afterDigest": {"sha256": "..."}}
  ],
  "functionsChanged": [{"name": "authenticate", "callers": 5}],
  "rollbackCommand": "git revert abc123"
}

Verification > Prompts: Instead of asking AI to document changes, we capture immutable evidence of what changed.

---

Pain Point 4: Trust Gap ("Did AI Really Run Tests?")

Problem: No proof AI executed required steps.

Solution: tool-invocation attestor with tags

• Each tool call is attested with input/output digests
• Tags like ["test", "lint", "build"] for semantic matching
• Exit code and duration captured
• Files read/written tracked

{
  "attestationType": "tool-invocation",
  "toolName": "Bash",
  "command": "npm test",
  "tags": ["test", "npm"],
  "exitCode": 0,
  "outputDigest": {"sha256": "..."},
  "filesRead": {"package.json": {"sha256": "..."}}
}

Verification > Prompts: Instead of "run tests before pushing", we require signed attestation of test execution.

---

Pain Point 5: AI Makes Breaking Changes

Problem: AI modifies APIs without understanding impact.

Solution: change-impact + compliance-gate with risk scoring

• Change impact calculates risk score based on:
  • Files touched
  • Functions modified
  • APIs changed (especially breaking)
  • Callers affected
• Compliance gate requires human approval for high-risk changes

{
  "attestationType": "change-impact",
  "apisChanged": [
    {"endpoint": "/api/users", "method": "GET", "breaking": true}
  ],
  "riskScore": 0.85,
  "riskFactors": [
    {"factor": "breaking-api", "severity": "high"}
  ]
}

Policy:

deny[msg] if {
    attestor.attestation.riskScore > 0.7
    some api in attestor.attestation.apisChanged
    api.breaking == true
    not has_human_approval(input)
    msg := "Breaking API changes require human approval"
}

Verification > Prompts: Instead of "be careful with API changes", we enforce approval workflows for breaking changes.

---

The Complete Picture

Developer: "Add MFA to login"
    │
    ▼
AI Session Attestor ─── Agent identity, policy binding
    │
    ▼
AI Reasoning ─── Decision context captured (hashed)
    │
    ▼
Tool Invocations ─── Each file read/write attested
    │
    ▼
Dependency Verify ─── All imports validated against registries
    │
    ▼
Code Review ─── AI security review with confidence scores
    │
    ▼
Change Impact ─── Blast radius calculated, risk scored
    │
    ▼
Compliance Gate ─── All attestations verified against policy
    │
    ▼
Git Push ─── Allowed only if gate passes

Every step produces cryptographic evidence. Policy evaluates the evidence. Trust is verifiable, not assumed.

[colek42]

Work Authorization + Test Plan Validation: Two-Gate Model

This is the missing architectural piece that maps to NIST 800-53 CM-3 (Configuration Change Control) and SA-11 (Developer Testing).

The Concept

Every AI action needs TWO attestation gates:

┌─────────────────────────────────────────────────────────────────┐
│                     GATE 1: AUTHORIZATION                        │
│                                                                  │
│   work-authorization attestation (from JIRA/GitHub/ServiceNow)  │
│   "Is this work approved?"                                      │
│   "Is it within scope?"                                         │
│   "Who approved it?"                                            │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
                        AI AGENT WORKS
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                     GATE 2: VALIDATION                           │
│                                                                  │
│   test-plan-validation attestation                              │
│   "Does it work correctly?"                                     │
│   "Does it break existing functionality?"                       │
│   "Does it meet product quality standards?"                     │
└─────────────────────────────────────────────────────────────────┘

Work Authorization = Input Specification (what to do)
Test Plan Validation = Output Verification (did it work?)

---

Work Authorization Attestor (work-authorization)

Triggered by: Webhook from JIRA/GitHub/ServiceNow

type Attestor struct {
    TicketID         string                   `json:"ticketId"`
    TicketSystem     string                   `json:"ticketSystem"`     // "jira", "github"
    
    Requester        Identity                 `json:"requester"`
    Approvers        []Identity               `json:"approvers"`
    ApprovalType     string                   `json:"approvalType"`     // "human", "automated"
    
    AuthorizedScope  ScopeConstraints         `json:"authorizedScope"`
    AcceptanceCriteria []AcceptanceCriterion  `json:"acceptanceCriteria"`
    
    ChangeType       string                   `json:"changeType"`       // "feature", "bugfix"
    RiskLevel        string                   `json:"riskLevel"`        // "low", "medium", "high"
}

type ScopeConstraints struct {
    AllowedPaths     []string                 `json:"allowedPaths"`     // ["src/auth/**"]
    DeniedPaths      []string                 `json:"deniedPaths"`      // ["**/*.key"]
    AllowedCommands  []string                 `json:"allowedCommands"`  // ["npm test"]
    DeniedCommands   []string                 `json:"deniedCommands"`   // ["rm -rf"]
    ValidUntil       *time.Time               `json:"validUntil,omitempty"`
}

---

Test Plan Validation Attestor (test-plan-validation)

Triggered by: After AI completes work, runs product test plan

type Attestor struct {
    TestPlanID       string                   `json:"testPlanId"`
    TestPlanVersion  string                   `json:"testPlanVersion"`
    ProductID        string                   `json:"productId"`
    WorkAuthRef      string                   `json:"workAuthRef"`      // Links back to ticket
    
    Categories       []TestCategory           `json:"categories"`
    TotalTests       int                      `json:"totalTests"`
    Passed           int                      `json:"passed"`
    Failed           int                      `json:"failed"`
    
    CodeCoverage     *CoverageMetrics         `json:"codeCoverage,omitempty"`
    RegressionTests  []RegressionResult       `json:"regressionTests,omitempty"`
    
    Verdict          string                   `json:"verdict"`          // "pass", "fail"
    BlockingFailures int                      `json:"blockingFailures"`
}

type TestCategory struct {
    Name             string                   `json:"name"`             // "unit", "integration", "security"
    Required         bool                     `json:"required"`         // Must pass for gate
    Total            int                      `json:"total"`
    Passed           int                      `json:"passed"`
    Failed           int                      `json:"failed"`
}

---

Complete Flow

1. JIRA TICKET CREATED (JUDGE-1234: "Add MFA to login")
   └── Webhook → work-authorization attestation
       ├── Scope: src/auth/**, tests/auth/**
       ├── Acceptance: tests pass, coverage > 80%
       └── Valid until: 2025-01-22

2. AI AGENT STARTS
   └── ai-session attestation
       └── workAuthorizationRef → links to JUDGE-1234

3. AI EXECUTES (within scope)
   └── tool-invocation attestations
       ├── Write src/auth/mfa.go ✓ (in scope)
       ├── Write tests/auth/mfa_test.go ✓ (in scope)
       └── Edit src/secrets.go ✗ BLOCKED (denied path)

4. TESTS RUN
   └── test-plan-validation attestation
       ├── unit: 245/245 ✓
       ├── integration: 47/48 ✗ (1 failure)
       ├── security: 15/15 ✓
       └── Verdict: FAIL

5. GIT PUSH ATTEMPTED
   └── compliance-gate checks:
       ├── work-authorization exists? ✓
       ├── All actions in scope? ✓
       ├── test-plan-validation verdict? ✗ FAIL
       └── PUSH BLOCKED

6. AI FIXES ISSUE
   └── New test-plan-validation
       └── Verdict: PASS

7. GIT PUSH ALLOWED

---

Rego Policies

Require Work Authorization:

deny[msg] if {
    # No work authorization attestation exists
    not work_auth_exists
    msg := "No work authorization. Create a ticket first."
}

work_auth_exists if {
    some auth in input.predicate.attestations
    auth.type == "https://witness.dev/attestations/work-authorization/v0.1"
}

Enforce Scope:

deny[msg] if {
    some tool in input.predicate.attestations
    tool.type == "https://witness.dev/attestations/tool-invocation/v0.1"
    
    some file_path, _ in tool.attestation.filesWritten
    not path_in_scope(file_path)
    
    msg := sprintf("File %s outside authorized scope", [file_path])
}

Require Test Plan Pass:

deny[msg] if {
    some validation in input.predicate.attestations
    validation.type == "https://witness.dev/attestations/test-plan-validation/v0.1"
    validation.attestation.verdict \!= "pass"
    
    msg := sprintf("Test plan failed: %d blocking failures", [
        validation.attestation.blockingFailures
    ])
}

---

NIST 800-53 Mapping

Control	Requirement	Implementation
CM-3	Document & approve changes	Work authorization from ticket system
CM-3(2)	Test changes before deployment	Test plan validation required
CM-4	Analyze impact of changes	Regression tests in test plan
CM-5	Restrict change access	Scope constraints in work auth
SA-11	Developer testing	Test plan attestation
SA-11(1)	Static code analysis	Security category in test plan

---

The Key Insight

The ticket IS the change request.
The attestation IS the approval.
The test plan IS the acceptance test.
The policy IS the change control board.

No prompts. No hoping the AI follows rules. Cryptographic proof of:

1. Work was authorized (ticket exists, signed)
2. Work stayed in scope (attestation chain verified)
3. Work is correct (test plan passed)

This is CM-3 implemented in code.

[colek42]

Concrete Tool-Level Attestation Mapping

Every Claude Code tool maps to a tool-invocation attestation. Here's the concrete mapping:

Tool → Attestation Type

Tool	What Gets Attested	Policy Checks
Bash	command, exit code, stdout digest, files touched	allowedCommands, deniedCommands
Read	file path, file digest, lines read	allowedPaths (read)
Write	file path, content digest, bytes written	allowedPaths, deniedPaths
Edit	file path, before/after digest, diff	allowedPaths, deniedPaths
Task	agent type, prompt digest, parent session	allowedAgents, deniedAgents
WebFetch	URL, response digest	allowedDomains, deniedDomains

---

Example: Bash Tool Attestation

Tool Call:

{"tool": "Bash", "command": "npm test"}

Attestation:

{
  "toolName": "Bash",
  "invocationId": "inv_001",
  "sessionId": "sess_abc123",
  "workAuthRef": "att_workauth_xyz",
  "input": {
    "command": "npm test",
    "commandDigest": {"sha256": "9f86d081..."}
  },
  "outputDigest": {"sha256": "e3b0c442..."},
  "exitCode": 0,
  "tags": ["test", "npm"],
  "resourcesAccessed": [
    {"resourceType": "file", "resourceId": "package.json", "accessType": "read"},
    {"resourceType": "file", "resourceId": "coverage/lcov.info", "accessType": "write", "afterDigest": {"sha256": "..."}}
  ]
}

---

Example: Write Tool Attestation

Tool Call:

{"tool": "Write", "file_path": "src/auth/mfa.go", "content": "package auth..."}

Attestation:

{
  "toolName": "Write",
  "invocationId": "inv_002",
  "sessionId": "sess_abc123",
  "workAuthRef": "att_workauth_xyz",
  "input": {
    "filePath": "src/auth/mfa.go",
    "contentDigest": {"sha256": "7d865e95..."},
    "contentLength": 1547
  },
  "resourcesAccessed": [
    {
      "resourceType": "file",
      "resourceId": "src/auth/mfa.go",
      "accessType": "write",
      "beforeDigest": null,
      "afterDigest": {"sha256": "7d865e95..."}
    }
  ]
}

---

Work Authorization with Tool-Specific Scope

The JIRA ticket produces a work-authorization with tool-specific constraints:

{
  "ticketId": "JUDGE-1234",
  "summary": "Add MFA to login flow",
  "authorizedScope": {
    "allowedPaths": ["src/auth/**", "tests/auth/**", "package.json"],
    "deniedPaths": ["**/*.key", ".env*", "src/auth/secrets.go"],
    
    "allowedCommands": ["npm test*", "npm run build*", "go test ./..."],
    "deniedCommands": ["rm -rf *", "*--force*", "kubectl*"],
    
    "allowedDomains": ["docs.github.com", "pkg.go.dev"],
    "deniedDomains": ["*.onion", "pastebin.com"],
    
    "allowedAgents": ["Explore", "Plan"],
    "deniedAgents": ["helm-implementor"]
  }
}

---

Pre-Tool Hook Flow

Tool Call: Write src/auth/mfa.go
         │
         ▼
┌─────────────────────────────────┐
│       PRE-TOOL HOOK             │
│                                 │
│  1. Load work-authorization     │
│  2. Check: src/auth/mfa.go      │
│     - In allowedPaths? ✓        │
│     - In deniedPaths? ✗         │
│  3. Decision: ALLOW             │
└─────────────────────────────────┘
         │
         ▼
    Execute Write
    Create Attestation
         │
         ▼
Tool Call: Write .env.local
         │
         ▼
┌─────────────────────────────────┐
│       PRE-TOOL HOOK             │
│                                 │
│  1. Load work-authorization     │
│  2. Check: .env.local           │
│     - Matches ".env*" in        │
│       deniedPaths ✗             │
│  3. Decision: DENY              │
└─────────────────────────────────┘
         │
         ▼
    BLOCKED - No execution
    No attestation created
    Error: "Path explicitly denied"

---

Rego Policy: Pre-Write Check

package witness.write_policy

work_auth := auth if {
    some auth in data.attestations
    auth.type == "https://witness.dev/attestations/work-authorization/v0.1"
}

allow if {
    input.tool == "Write"
    path_allowed(input.file_path)
    not path_denied(input.file_path)
}

path_allowed(path) if {
    some pattern in work_auth.attestation.authorizedScope.allowedPaths
    glob.match(pattern, ["/"], path)
}

path_denied(path) if {
    some pattern in work_auth.attestation.authorizedScope.deniedPaths
    glob.match(pattern, ["/"], path)
}

deny[msg] if {
    input.tool == "Write"
    path_denied(input.file_path)
    msg := sprintf("Path '%s' explicitly denied", [input.file_path])
}

---

Complete Session Flow

JIRA-1234 Created → work-authorization attestation
                           │
                           ▼
                    AI Session Starts
                    (sessionId: sess_abc123)
                           │
    ┌──────────────────────┼──────────────────────┐
    │                      │                      │
    ▼                      ▼                      ▼
Read package.json    Write mfa.go         Write .env.local
    │                      │                      │
Pre-hook: ✓          Pre-hook: ✓          Pre-hook: ✗ DENIED
    │                      │                      │
Execute              Execute              BLOCKED
    │                      │                      │
Attestation          Attestation          No attestation
inv_001              inv_002              Error returned
    │                      │
    └──────────────────────┼──────────────────────┐
                           │                      │
                           ▼                      ▼
                    Bash "npm test"         Git Push
                           │                      │
                    Pre-hook: ✓            compliance-gate
                           │                      │
                    Attestation            Verify all:
                    inv_003                 - work-auth ✓
                    tags: ["test"]          - scope ✓
                    exitCode: 0             - tests ✓
                                                  │
                                           PUSH ALLOWED

Every tool call is either:

1. Allowed → Executed → Attested → Verifiable
2. Denied → Blocked → No execution → Error returned

The attestation chain proves ONLY authorized operations occurred.