For Auditors and Compliance Teams

Why Auditors Should Care

Agentic AI introduces a fundamentally new risk profile that traditional security controls were never designed to address. Unlike conventional service accounts or API integrations, AI agents are autonomous, adaptive, and goal-oriented. They decide at runtime which tools to invoke, what data to access, and how to sequence multi-step operations, all without human oversight of each individual action.

The New Threat Surface

• Prompt injection: Adversarial inputs that hijack agent reasoning to bypass intended controls and execute unauthorized actions.
• Credential exfiltration: Agents persuaded (via crafted prompts or malicious tool outputs) to leak secrets, API keys, or database credentials in their responses.
• Tool misuse: Agents invoking tools they should not have access to, or invoking permitted tools with parameters outside their authorized scope.
• Runaway loops: Unbounded recursive execution patterns that consume resources, amplify errors, or produce cascading failures across dependent systems.
• Data exfiltration: Agents accumulating sensitive data across multiple requests within a session and exfiltrating it through legitimate-looking tool calls.
• Tool poisoning: Compromised tool definitions (rug-pull attacks) where a previously safe tool is replaced with a malicious implementation.

What PRECINCT Provides

PRECINCT is the control framework specifically designed for this risk surface. Rather than retrofitting traditional IAM or network controls onto agentic workloads, PRECINCT provides purpose-built enforcement mechanisms:

• Pre-built control mappings to SOC 2, ISO 27001, GDPR, HIPAA, CCPA/CPRA, and PCI-DSS.
• Automated evidence generation in auditor-ready formats (XLSX, CSV, PDF), not locked into any vendor-specific tool.
• Immutable audit trails with hash-chained events, trace correlation, and tamper-proof storage.
• Verifiable controls that auditors can independently test and confirm using the procedures documented on this page.

Compliance Framework Coverage

PRECINCT provides explicit control mappings to the following compliance frameworks. Each mapping identifies the specific architectural mechanism that satisfies the control requirement, the evidence artifacts generated, and the current implementation status.

Control-Family Crosswalk

The following table maps each PRECINCT control family to its implementing architecture mechanism and the specific controls it satisfies across frameworks. Use this crosswalk to trace from any framework requirement to the concrete enforcement point in the architecture.

Evidence Generation

PRECINCT includes built-in tooling for generating compliance evidence in auditor-ready formats. All output is produced in standard, vendor-neutral formats (XLSX, CSV, and PDF) that work with any compliance management tool or can be reviewed directly by a human auditor.

Generating a Compliance Report

The primary entry point for compliance evidence is the make compliance-report target, which produces a comprehensive report covering all implemented framework mappings, control statuses, and evidence artifacts.

# Generate auditor-ready compliance report
make compliance-report

Framework-Specific Evidence Collection

For targeted evidence collection against a specific framework, use the compliance-evidence target with the FRAMEWORK parameter. Optionally sign the output with the SIGN=1 flag for cryptographic provenance.

# Collect framework-specific evidence
make compliance-evidence FRAMEWORK=soc2
make compliance-evidence FRAMEWORK=hipaa SIGN=1

Security Scan Evidence

Security scanning and production readiness validation can also produce evidence artifacts suitable for audit review.

# Security scan evidence
make security-scan

# Production readiness validation
make production-readiness-validate

Immutable Audit Trail

Every gateway decision produces a structured audit event. These events form a tamper-evident chain that provides complete traceability from any agent action back to the identity, policy, and context that authorized (or denied) it.

Audit Event Structure

Each audit event is written as structured JSONL (JSON Lines) and contains the following fields:

• decision_id: Unique identifier for this specific policy decision.
• trace_id: Distributed trace identifier for correlating across services.
• session_id: Agent session identifier for grouping related decisions.
• spiffe_id: The cryptographically verified SPIFFE identity of the calling workload.

Hash Chain Integrity

Each event includes a prev_hash field containing the SHA-256 digest of the immediately preceding event. This creates a linked chain where any tampering with a historical event breaks the hash chain from that point forward. Additionally, each event records:

• Policy bundle digest: The hash of the OPA policy bundle that was active at decision time, establishing which rules governed the decision.
• Registry digest: The hash of the tool registry state, establishing which tool definitions were in effect.

Storage and Retention

Kubernetes Deployments

In Kubernetes, audit events are shipped to S3-compatible storage with Object Lock in COMPLIANCE mode. This provides hardware-enforced immutability: once written, no principal (including root administrators) can modify or delete the data until the retention period expires. This is the strongest available guarantee for tamper-proof audit retention.

Docker Compose Deployments

In Docker Compose, full immutability guarantees are not available. Compensating controls are applied instead:

• Hash-chain verification: Integrity of the event chain can be verified at any time by recomputing the hash sequence.
• Off-host shipping: Events are shipped to an external log aggregator as soon as they are produced, reducing the window of local tampering opportunity.

