Pipelock can emit mediator-signed action receipts from outside the agent trust boundary when receipt signing is configured. That signing position is the load-bearing property compliance evidence depends on: an external attestor recording the agent’s actions instead of the agent attesting to itself.
Pipelock generates AI compliance evidence through structured mappings between its runtime security controls and five external frameworks. These are control mappings with evidence generation, not compliance certifications. They document which controls Pipelock addresses and what evidence the product can emit.
AI agent compliance evidence answer
AI agent compliance evidence should connect each runtime action to a control, a policy version, and a record an auditor can check later. Pipelock generates that evidence by mediating the agent’s network and MCP traffic, writing structured events, and producing signed receipts when receipt signing is configured.
| Compliance evidence need | Signed receipt | Plain log |
|---|---|---|
| AI agent audit logs | One decision per mediated action with verdict and policy hash | Usually operational text or vendor event data |
| Tamper evidence | Ed25519 signature and hash-chain linkage | Depends on storage controls |
| Offline review | Verifier checks bytes against a pinned public key | Often tied to the original logging system |
| Deployer duty | Keep, review, and sign off through your compliance program | Same deployer duty, with weaker evidence |
Mapped Frameworks
| Framework | Scope | Controls Mapped |
|---|---|---|
| OWASP MCP Top 10 | MCP protocol security risks | 10 controls (MCP01-MCP10) |
| OWASP Agentic Top 10 | AI agent application risks | 10 controls (ASI01-ASI10) |
| MITRE ATLAS | Adversarial ML threat techniques | Reconnaissance, discovery, exfiltration techniques |
| EU AI Act | Articles 12, 13, 14, 26 | Record-keeping, transparency, human oversight, deployer monitoring |
| SOC 2 Trust Services Criteria | Security, availability, processing integrity, confidentiality, privacy | 5 criteria (SEC, AVA, PI, CONF, PRIV) |
In addition, Pipelock maps to NIST SP 800-53 Rev. 5 across 7 control families:
- AC – Access Control (tool policy, per-agent profiles, sandbox)
- AU – Audit and Accountability (structured events, SARIF, OTLP)
- CA – Assessment, Authorization, and Monitoring (continuous monitoring)
- CM – Configuration Management (audit score, hot reload validation)
- IR – Incident Response (kill switch, emit pipeline, flight recorder)
- SC – System and Communications Protection (DLP, capability separation, TLS)
- SI – System and Information Integrity (scanner pipeline, binary integrity)
Generating Evidence with pipelock assess
The pipelock assess command orchestrates four security primitives into a reproducible, optionally signed evidence bundle:
pipelock assess init --config pipelock.yaml
pipelock assess run assessment-a1b2c3d4/
pipelock assess finalize assessment-a1b2c3d4/
Init creates a run directory with a manifest and a SHA-256 hash of your config file. Run executes the assessment primitives: attack simulation, audit scoring, installation verification, and MCP server discovery. Finalize synthesizes the results into a scored report (JSON and HTML) and optionally signs the manifest with Ed25519.
Additional finalize options:
pipelock assess finalize assessment-a1b2c3d4/ --archive # .tar.gz bundle
pipelock assess finalize assessment-a1b2c3d4/ --attestation # attestation.json + signature
pipelock assess finalize assessment-a1b2c3d4/ --badge # SVG badge (requires --attestation)
Verify a previous assessment with pipelock assess verify or pipelock assess verify-attestation.
Pipelock v2.2.0 also adds pipelock posture verify, which checks a signed posture capsule against a named policy and gives CI-friendly exit codes for integrity failures versus policy failures. That turns the evidence bundle from a report artifact into a deployment gate.
SARIF Output for GitHub Code Scanning
Pipelock’s audit and git scan-diff commands support SARIF v2.1.0 output:
pipelock audit --format sarif -o results.sarif
pipelock git scan-diff --format sarif -o results.sarif
Upload the SARIF file using the github/codeql-action/upload-sarif action. Findings appear as inline annotations on pull request diffs, integrating security scanning into your existing code review workflow.
What Each Primitive Tests
| Primitive | What It Does |
|---|---|
simulate | Runs 30 built-in attack scenarios (DLP exfiltration, prompt injection, tool poisoning, SSRF, URL evasion) plus 6 per canary token. Verifies the correct scanner layer detected each attack |
audit-score | Scores your config across 23 security categories (0-100, A-F grade) with tool policy overpermission audit |
verify-install | 15 deterministic checks verifying the scanning pipeline and network containment are operational |
discover | Scans MCP server configs across IDEs and reports which servers lack Pipelock wrapping |
Licensing
Unlicensed users get a summary projection without cryptographic signature. Licensed users get the full assessment with Ed25519 signed manifests, attestation documents, and SVG badges. All detection and scanning features are free and open source; the paid tier adds signed evidence packaging.
For procurement, audit, and legal-team framing of Pipelock as evidence substrate inside an existing compliance program (rather than as a compliance product), see Compliance Evidence Substrate. For a framework-by-framework view across EU AI Act, DORA, NIS2, NIST AI RMF, ISO 42001, the Colorado AI Act, SOC 2, and OWASP, see the AI Agent Regulatory Controls hub. To walk through a single decision end-to-end with a real signed receipt and verifier output, see What did my agent do?.
Back to Pipelock | Proof | Generate signed reports with Assess