Pipelock Guides: IDE Setup and MCP Security on PipeLab

Agent Firewall, Guardrails, Sandbox: Defining the Category

Sat, 13 Jun 2026 00:00:00 +0000

“Agent firewall,” “runtime security,” “guardrails,” and “sandbox” get used as if they mean the same thing. They do not, and the blur is why the skeptical takes land. “Should you even bother with AI firewalls, they all get bypassed” reads as insight precisely because nobody drew the lines. Once you define the category by what each control actually does, the question answers itself.

Agent security is four functions, not four products: prevention, detection, containment, and evidence. A real deployment needs all four. Most stacks ship the first three and skip the fourth.

Claude Code Security: Harden the Agent Runtime

Sat, 13 Jun 2026 00:00:00 +0000

Claude Code has shell access, your API keys, and a set of MCP servers feeding content straight into its context window. That is what makes it useful. It is also the attack surface. If the agent gets tricked by a prompt injection or a poisoned MCP server, it can leak credentials, overwrite files, or run a command, and it will do all of it at machine speed before you notice.

Pipelock Known Limitations: What It Does Not Catch

Sat, 13 Jun 2026 00:00:00 +0000

Pipelock publishes what it cannot catch. A security control that claims full coverage is the one to distrust, and a reviewer needs the boundaries drawn to decide what residual risk is acceptable. This page is the standing register. It tracks the documented gaps and, per release, the false-positive and true-positive picture.

The authoritative engineering source is the bypass resistance doc, which lists the evasion techniques Pipelock handles alongside the ones it does not. This page is the operator-facing summary.

Progressive Enforcement for AI Agents

Sat, 13 Jun 2026 00:00:00 +0000

You cannot deploy a blocking agent firewall blind. Drop a hard allowlist in front of a live agent fleet on Monday and by Tuesday the agent has tried something legitimate you did not predict, the firewall blocked it, and someone is paged. The control gets ripped out, and now you have no firewall at all. That is the single most common way a runtime enforcement tool dies.

Progressive enforcement is the fix. Observe first, derive a baseline from what the agent actually does, run in shadow to see what you would block, then enforce once the evidence says it is safe. Pipelock ships that whole workflow, and it can prove each step happened.

What Pipelock Claims, and What It Doesn't

Sat, 13 Jun 2026 00:00:00 +0000

Pipelock does not claim it cannot be bypassed. It never reports that no bypass occurred. That is a deliberate position, and it is a sales asset, not a disclaimer.

The skeptical line about runtime security is that every sandbox can be escaped, so why trust any of it. The line is correct about bypassability and wrong about the conclusion. Bypassability is the reason to add an evidence layer, the one control that tells you what actually crossed instead of asking you to trust that nothing did. The honest claim is the stronger one in front of a risk or audit buyer, because it is the one they can verify.

AARP Claims Dictionary

Mon, 08 Jun 2026 00:00:00 +0000

An AARP appraisal reports a claim set, not a trust score. Each claim name says what the verifier mechanically confirmed, and the paired limitations say what a reader must not infer from that evidence.

This page renders from the public JSON dictionary shipped with the Pipelock SDK. The human page is a view of that source, not a separate hand-maintained table.

Reserved entries are vocabulary locks. They name future transparency, deployment, and authority claims, but the current verifier does not emit those claims until the evidence and hostile fixtures exist.

AARP v0.1: The Agent Action Receipt Profile (Spec)

Wed, 03 Jun 2026 00:00:00 +0000

When a signing key is configured, Pipelock signs an action receipt for every agent action it mediates. A valid receipt signature proves the bytes were signed by a key and not altered. It proves nothing about whether the decision was correct, whether something bypassed the mediator, or whether the receipt is the whole story. AARP is the profile that makes that distinction machine-readable.

AARP is the Agent Action Receipt Profile. It is not a new receipt format. The shipped ActionReceipt v1 and EvidenceReceipt v2 stay byte-for-byte frozen. AARP appraises one of them as an immutable input, referenced by digest, and emits a structured result that lists exactly what it could cryptographically confirm and what it could not. It never rewrites a receipt, and it never emits a “trusted” or “safe” verdict.

What an AARP Receipt Proves, and What It Does Not

Wed, 03 Jun 2026 00:00:00 +0000

AARP is the assurance profile over a Pipelock action receipt. A verifier appraises the envelope and reports a claim-set grouped by axis. This page is the blunt version: what a verified appraisal proves, what it leaves as a claim, and the assumptions a relying party should pin before treating any claim as fact.

The honesty is the point. AARP refuses to collapse different kinds of proof into a single “trusted” score, because a relying party that reads more into a receipt than it proves is the failure this profile exists to prevent.

