pipelock check --config /path/to/pipelock.yaml

Use the real production config path. Every refusal names the field, and most name the value and the fix.

Config that now fails to load

Each of these was accepted by 3.5 and is refused by 3.6, at startup and on hot reload.

Why Continue.dev needs an agent firewall

Continue sessions frequently involve:

Pipelock sits inline on each MCP server. It scans tools/call arguments outbound for DLP, scans tool responses inbound for prompt injection, scans tool definitions for poisoned descriptions, and emits signed action receipts so an operator can prove what happened.

The fixtures here come from the public conformance corpus that verifier authors and Audit Packet producers can test against. There is no vendor-only verification path: every command below runs on public fixtures with a public test key.

That is the difference between a log and evidence.

Verifiable AI agent actions

Verifiable AI agent actions need more than a timestamped log line. They need a record from outside the agent process and a verifier that rejects tampered evidence without calling the original vendor. The what did my agent do page walks a full audit trail end to end.

What this covers

This setup routes requests that honor the proxy setting through Pipelock. For HTTPS, Pipelock sees only the destination of a plain CONNECT tunnel; scanning headers and bodies needs TLS interception and a Pipelock CA that Pi trusts. Tools and subprocesses that ignore proxy environment variables need separate network containment. See the containment guide for that.

What containment is

Containment splits one workstation into three accounts:

There is no pipelock grok install. Do not treat this page as env-only, and do not treat MCP as unsupported. The full command reference lives in the Grok CLI integration guide on GitHub.

The specification is CC BY 4.0. The checker, schemas, fixtures, scripts, and other code are Apache 2.0.

Deployers of high-risk AI systems must retain the logs the system automatically generates for at least six months, to the extent the deployer controls those logs, and longer where Union or national law requires it. Article 12 is the design-time obligation on the provider to make the system technically capable of automatic logging. Article 26(6) is the runtime obligation on the deployer to keep the logs that result.

AI agent compliance is the practice of proving that agents operated within defined boundaries. Not describing what they should do. Proving what they did.

What Auditors Actually Ask

Auditors do not ask “what model do you use?” They ask:

This page is built for the buyer doing the work. It maps Pipelock evidence to the obligations of each major framework with honest scope: what the framework asks, what Pipelock supplies, and what it does not cover. Use it as a starting point for procurement and audit conversations. Every assertion below has a public source link.

Pipelock supplies product evidence for controls that operate at its boundary. An organization and its auditor decide whether that evidence supports a control test.

Criteria mapping

What the mapping means

A covered row identifies the Pipelock controls and evidence that map to that criterion. A partial row identifies the same contribution and its stated limit. The mapping is not an audit result, an attestation, or a certification claim.

The mapping includes the four core functions and four Generative AI rows. Covered rows name the product controls. Partial rows state the operator-owned work that remains.

Core function mapping

Generative AI mapping

What the mapping does not claim

Pipelock supports deployment evidence and runtime mediation. The operator owns governance roles, policy approval, stakeholder work, impact classification, and bias evaluation. The provenance mapping covers Pipelock’s mediation and known tool binary. It does not establish model provenance.

Each row below comes from Pipelock’s built-in compliance mapping. “Covered” names a direct product mapping. “Partial” names a product contribution and the remaining gap.

Technique mapping

What the partial mappings leave outside Pipelock

Pipelock can inspect, simulate, record, and attest to activity at its control points. It does not curate an external corpus, decide whether a reader should trust an output, validate the correctness of citations from an upstream retrieval source, or govern the write path for a corpus. It also does not fully govern long-lived agent state or scheduler control.

Physical safeguards are outside this mapping. Physical security for the host running Pipelock remains the operator’s responsibility. The same applies to business agreements, workforce procedures, and other organizational controls.

Six activation sources, OR-composed

The kill switch controller composes six independent activation sources. Any single active source denies traffic; all six must be clear for traffic to flow. OR-composed means the sources add up in one direction only: another source can always stop traffic, but no source can override a stop.

What’s new in recent releases

JetBrains integration is pure MCP proxy wrapping, which unlocks the current signed-evidence surface when receipt signing is configured:

• Mediator-signed action receipts for MCP decisions (v2.2.0). With flight_recorder.signing_key_path set in the pipelock config, each proxied Junie MCP decision emits a chained Ed25519 receipt on the mcp_stdio transport.
• Cross-implementation verifier (v2.2.0). Receipts verify byte-for-byte against a published Python verifier using a conformance suite. The receipt format is open, not a vendor artifact.
• RFC 9421 mediation envelope signing (v2.2.0). If a Junie config routes to a remote MCP server over HTTP/SSE, every request carries an Ed25519 Pipelock-Mediation signature with a canonical policy hash.
• Posture verify CI gate (v2.2.0). pipelock posture verify gates deploys with distinct exit codes: 0 pass, 1 could not complete, 2 verified but failed.
• Class-preserving redaction on tools/call arguments (v2.3.0). With the redaction section enabled in the pipelock config, matched secrets in params.arguments are rewritten in place with typed placeholders like <pl:aws-access-key:1> before forwarding to the MCP server. Runs on Pipelock’s MCP proxy transports. Irreversible. Fail-closed on parse errors. Tool responses are not redacted in v1.

See the action receipt spec for the receipt format and the AI agent data redaction guide for redaction rollout.

MCP tool poisoning is an attack where a malicious Model Context Protocol server hides instructions inside tool metadata that an AI agent reads during discovery. The hidden instructions enter the model’s context window as trusted documentation and the agent acts on them. Every text field in a tool schema is a potential injection surface, not just the top-level description. Rug-pulls are a sub-variant where the server returns clean descriptions to install-time scanners and poisoned descriptions after the agent is using the server. Effective defense combines pre-deploy scanning, runtime proxy inspection, session fingerprinting, and tool inventory binding.