The existing receipt-generation demo exercises several transports from source. This recipe uses the pinned release and HTTP fetch path. Action receipts explains the evidence format; Verify a receipt uses published conformance fixtures instead of generating new evidence.

The HIPAA mapping explains the organizational and deployment controls this test doesn’t cover. The community rules guide covers signature trust, freshness and additive loading.

Starting point

Use Ubuntu 24.04 on Linux x86-64 with Bash, curl, CA certificates and tar. The commands also use standard Ubuntu tools, including grep, sha256sum and seq. Start in an empty working directory with no Pipelock installation, config, installed rules or license. Run the blocks in order in the same Bash shell. This recipe uses free features.

The community rules guide explains signature trust, freshness, experimental-rule filtering and updates. Pipelock Rules describes the published bundles.

Starting point

Use Ubuntu 24.04 on Linux x86-64 with Bash, curl, CA certificates and tar. The commands also use standard Ubuntu tools, including grep, sha256sum and seq. Start in an empty working directory with no Pipelock installation, config, installed rules or license. Run the blocks in order in the same Bash shell. This recipe uses free features.

The MCP proxy guide explains the transports and scan directions. Claude Code hooks describes how proxy wrapping complements client-side hooks.

Starting point

Use Ubuntu 24.04 on Linux x86-64 with Bash, curl, CA certificates and tar. The commands also use standard Ubuntu tools, including grep and sha256sum. Start in an empty working directory with no Pipelock installation, config, installed rules or license. Run the blocks in order in the same Bash shell. This recipe uses free features.

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.

This page is about the Codex CLI at runtime. OpenAI’s separate Codex Security product scans connected GitHub repositories, and OpenAI’s own security page points readers looking for it elsewhere. The full command reference for this integration lives in the Codex integration guide on GitHub.

The ecosystem has responded with MCP security tools. They vary widely in what they actually check. This guide breaks down the categories, names the major tools, and helps you evaluate what you need.

An AI egress proxy is a forward proxy purpose-built for AI agent traffic. It sits between your agent and every external service the agent contacts. Every outbound HTTP request, MCP tool call, and WebSocket frame passes through it.

The proxy inspects traffic in both directions. Outbound, it scans for leaked credentials, SSRF attempts, and policy violations. Inbound, it scans responses for prompt injection payloads that could compromise the agent on the next turn.

Release posts

Reading older releases

Older posts describe behavior as it shipped in that version. Later releases changed some defaults: v3.0 moved enforcement to fail closed, for example. Check the newest upgrade guide before you copy a configuration from an older post.

MCP security is the practice of protecting AI agents that use the Model Context Protocol from threats originating in tool descriptions, tool arguments, tool responses, and the underlying transport. The four channels each carry different risk: tool descriptions and responses can carry hidden instructions, tool arguments can leak credentials, and transport metadata can hide exfiltration. Static install-time scanners catch some risks but miss rug-pull attacks where a server changes its tools mid-session, so runtime inspection at the proxy layer is necessary.

AI agent security is not one tool or one layer. Your agent has API keys, file system access, and an internet connection. When something goes wrong, secrets leave through HTTP requests, MCP tool calls, or DNS queries before anyone notices. The model’s built-in safety training helps, but it’s not a security boundary. It can be bypassed with the right prompt.

Real defense requires multiple layers, each catching different attacks at different points. Most teams either have zero layers or think one tool covers everything. Neither is true.

The question is whether that firewall should be a SaaS product you can’t inspect, or open source software you control.

Without a gateway, your agent talks directly to MCP servers with no inspection. Tool descriptions can contain hidden instructions. Tool arguments can carry your API keys. Responses can inject new prompts into your agent’s context. There is no log, no scan, no enforcement point, and no way to roll out a policy change without touching every agent.

This page maps the tool landscape by category. Each section explains what the tools in that category inspect, what they miss, and where they fit in a defense stack. Named tools are included as examples, not endorsements. Evaluate them against your own threat model.

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.

Inspect a service you trust

Start the intended MCP service. pipelock mcp identity register observes it and prints a configuration entry for review; it doesn’t edit your config. The command accepts --upstream, --name, optional --mapped-file inputs and an optional session header carrier.

Prove the end of a receipt chain

A valid prefix doesn’t prove the writer finished. Chain verification reports VALID PREFIX, END UNPROVEN and exits 3 when its end isn’t proven. --allow-prefix accepts an intentional open-prefix check with exit 0, but keeps the label. Don’t use it as a completeness check.