Hermes Agent Integration: Hook-Based Scanning for Non-MCP Agents

Sun, 31 May 2026 00:00:00 +0000

MCP gave Pipelock a clean place to stand between an agent and its tools. Frameworks that do not run on MCP never had that seam. Their tool calls and lifecycle events happened entirely inside the framework, where no proxy could see them.

The Hermes Agent integration adds the seam. A small plugin inside Hermes forwards each hook event to Pipelock, which scans it the same way it scans everything else.

AI Redaction Placeholders: What , , and [REDACTED] Mean

Sun, 31 May 2026 00:00:00 +0000

You opened an AI chat transcript, an agent log, or an API response and found a token like <private_address>, <private_person>, or <pl:aws-access-key:1> sitting where a real value should be. A redaction layer put it there. It found something sensitive and swapped in a label before the text reached the model or the log you are reading.

This page decodes the common placeholder vocabularies and tells you which tool emits each one.

Request Policy: Allow and Deny Individual API Operations

Sun, 31 May 2026 00:00:00 +0000

A host allowlist answers one question: can the agent reach this destination at all. It cannot answer the next one. Once api.example.com is allowed, every operation against it is allowed too, the harmless read and the account-deleting mutation alike. Request policy is the rail for that second question.

Request policy is an allow-by-default deny or warn rail over outbound HTTP API operations. Where DLP matches on content and the domain blocklist matches on host, request policy matches on what the request is trying to do: a GraphQL mutation root field, a JSON-RPC command, an admin DELETE. It blocks the dangerous operations and forwards everything else untouched.

Pipelock Pro Reference Deployment

Sat, 23 May 2026 00:00:00 +0000

Pipelock Pro adds multi-agent coordination on top of the same scanning, redaction, and receipt-emission that ships in the open-source build. The OSS binary already enforces a single-agent boundary. Pro is what happens when you have a fleet of agents that need to be told apart, billed apart, and audited apart.

This page documents the architecture pattern, not a particular deployment. The reference shape is real and exercised in production, but the names, namespaces, and addresses below are abstract.

Agent Security Tool Profiles: Procurement Evidence

Fri, 22 May 2026 00:00:00 +0000

A procurement reviewer asks one question of an agent security tool:

Can you prove what your tool did, with evidence I can verify offline?

A receipt-scoring profile is the structured answer. The rubric lives in the public agent-egress-bench corpus. Tool maintainers publish their own profile against a fixed public case set. A relying party reproduces it before trusting it.

What a signed receipt proves

A signed action receipt records what an agent tried to do, what verdict the tool returned, and which key signed the record. A receipt is durable evidence the tool both observed and adjudicated the action. A relying party can verify the receipt against a pinned public key without a vendor dashboard and without a network call to a hosted API. The verifier code is open source. The buyer runs it.

Agent Action Receipts: Signed Evidence for What an AI Agent Did

Thu, 21 May 2026 00:00:00 +0000

Most agent security tools tell you what the agent did from inside the agent. An action receipt tells you what the agent did from outside, signs the record with a key the agent cannot reach, and lets any third party verify the record without trusting the vendor that produced it.

That is the difference between a log and evidence.

What a receipt is

A receipt is a JSON record with three parts:

Agent Security Control Layers: Sandboxing, Identity, MCP Gateway, Egress Inspection

Thu, 21 May 2026 00:00:00 +0000

AI agent security splits into four layers. Each lane catches a different class of attack. Operators evaluating tools should map their threat model to the layers, not chase a single vendor that claims to cover everything.

Pipelock sits in layer 4. This page exists so a buyer comparing “agent firewall” products can see where the named examples actually fit.

Layer 1: process sandboxing and OS isolation

Constrains what the agent process can do at the kernel level. Network namespaces, Linux capabilities, Landlock, seccomp filters. The agent process is contained inside a jail; outbound network goes through a controlled proxy port.

Verifiable Egress Control: Binary-Enforced Mediation with Signed Evidence

Thu, 21 May 2026 00:00:00 +0000

Verifiable egress control is a security property: every network action an AI agent takes is mediated by a process outside the agent’s trust boundary, and each decision produces a signed receipt any third party can verify offline. The short version is “receipts or it didn’t happen.” Pipelock is the reference implementation. The full definition is the property pair below.

The property pair

A control qualifies as verifiable egress control when both hold:

Verify a Pipelock Receipt: Copy-Paste Demo

Thu, 21 May 2026 00:00:00 +0000

Pipelock writes a signed receipt every time it adjudicates an outbound agent action. Receipts compose into a hash-chained file an auditor or CI runner can read without trusting any vendor dashboard. This page is the shortest path from zero to “I ran the verifier, it passed, I tampered one byte, it failed.”

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.

