Compliance Evidence Substrate for AI Agents

Pipelock is not a compliance product. It is the evidence substrate procurement, audit, and legal teams use inside their existing programs.

Ready to protect your own setup?

Pipelock is not a compliance product. It is an evidence substrate for AI-agent operations: it records what an agent tried to do, which control point observed it, which policy applied, what verdict was reached, and whether the evidence can be verified later.

Procurement, audit, and legal teams use this evidence inside EU AI Act Article 12 logging programs, NIST AI RMF risk management documentation, ISO/IEC 42001 AI management systems, SOC 2 audits, and incident reviews. Pipelock does not replace any of those frameworks. It supplies the machine-verifiable records those programs ask for.

This page is for procurement teams writing AI-vendor questionnaires, auditors pulling evidence for an attestation engagement, and legal counsel building defensible records for AI agent operations. Engineers should read the AI compliance evidence overview and the action receipt spec instead.

What an evidence substrate is, and why the distinction matters

A compliance product makes a certification claim: “we are SOC 2 Type II audited” or “we are ISO 27001 certified.” A compliance product carries auditor attestation as part of the deliverable.

An evidence substrate produces the underlying signed records that compliance programs need. The substrate does not certify your organization. Your ISMS, your auditor, your legal team, and your management own the certification claim.

Pipelock is the substrate. The records it emits are:

  • Signed action receipts with a chain hash, policy hash, and Ed25519 signature from outside the agent trust boundary
  • Scanner verdicts with a reason code, severity, and the specific scanner layer that produced the verdict
  • Audit packets that bundle a run’s receipt chain, verifier output, scanner config snapshot, and posture metadata into one inspectable artifact
  • Control point metadata that names where the decision happened (HTTP proxy, MCP proxy, WebSocket, CI action, sidecar) and the trust boundary

These records carry weight because they were emitted by a mediator outside the agent process. The agent did not attest to itself. An external attestor recorded what the agent attempted, and that record can be independently verified later.

EU AI Act Article 12 mapping

Regulation (EU) 2024/1689 Article 12 requires high-risk AI systems to technically allow automatic recording of events over the system lifetime, support traceability appropriate to intended purpose, support monitoring of operation, help identify situations that may result in risk, and be appropriate to system design.

Pipelock generates evidence for each of those obligations. Pipelock does not satisfy the obligation by itself; the deployer still owns retention policy (Article 26 specifies a six-month minimum), review cadence, risk acceptance, and formal documentation.

Article 12 requirementCompliance needPipelock primitiveEvidence produced
Automatic event recording over system lifetimeMachine-action event loggingAction receipt + flight recorderTimestamped action record with verdict, target, policy hash, scanner layer
Traceability appropriate to intended purposeTraceability of agent operationsHash-chained audit log + receipt hashOrdered event chain, receipt hash, signature metadata
Support monitoring of operationOperational monitoringScanner verdict + metrics + session manifestAllow/block/warn counts, finding class, session posture
Help identify situations that may result in riskRisk event detectionDLP, prompt-injection, SSRF, MCP tool-poison findingsReason code, severity, scanner, normalized finding class
Appropriate to system designControl-point specificitycontrol_point metadataWhether decision came from HTTP proxy, MCP proxy, WebSocket, CI action, sidecar

NIST AI RMF mapping

NIST AI 100-1 (the AI Risk Management Framework) defines four core functions: GOVERN, MAP, MEASURE, MANAGE. Pipelock evidence supports each function. The framework itself is a process and governance structure that Pipelock evidence feeds into; Pipelock does not implement the framework.

NIST AI RMF functionCompliance needPipelock primitiveEvidence produced
GOVERNPolicy, accountability, risk process evidencePolicy hash + posture capsuleWhich policy was active; whether runtime posture matched expected policy
MAPContext and use-case characterizationAudit Packet + session metadataAgent identity, target service, transport, action class, deployment context
MEASURERisk analysis and trackingScanner verdict + benchmark/conformance resultsDetection class, severity, false-positive notes, conformance case references
MANAGERisk response and control operationKill switch + fail-closed verdicts + HITL approvalsBlock/allow/ask decision, override record, recovery/termination event