RACI Operating Model

The following RACI matrix defines accountability and responsibility for key security processes in a PRECINCT deployment. Auditors should verify that each row has named owners assigned in the organization's operational documentation.

Legend: R = Responsible (does the work), A = Accountable (owns the outcome), C = Consulted (provides input), I = Informed (kept in the loop).

What Auditors Can Verify

The following is a step-by-step guide for auditors to independently verify that PRECINCT controls are operating as designed. Each step includes the control objective, the verification procedure, and the expected outcome.

1. Identity Verification

Objective: Confirm that all workloads possess valid, attested SPIFFE identities and that SVIDs rotate on schedule.

• Run the SPIRE entry list command to enumerate all registered workloads.
• Verify that each agent and service has a corresponding SPIFFE entry.
• Confirm that SVIDs have finite TTLs and rotate automatically before expiry.

2. Authorization Enforcement

Objective: Confirm that unauthorized requests are denied with structured, auditable responses.

• Send a request to the gateway from an identity that lacks the required permissions.
• Verify that the gateway returns a structured denial response (not a generic error).
• Confirm that the denial is recorded in the audit trail with the requesting identity and the policy rule that triggered the denial.

3. Tool Integrity

Objective: Confirm that tool registry hash verification prevents rug-pull attacks and tool poisoning.

• Verify that the tool registry contains cryptographic hashes for all registered tools.
• Attempt to invoke a tool after modifying its definition (simulate a rug-pull).
• Confirm that the gateway detects the hash mismatch and blocks the invocation.

4. Data Loss Prevention

Objective: Confirm that the DLP layer detects and blocks sensitive data in agent requests and responses.

• Send a request that includes a credential (API key, connection string, or similar) in the payload.
• Verify that the DLP layer blocks the request before it reaches the upstream tool.
• Confirm that the blocking event is recorded in the audit trail.

5. Secret Protection

Objective: Confirm that agents never observe real credentials.

• Review the agent audit trail for any request or response that contains raw secret material.
• Verify that agents operate exclusively with opaque reference tokens.
• Confirm that token-to-secret substitution occurs only at the gateway egress layer (step 13 of the middleware chain).

6. Audit Chain Integrity

Objective: Confirm that the hash chain is intact and no events have been tampered with.

• Retrieve the audit event log for a given time range.
• Recompute the SHA-256 hash chain by hashing each event and comparing it to the prev_hash field of the next event.
• Confirm that the chain is unbroken from the first event to the last.

7. Rate Limiting

Objective: Confirm that per-identity rate limits are enforced and that one agent cannot monopolize system resources.

• Issue requests from a single identity at a rate exceeding the configured limit.
• Verify that the gateway returns rate-limit responses after the threshold is exceeded.
• Confirm that rate limiting is applied per-identity, not globally (other identities remain unaffected).

8. Supply Chain Verification

Objective: Confirm that only image-digest-pinned containers are admitted to the cluster.

• Verify that all container image references use digest pinning (SHA-256), not mutable tags.
• Attempt to deploy a container with a tag-only reference and confirm it is rejected by admission control.
• Review the image signing and verification pipeline for completeness.

Production Go/No-Go Conditions

The following conditions must all be satisfied before an organization may claim production defensibility for a PRECINCT deployment. These are not aspirational; they are hard gates. If any condition is not met, the deployment is not production-ready from a compliance standpoint.

1. RACI ownership formally assigned. Every row in the RACI matrix above has named, individual owners (not team names) documented and acknowledged by the assigned individuals.
2. Evidence pipelines automated and immutable where required. Compliance evidence generation runs on a defined cadence without manual intervention, and storage is immutable in Kubernetes deployments.
3. Gateway mediation mandatory. All model egress and ingress traffic flows through the PRECINCT gateway. No agent can reach an LLM or tool without passing through the 13-layer middleware chain.
4. Context admission invariants enforced. The context admission rules (session scoping, provenance tagging, retention limits) are active and tested.
5. Legal/privacy prerequisites embedded in release gates. Privacy impact assessments and legal review are required checkpoints in the release pipeline, not afterthoughts.
6. Break-glass approvals time-boxed, reason-coded, and reviewed. Any emergency override of policy controls is time-limited, requires a structured reason code, and is reviewed in the next business day's audit.
7. Internal audit confirms control operation. An internal audit team (or equivalent function) has independently verified that the controls described in the What Auditors Can Verify section operate as designed.
8. prod_standard and prod_regulated_hipaa profiles validated. The deployment configuration profiles have been validated against their respective test suites and all tests pass.

STRIDE/PASTA Threat Model Coverage

PRECINCT's architecture was designed against both the STRIDE and PASTA threat modeling methodologies. The following summarizes how each STRIDE threat category is addressed.

STRIDE Coverage

PASTA Coverage