Pipelock v2.5 Upgrade Guide

Wed, 20 May 2026 00:00:00 +0000

Pipelock v2.5.0 is an additive upgrade for most v2.4.x operators, but it changes two operational assumptions: inbound federation is stricter by default, and host containment now has a full lifecycle CLI that can enforce the agent/proxy separation on Linux.

Upgrade the binary first. Then enable the new controls one at a time.

Upgrade the binary

# Homebrew
brew upgrade luckyPipewrench/tap/pipelock

# or container
docker pull ghcr.io/luckypipewrench/pipelock:2.5.0

For direct binary installs, download the v2.5.0 artifact from the GitHub release and replace the existing binary.

Audit Packet Threat Model: What Verified Receipts Prove

Sun, 17 May 2026 00:00:00 +0000

Pipelock writes an Audit Packet after every mediated agent run. The packet pairs a verifier verdict over a chain of Ed25519-signed action receipts with the enforcement posture that produced them. The first producer is the Pipelock Agent Egress Control GitHub Action; producers on other CI surfaces follow the same schema.

This page is the threat model for the packet. It describes what a verified packet does and does not prove about the run, and the trust assumptions a relying party (CISO, auditor, downstream platform, procurement reviewer) should pin before treating a valid verdict as provenance.

Browser Shield: Defensive Response Rewriting

Sat, 16 May 2026 00:00:00 +0000

Browser Shield is a defensive response-rewrite layer. It runs after Pipelock fetches a response and before the agent receives the body. Page-side probes that try to enumerate browser extensions, tracking beacons, and hidden prompt traps get stripped from the response. Every rewrite gets recorded in the action receipt so an operator can audit the intervention later.

It is opt-in. browser_shield.enabled defaults to false. The strictness, size limit, and individual rewrite toggles all have safe defaults once enabled.

Continue.dev MCP Security: Scanning with Pipelock

Sat, 16 May 2026 00:00:00 +0000

Continue.dev is an open-source AI coding assistant that runs inside VS Code and JetBrains IDEs. It is MCP-native: tools, context providers, and integrations get loaded from MCP servers declared in the Continue config. Pipelock wraps each of those servers so every tool call and response runs through its MCP proxy.

Why Continue.dev needs an agent firewall

Continue sessions frequently involve:

Workflow	What Continue accesses	What could go wrong
Multi-file edits	Source code, secrets in history	Credentials leaked through tool arguments
Context providers	Repository search, docs, URLs	Prompt injection in fetched content
MCP tool execution	Filesystem, databases, APIs	Tool poisoning, rug-pull updates, chain attacks
Conversation history	Past plans, tool outputs	An injected instruction surviving across resume

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.

Pipelock Performance

Fri, 15 May 2026 00:00:00 +0000

Pipelock adds 0.5 to 2 ms to a round-trip depending on transport, and starts in under 50 ms. Numbers come from one quick-mode run on a Linux x86-64 desktop. Run it yourself; your numbers may vary slightly.

Latency overhead

The bench drives traffic against a deterministic mock backend directly and through Pipelock, in adjacent pairs to control for thermal drift.

Transport	Direct p50	Proxied p50	Pipelock overhead
HTTP GET	88 µs	1.6 ms	+1.5 ms
SSE (100 chunks)	81 ms	72 ms	within noise
Tool-call chain (3 round trips)	290 µs	2.2 ms	+1.9 ms
MCP stdio (`tools/call`)	22 µs	0.5 ms	+0.46 ms
WebSocket (100 frames)	5.7 ms	65 ms	+60 ms (~600 µs/frame)

SSE responses stream through Pipelock chunk-by-chunk. Direct TTFB is 152 µs; proxied TTFB is 1.33 ms — within one order of magnitude of direct, on every config including the default with response scanning fully on. Per-event DLP and prompt-injection scanning runs inline against each event; clean events flush immediately. The pre-v2.5 buffered downgrade (proxied TTFB ≈ full-stream time) is gone.

Zed MCP Security: Scanning with Pipelock

Fri, 15 May 2026 00:00:00 +0000

Zed MCP security starts with inspecting what flows between Zed and every context_server. Pipelock wraps each entry in your settings.json so every tool call and response runs through its MCP proxy. Works on Zed stable, Zed Preview, and Flatpak builds of either channel.

What’s new in recent releases

Zed integration is pure MCP proxy wrapping. That brings the current signed-evidence and class-preserving redaction surface into the Zed MCP path as soon as the wrap is in place:

Pipelock License Setup

Thu, 14 May 2026 00:00:00 +0000