Other framework alignments

Pipelock evidence also feeds into:

  • ISO/IEC 42001 AI management system documentation (operational records and management review evidence)
  • SOC 2 Common Criteria around system operations, change management, and incident response (CC7-CC9)
  • OWASP Agentic Top 10 mappings, see the agent egress security and MCP security learn pages for control coverage
  • MITRE ATLAS adversarial ML threat techniques, particularly reconnaissance, discovery, and exfiltration coverage

For the framework-mapped product surface (assess command, signed bundles, SARIF integration), see AI compliance evidence. For Article 26 deployer obligations and the six-month retention rule specifically, see EU AI Act compliance.

What this is not

Pipelock is not:

  • A SOC 2 substitute. SOC 2 requires an independent auditor’s attestation; Pipelock supplies records the auditor evaluates.
  • A certified audit. Pipelock evidence supports an audit but does not replace one.
  • An ISMS. Pipelock does not establish information security policy, risk acceptance criteria, or governance structure.
  • A model evaluation framework. Pipelock observes agent egress at the network and tool boundary; it does not evaluate model behavior, fairness, or bias.
  • A content moderation product. Pipelock scans for secret leaks, prompt injection, SSRF, and tool poisoning, not for content acceptability.
  • A legal opinion. Pipelock evidence supports legal review but does not constitute legal advice.

The records Pipelock produces are what your compliance program runs on. Retention, review, risk acceptance, formal documentation, and auditor sign-off remain your organization’s work.

How to use this evidence in your program

Procurement teams writing AI-vendor questionnaires can ask vendors to produce Pipelock-compatible audit packets for any AI agent the vendor uses on procurement-team data. Verifying a packet only requires an Ed25519 public key and a small reference verifier. The verifier path is open source.

Auditors pulling evidence for an attestation engagement can request audit packets per agent-run, validate the signature chain with the open-source verifier, and treat the packet as the underlying record for an Article 12 logging assertion or an SOC 2 control test.

Legal counsel building defensible records for AI agent operations can rely on the chain-linked structure of action receipts to detect post-hoc tampering: any modification to an event in the chain breaks the hash linkage and the verifier reports it as invalid.

In each case, the procurement, audit, or legal team owns the program that wraps the evidence. Pipelock supplies the records.

Sources


Further reading

Back to Pipelock | Action receipt spec | Regulatory controls hub | What did my agent do? | Compliance evidence overview

Frequently asked questions

Is Pipelock a compliance product?
No. Pipelock is an evidence substrate. It produces machine-verifiable records that procurement, audit, and legal teams can use inside their existing compliance programs. Pipelock does not replace an ISMS, certified audit, model risk management framework, or formal conformity assessment.
What does 'evidence substrate' mean for procurement teams?
It means Pipelock generates the underlying signed records (action receipts, scanner verdicts, audit packets, control point metadata) that compliance frameworks ask for, but the procurement team still owns retention policy, review cadence, risk acceptance, and formal sign-off. Pipelock supplies the records. The organization runs the program.
Which EU AI Act articles does Pipelock evidence map to?
Article 12 specifically: automatic event recording, traceability, operational monitoring, risk event detection, and control-point specificity. Pipelock does not address Article 9 risk management process, Article 10 training data governance, Article 14 human oversight at the workflow level, or Article 43 conformity assessment. Those need additional controls and process around the evidence.
How does Pipelock map to NIST AI RMF?
Pipelock generates evidence aligned with all four core functions: GOVERN (policy hash plus posture capsule), MAP (audit packet plus session metadata), MEASURE (scanner verdict plus benchmark and conformance results), and MANAGE (kill switch, fail-closed verdicts, and HITL approvals). Auditors and risk teams can pull this evidence directly into their NIST RMF documentation.

Ready to protect your own setup?