The PASTA (Process for Attack Simulation and Threat Analysis) methodology provides a risk-centric lifecycle approach. PRECINCT provides coverage across three PASTA dimensions:

• Decomposition quality: The five governed planes provide clear decomposition boundaries for threat analysis, ensuring no system surface is overlooked.
• Threat completeness: The 13-layer middleware chain ensures that each identified threat category has a concrete enforcement point, reducing gaps between threat identification and mitigation.
• Risk-treatment clarity: Each control maps explicitly to framework requirements (see the crosswalk table), providing clear traceability from risk to treatment to evidence.

Sample Audit Output

Every request through the PRECINCT gateway produces an immutable audit record in JSONL format. Records are hash-chained: each record's prev_hash field references the preceding record, making tampering detectable. Below are representative examples.

Successful request (all 13 layers pass)

{
  "timestamp": "2025-11-15T09:23:41.003Z",
  "request_id": "req-a7f3b291",
  "spiffe_id": "spiffe://precinct.dev/agent/research-bot",
  "tool": "web_search",
  "layers_passed": 13,
  "decision": "ALLOW",
  "latency_ms": 47,
  "hash": "sha256:e3b0c44298fc1c149afbf4c8996fb924",
  "prev_hash": "sha256:d7a8fbb307d7809469ca9abcb0082e4f"
}

DLP violation (credentials detected, blocked at layer 7)

{
  "timestamp": "2025-11-15T09:24:02.117Z",
  "request_id": "req-c8d4e512",
  "spiffe_id": "spiffe://precinct.dev/agent/code-assistant",
  "tool": "file_write",
  "layers_passed": 6,
  "blocked_at_layer": 7,
  "layer_name": "DLP Scanner",
  "decision": "DENY",
  "reason": "Credential pattern detected in response payload",
  "dlp_match": "AWS_ACCESS_KEY",
  "hash": "sha256:9f86d081884c7d659a2feaa0c55ad015",
  "prev_hash": "sha256:e3b0c44298fc1c149afbf4c8996fb924"
}

Policy denial (unauthorized tool, blocked at layer 6)

{
  "timestamp": "2025-11-15T09:24:15.891Z",
  "request_id": "req-f1a2b3c4",
  "spiffe_id": "spiffe://precinct.dev/agent/intern-bot",
  "tool": "shell_exec",
  "layers_passed": 5,
  "blocked_at_layer": 6,
  "layer_name": "OPA Policy Engine",
  "decision": "DENY",
  "reason": "Agent 'intern-bot' is not authorized to use tool 'shell_exec'",
  "policy": "precinct/tool_access/v1",
  "hash": "sha256:4e07408562bedb8b60ce05c1decfe3ad",
  "prev_hash": "sha256:9f86d081884c7d659a2feaa0c55ad015"
}

Rate limit exceeded (blocked at layer 11)

{
  "timestamp": "2025-11-15T09:24:31.445Z",
  "request_id": "req-d5e6f7a8",
  "spiffe_id": "spiffe://precinct.dev/agent/data-collector",
  "tool": "api_call",
  "layers_passed": 10,
  "blocked_at_layer": 11,
  "layer_name": "Rate Limiter",
  "decision": "DENY",
  "reason": "Token budget exceeded: 45,000/50,000 tokens consumed in current window",
  "rate_limit": {"window": "1h", "limit": 50000, "consumed": 45000},
  "hash": "sha256:ef2d127de37b942baad06145e54b0c61",
  "prev_hash": "sha256:4e07408562bedb8b60ce05c1decfe3ad"
}

CLI audit commands

Use the agw CLI to query and verify audit trails:

# Search audit records by agent identity
agw audit search --spiffe-id "spiffe://precinct.dev/agent/research-bot" --last 24h

# Explain a specific audit decision
agw audit explain --request-id req-c8d4e512

# Verify hash chain integrity
agw audit verify --from "2025-11-15T00:00:00Z" --to "2025-11-15T23:59:59Z"

CLI compliance evidence commands (OpenSearch-backed, secure path)

export AGW_OPENSEARCH_PASSWORD='<secret>'

# Collect SOC2 evidence from indexed audit records over HTTPS + mTLS
agw compliance collect \
  --framework soc2 \
  --audit-source opensearch \
  --opensearch-url https://opensearch.observability.svc.cluster.local:9200 \
  --opensearch-ca-cert /certs/ca.crt \
  --opensearch-client-cert /certs/client.crt \
  --opensearch-client-key /certs/client.key

Docker Compose vs Kubernetes for Audit

The deployment environment has significant implications for audit defensibility. Auditors must understand and document which environment produced any given piece of evidence.

When reviewing evidence, auditors should always verify the deployment_environment field in evidence metadata. Kubernetes deployments provide full audit defensibility; Docker Compose deployments provide compensating controls that may satisfy some but not all regulatory requirements.