Pipelock Pro and Founding Pro subscribers receive a signed license token by email after subscribing. The token unlocks premium features inside the pipelock binary. Setup is either an environment variable or an installed token file referenced from your config.

Install

pipelock license install <your-token>

That writes the token to ~/.config/pipelock/license.token with mode 0600. Override the path with --path if you want it somewhere else.

Then add the installed path to your pipelock YAML:

MCP Runtime Security: Live-Traffic Defenses for AI Agents

Tue, 12 May 2026 00:00:00 +0000

MCP runtime security in one paragraph

MCP runtime security is the practice of inspecting Model Context Protocol traffic while an agent is using it. It scans tools/list responses for poisoned tool descriptions, scans tools/call arguments for credential leaks, scans tools/call results for injected instructions, watches for tool description drift mid-session, and tracks cross-call patterns. Pre-deploy scanners check the server before the agent connects. Runtime scanners catch attacks that only appear once traffic is flowing. Both are necessary. Neither replaces the other.

MCP Vulnerability Scanner: Pre-Deploy and Runtime Compared

Tue, 12 May 2026 00:00:00 +0000

What an MCP vulnerability scanner actually does

An MCP vulnerability scanner checks Model Context Protocol servers and their tool definitions for security weaknesses. The category covers two distinct lanes.

Pre-deploy scanners examine an MCP server before an agent connects to it. They read tools/list output, validate schemas, check tool descriptions for poisoning, review dependency manifests for known CVEs, and flag suspicious patterns in tool argument shapes. The job is to catch the server-side flaws that are visible without traffic.

AI Agent Regulatory Controls and Evidence Hub

Mon, 11 May 2026 00:00:00 +0000

Most AI agent compliance writing collapses into one of two shapes: a vendor that claims to “solve” a framework, or a legal-summary blog post with no product story. Both are useless to the buyer who actually has to ship.

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.

AI Agent Action Receipts: Verify What an Agent Did Offline

Mon, 11 May 2026 00:00:00 +0000

You can build a runtime firewall for AI agents. You can write a policy. You can call it “agent security.” The harder question, the one buyers ask in their second meeting, is what did the agent actually do, and can you prove it without trusting the agent.

This page is the answer. A real action chain, an unsafe MCP tool response, the verdict Pipelock returned, the signed receipt that captured it, and the verifier commands you can run yourself to confirm it offline. The chain below is the kind of evidence we ship to compliance, audit, and incident-response teams. No screenshots, no narration around it. Just the artifacts.

Agent Egress Control: GitHub Action Setup

Sun, 10 May 2026 00:00:00 +0000

Pipelock Agent Egress Control is the missing CI primitive for AI agents. The action runs an agent script inside a Linux network namespace, forces every byte through Pipelock at the boundary, scans for credential exfiltration, prompt injection, SSRF, and policy violations, then writes a signed Audit Packet a third party can verify offline.

This page is the operator-facing setup guide for v0.1.0. Full reference and design notes live in the release notes and the README.

Compliance Evidence Substrate for AI Agents

Wed, 06 May 2026 00:00:00 +0000

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.

Skill Supply Chain Security: Poisoning Attacks Against npx skills, vercel-labs/skills, and the Open Skills Ecosystem

Wed, 06 May 2026 00:00:00 +0000

The Model Context Protocol settled into the default integration surface for agent tool calls during Q1 2026. By April every major coding agent shipped first-class MCP support, and the threat model for tool poisoning crystallized: hidden instructions inside tool descriptions and schema fields that the agent reads as guidance.

A parallel ecosystem started forming in the same window. Agent skills. SKILL.md files with YAML frontmatter, distributed via npx skills add <name>, installable across Claude Code, Cursor, Codex, and ChatGPT. Vercel-labs launched the open skills ecosystem in January 2026. By May a single skill in that ecosystem had passed 15,000 GitHub stars and 1,300 forks. Forks of the skills CLI itself exist.

Cloudflare AI Gateway: What It Does and Where It Fits

Tue, 05 May 2026 00:00:00 +0000

Pipelock is the open-source agent firewall written for the network-egress boundary. Pipelock emits mediator-signed action receipts from outside the agent trust boundary, scanning HTTP, MCP, and WebSocket egress for credential leaks, prompt injection, SSRF, and tool poisoning. Cloudflare AI Gateway is something else, sitting at a different boundary: hosted at Cloudflare’s edge, in front of LLM API calls, with caching, rate limiting, and content scanning on the prompts and completions that traverse the LLM-API surface. Both can be useful. They do not overlap as much as the marketing labels suggest.

Block Reason Headers

Mon, 04 May 2026 00:00:00 +0000

When Pipelock blocks a request on an HTTP-capable path, it sets a small set of response headers naming the rule class that fired, the severity, and an optional retry hint. The headers let an agent react to a block intelligently without parsing English error pages.

The schema is locked at v1. Additive changes (new reason codes, new optional headers) keep v1.

Headers emitted

Header	Required	Example
`X-Pipelock-Block-Reason`	Always	`dlp_match`
`X-Pipelock-Block-Reason-Version`	Always	`1`
`X-Pipelock-Block-Reason-Severity`	Always	`critical`
`X-Pipelock-Block-Reason-Retry`	Always	`none`
`X-Pipelock-Block-Reason-Layer`	Optional	`body_dlp`
`X-Pipelock-Block-Reason-Receipt`	Optional, reserved	`01J0GNYZ7XSQRTQ8FPYM5BHX2K`

The version header lets a future v2 schema break compatibility cleanly. Receivers should parse the version header first and reject unknown majors.

Pipelock Health Watchdog

Mon, 04 May 2026 00:00:00 +0000

The /health endpoint reports whether Pipelock’s HTTP server is responsive AND whether its internal subsystems are alive. External supervisors poll it to decide when to restart Pipelock or route traffic away from it.

v2.4.0 introduces a wedge-detection watchdog that flips /health to 503 Service Unavailable when any tracked subsystem is unhealthy. Before v2.4, /health returned 200 as long as the HTTP handler itself responded; a scanner deadlock or dead session-manager goroutine looked healthy from outside while customer traffic failed inside.

Learn-and-Lock Agent Contracts

Mon, 04 May 2026 00:00:00 +0000

Learn-and-lock is the path from “watch what this agent normally does” to “enforce that behavior as policy.” It is the mechanism behind progressive enforcement, the observe-first rollout pattern for deploying a blocking agent firewall without breaking production.

It exists because static allowlists get brittle fast. A coding agent may need GitHub, package registries, docs, search, issue trackers, MCP servers, and provider APIs. Writing every safe host, path, method, and data-class rule by hand is slow. Skipping policy is worse.

Pipelock v2.4 Upgrade Guide

Mon, 04 May 2026 00:00:00 +0000

Pipelock v2.4.0 is an additive upgrade for v2.3.x operators. Upgrade the binary first, then roll out the new controls deliberately.

Upgrade the binary

# Homebrew
brew upgrade luckyPipewrench/tap/pipelock

# or container
docker pull ghcr.io/luckypipewrench/pipelock:2.4.0

For direct binary installs, download the v2.4.0 artifact from the GitHub release and replace the existing binary.

Run:

pipelock version
pipelock check --config pipelock.yaml

Review health consumers

The health watchdog is enabled by default:

health_watchdog:
 enabled: true
 interval_seconds: 2

With the watchdog enabled, /health adds:

AI Agent Security Categories: What Each One Catches and Misses

Wed, 29 Apr 2026 00:00:00 +0000

The AI agent security market looks crowded because six different categories of product are all calling themselves the answer. Each category guards a different boundary. Each catches some attacks and misses others. Most buyers pick one and assume they bought coverage they did not.

This is a map. For each category, the page names the boundary it controls, the vendors who own it, what it catches, what it misses, and the buyer profile it actually serves. Pipelock sits in the sixth category. The other five are competition for budget more than for the same threat model.

Securing Claude Code Against Secret Exfiltration

Wed, 29 Apr 2026 00:00:00 +0000

Claude Code holds your secrets on purpose. The session reads and writes your repo using a GitHub token, calls cloud APIs with AWS or GCP credentials, and authenticates to Anthropic with an sk-ant-api03 key in your environment. That access is the point. The risk is that the same session can also fetch URLs, run shell commands, and call MCP tools, which means anything that steers the agent toward a network destination has a path to those secrets. This page covers how the leak actually happens on Claude Code specifically, the patterns that show up in the wild, and the defenses that catch each path before the request leaves your machine.

Preventing SSRF in AI Agents: Attack Vectors and Defenses

Wed, 29 Apr 2026 00:00:00 +0000

SSRF (Server-Side Request Forgery) was a server-side problem before agents existed. A web app would accept a URL parameter, fetch it server-side, and return the body. Attackers used that fetcher to reach internal services the public could not. The classic mitigation list (block private CIDRs, reject schemes other than http and https, resolve once and pin the IP) was already well documented before LLMs showed up.

AI agents bring the same primitive into a worse shape. The agent fetches URLs without a human in the loop. The URLs come from tool calls, fetched documents, MCP tool descriptions, and prompt injection payloads embedded in any of those. The trust path is longer and the input is adversarial by default. Web-SSRF defenses still apply, just against more parsers, more transports, and more URL-smuggling surfaces.

Self-Hosted Sure with Pipelock: Secure AI Assistant Egress

Tue, 28 Apr 2026 00:00:00 +0000

Inside the Sure chart

Sure is an open-source personal finance app maintained at we-promise/sure. It is a community-maintained fork of Maybe Finance, with a Rails 8 app, Sidekiq workers, optional Postgres and Redis, and a first-party Helm chart at charts/sure.

Starting with v0.6.9, Sure’s chart ships Pipelock as a first-class deployable component. Self-hosters running Sure with the external AI assistant feature get a security boundary between the assistant and the LLM provider or MCP servers it talks to, without rolling their own proxy.

Agent Evidence: SIEM and Detection Integration

Fri, 24 Apr 2026 00:00:00 +0000

Pipelock is a real-time agent firewall. It blocks what it can see on the wire. That is a hard, narrow job, and it is not the whole detection story.

Long-running agents move through multi-week attack chains, reason in natural language, and produce actions that look benign in isolation. No real-time gateway will catch all of that. The gate is the first line, not the last.

This page is for the people building the layer that runs behind the gate. SIEM engineers, SOC analysts, and researchers training detection models all need the same thing upstream: structured, tamper-evident evidence of what the agent did. Pipelock emits that as mediator-signed action receipts.

AI Agent Data Redaction

Fri, 24 Apr 2026 00:00:00 +0000

Pipelock v2.3.0 adds class-preserving redaction. When an agent tries to send a secret across the network boundary, the proxy can rewrite the value in place with a typed placeholder before the request leaves.

This is not a vault. It is not a key store. It is the gate at which a secret either gets rewritten before egress or the request is blocked.

What gets rewritten

The redactor walks JSON payloads, replaces matched values with typed placeholders such as <pl:aws-access-key:1>, then runs the normal request-side DLP scan on the rewritten bytes. Coverage in v2.3.0:

Pipelock v2.3 Upgrade Guide

Fri, 24 Apr 2026 00:00:00 +0000

Pipelock v2.3.0 is a drop-in upgrade. There are no breaking config changes from v2.2.x. New behavior is opt-in or default-on with conservative defaults.

What you have to do

For most installs, the upgrade is:

# Homebrew
brew upgrade luckyPipewrench/tap/pipelock

# or container
docker pull ghcr.io/luckypipewrench/pipelock:2.3.0

For direct binary installs, download the v2.3.0 artifact from the GitHub release and replace the existing binary. That is enough to pick up the bug fixes and tech-debt sprint without touching configs.

SSE Streaming Response Scanning

Fri, 24 Apr 2026 00:00:00 +0000

Pipelock v2.3.0 adds inline scanning for generic text/event-stream responses on the HTTP proxy paths, not only A2A. OpenAI chat completions, Anthropic messages, the Kilo Gateway streaming surface, and similar provider streams all flow through the same per-event scanner when they cross the forward proxy, TLS interception, or reverse proxy.

Token-by-token chat UX is preserved. A finding terminates the stream fail-closed before further events are forwarded.

Before and after

Before v2.3.0, only A2A streams received inline scanning. Generic LLM SSE responses were buffered before scanning, which broke streaming UX and capped response size at 1 MB on the reverse proxy.

LLM Security: A Practitioner's Guide to Protecting Large Language Models and AI Agents

Sun, 19 Apr 2026 00:00:00 +0000

What LLM security means in 2026

LLM security is the practice of protecting large language model applications, and the autonomous agents built on top of them, from attacks that exploit the model’s natural-language interface or the agent’s ability to take action in the world.

AI Agent Data Loss Prevention: How DLP Works for Agents (and Where It Breaks)

Sat, 18 Apr 2026 00:00:00 +0000

AI agents have credentials, shell access, and the internet. When one of them gets prompt-injected (through a poisoned MCP tool description, a malicious webpage, an instruction buried in a fetched document), those credentials leave through the next HTTP request the agent makes. AI agent data loss prevention is the practice of catching the leak before it leaves the network.

This page covers what AI agent DLP actually catches, where the leak channels live, why traditional DLP misses most of them, and the open-source self-hosted approach.

Chatbot Security: Risks, Defenses, and Where Network Controls Fit

Sat, 18 Apr 2026 00:00:00 +0000

What chatbot security means

Chatbot security is the practice of protecting users, operators, and downstream systems from the failures and attacks unique to chatbots that use large language models. The boundary is wider than it looks: a chatbot is a model plus a prompt plus everything it reads plus everything it can do.

The main risk categories:

Credential and PII leaks: the chatbot reads sensitive content and sends it somewhere it should not.
Prompt injection and indirect prompt injection: content the chatbot reads (user message, retrieved document, tool response, webpage) overrides its intended behavior.
Jailbreaks: adversarial prompts that bypass safety training.
Oversharing: the chatbot reveals system prompts, internal context, or backend data.
Hallucinations: the chatbot confidently states things that are not true and the user acts on them.
Tool abuse: when the chatbot can call APIs or take actions, those calls become an attack surface.
Supply-chain compromise: the model provider or hosted service is compromised.
Inadequate logging and audit: any of the above is invisible after the fact.

Each category has a defense pattern. The defenses combine; no single control catches everything.

What Is MCP? Model Context Protocol Explained for AI Agents

Sat, 18 Apr 2026 00:00:00 +0000

What is MCP?

MCP (Model Context Protocol) is an open standard for connecting AI applications to external tools and data sources. Anthropic introduced it in November 2024 and published the specification at modelcontextprotocol.io. Using MCP, an AI agent can discover what tools a server offers, call those tools with structured arguments, and receive structured results, all over a uniform protocol that works the same way regardless of which AI model or which external system is on either end.

Mediation Envelope Signing and Inbound Verification

Fri, 17 Apr 2026 00:00:00 +0000

Pipelock v2.2.0 extends the proof story from logs and receipts onto the request path itself.

When mediation_envelope.sign is enabled, Pipelock can attach a signed mediation envelope to proxied HTTP and MCP traffic so downstream systems can verify what policy mediated the request.

What the envelope carries

The mediation envelope is sideband metadata that tells the downstream system things like:

action
verdict
actor identity
policy hash
receipt correlation
taint state
task ID

Without signing, that metadata is still useful, but it is just a header or _meta field. With signing, the downstream verifier can check that the envelope was produced by Pipelock and not rewritten along the way.

Pipelock Kubernetes Companion Proxy

Fri, 17 Apr 2026 00:00:00 +0000

pipelock init sidecar --inject-spec is the most important deployment feature in v2.2.0, and its name is easy to misread.

It does not generate a same-pod sidecar. It generates an enforced companion-proxy topology for Kubernetes workloads.

What the command generates

Point the command at a Deployment, StatefulSet, Job, or CronJob manifest and it emits:

a patched workload that points HTTP_PROXY and HTTPS_PROXY at the companion Service
a Pipelock ConfigMap
a separate Pipelock Deployment
a Pipelock Service
agent and proxy NetworkPolicies
a PodDisruptionBudget

That gives you a cluster-enforced path where the workload can reach DNS and the Pipelock Service, and the Pipelock pods handle the actual internet egress.

Pipelock Posture Verify Guide

Fri, 17 Apr 2026 00:00:00 +0000

pipelock posture verify is one of the most useful operator additions in v2.2.0 because it turns a signed posture capsule into a deployment decision.

Instead of treating posture output as a report someone might read later, you can gate CI or release automation on it.

What it verifies

pipelock posture verify evaluates a signed posture capsule against:

integrity requirements
age requirements
a named policy
an optional minimum score

That gives you a binary answer for automation and a structured explanation for humans.

Pipelock Session Recovery

Fri, 17 Apr 2026 00:00:00 +0000

Adaptive enforcement is only operationally useful if someone can recover a session on purpose.

Pipelock v2.2.0 adds a real session-recovery surface: API endpoints for inspection and control, plus the pipelock session CLI for operators.

What the session CLI adds

The pipelock session command group gives operators five direct actions and one guided flow:

list
inspect
explain
release
terminate
recover

That is the difference between “we airlocked the session” and “we know exactly how to handle the next incident.”

Pipelock v2.2 Upgrade Guide

Fri, 17 Apr 2026 00:00:00 +0000

Pipelock v2.2.0 is an operator release. The biggest risk in the upgrade is not the scanner itself. It is rolling the new deployment and verification surfaces out without checking the configs that used to load quietly.

What changed in v2.2

The release adds four operator-visible surfaces:

strict YAML parsing that fails on unknown fields
pipelock init sidecar --inject-spec for Kubernetes companion-proxy generation
pipelock session for airlock recovery
pipelock posture verify and signed mediation envelopes for stronger downstream verification

Those changes sharpen the product, but they also make old config drift visible. That is a good thing, as long as you validate before swapping traffic.

AI Runtime Security: Defending AI Agents and Models at Execution Time

Tue, 14 Apr 2026 00:00:00 +0000

What AI runtime security means

AI runtime security covers the defenses that operate while an AI model or agent is actually running, as opposed to checks performed before deployment. The term appears in product categories from CrowdStrike, HiddenLayer, Operant, and a growing number of open source projects. Each vendor defines the scope slightly differently, but the common thread is the same: static analysis of a model or a codebase cannot cover every input the system will see in production, and some classes of attack only exist at execution time.

Generative AI Firewall: What It Is and When You Need One

Tue, 14 Apr 2026 00:00:00 +0000

A generative AI firewall is a security control that inspects traffic moving through generative AI systems and blocks the dangerous parts. Inbound prompts get scanned for jailbreaks and injection. Outbound completions get scanned for data leaks and unsafe content. Agent tool calls get scanned for exfiltration and policy violations. The firewall sits inline as a proxy, gateway, or edge service.

NeuralTrust used the “Generative Application Firewall” (GAF) label in a 2026 paper and helped popularize it, though vendors now use adjacent names for overlapping runtime controls. Cloudflare, Akamai, F5, Palo Alto, Lakera (Check Point), and Prompt Security (SentinelOne) all ship products that fit parts of the broader description, though the implementations vary significantly.

Cloudflare Sandboxes and Pipelock: Two-Layer Egress Control for AI Agents

Mon, 13 Apr 2026 00:00:00 +0000

What Cloudflare ships for agent egress control

Cloudflare Sandboxes went generally available on April 13, 2026 as part of Cloudflare Agents Week. The launch was a stack, not a single product. Sandboxes provide the container-based isolated environment for agent code. On April 13 Cloudflare shipped Outbound Workers for Sandboxes with zero-trust credential injection, TLS interception, and allow/deny lists. On April 14 they announced Cloudflare Mesh, a private networking fabric that connects users, nodes, and agents across clouds. The shared enforcement point for egress from a sandbox is the Outbound Worker.

The Mythos-Ready Playbook: Runtime Controls for the AI Vulnerability Storm

Mon, 13 Apr 2026 00:00:00 +0000

The 20-hour window

Mean time-to-exploit has collapsed. In 2018 it took an average of 2.3 years from CVE disclosure to confirmed exploitation. In 2024 that was down to 56 days. In 2026 it is approximately 20 hours.

Those numbers come from the Zero Day Clock by Sergej Epp, based on 3,529 CVE-exploit pairs drawn from CISA KEV, VulnCheck KEV, and XDB. The trend was cited in “The AI Vulnerability Storm: Building a Mythos-Ready Security Program” (v0.4, April 13, 2026), a joint briefing published by the CSA CISO Community, SANS, [un]prompted, and the OWASP GenAI Security Project.

MCP Authorization: Access Control for AI Agent Tool Calls

Sun, 12 Apr 2026 00:00:00 +0000

Non-human identity for agents

MCP authorization is one layer of a larger problem: how to govern non-human identities at machine speed. Every agent, script, CI job, and MCP server is an NHI. Each one needs a credential to call a tool, a policy that says which calls are allowed, and a way for security teams to see what that identity did. The three layers that matter in 2026:

Credential hygiene at rest. Tokens leak. GitGuardian’s 2026 State of Secrets Sprawl report documents 28.65 million secrets exposed on public GitHub in 2025 and a 5x acceleration attributed to AI agents. On April 14, 2026, Cloudflare announced scannable API tokens with GitHub Secret Scanning integration that auto-revoke on detection. That closes the detect-and-revoke loop after a token reaches a public repo. It does not prevent the agent from sending the token in the first place, and it does not help with tokens that leak through private channels.

OWASP MCP Top 10 (MCP01:2025 through MCP10:2025): Risks and Practical Defenses

Sun, 12 Apr 2026 00:00:00 +0000

The OWASP MCP Top 10 is the first OWASP framework dedicated to Model Context Protocol security. It catalogs the ten risk categories most likely to compromise an MCP deployment, from token mismanagement to shadow servers. The project is in beta as of 2026 under the lead of Vandana Verma Sehgal, with categories published as MCP01:2025 through MCP10:2025.

This page explains every category, then maps each one to the control type that actually mitigates it. The matrix is the core of the page. No single tool category covers all ten risks, and the honest answer about any vendor (including Pipelock) is that it covers some rows fully, some partially, and others not at all.

Shadow MCP: Find and Lock Down Rogue MCP Servers

Sun, 12 Apr 2026 00:00:00 +0000

Shadow MCP is the unknown half of your agent’s attack surface. Your developers installed Model Context Protocol servers during exploration, your AI IDE suggested a few more, and your CI pipeline pulls a couple through package dependencies. Nobody kept a list. Nobody reviewed the code. The agent is connecting to all of them.

Mend.io published an early public write-up on shadow MCP as unauthorized AI connectivity in your codebase. The category is now tracked as MCP09:2025 Shadow MCP Servers in the OWASP MCP Top 10 (beta, 2026). Credit where it’s due: Mend helped push the problem into the open before most teams had an inventory for it.

AI Agent Security Best Practices: A Practical Checklist