Security Assurance Case#

This document describes Pipelock's security model, trust boundaries, threat coverage, and known limitations. It serves as the project's assurance case: a structured argument that security requirements are met.

Threat Model#

Pipelock protects against AI agents being tricked into harmful actions. The primary threats are:

1. Credential exfiltration: Agent leaks API keys, tokens, or secrets through HTTP requests, DNS queries, URL parameters, or MCP tool arguments.
2. Prompt injection: Attacker-controlled text in web pages or tool results redirects the agent's behavior.
3. Tool misuse: Agent executes destructive commands (file deletion, force-push, reverse shells) due to injection or misconfiguration.
4. Tool poisoning: MCP server descriptions contain hidden instructions or change definitions mid-session to manipulate agent behavior.
5. Data exfiltration: Agent sends sensitive workspace data to external endpoints through legitimate-looking requests.

These map to the OWASP Top 10 for Agentic Applications and are tested against a full evasion test suite (see README testing metrics).

Trust Boundaries#

Pipelock is designed to be deployed in a capability-separated architecture:

+-----------------------+ +------------------------+ +----------+
| Agent | ---> | Pipelock Proxy | ---> | Internet |
| (has secrets/API keys | | (has network access, | | |
| no network access) | | no agent secrets) | | |
+-----------------------+ +------------------------+ +----------+

Trust boundary 1: Agent → Proxy. All outbound HTTP traffic passes through the fetch proxy. The agent cannot reach the network directly (enforced by container networking, firewall rules, or OS-level restrictions).

Trust boundary 2: MCP Client → MCP Server. The MCP proxy sits between the agent and any MCP server, scanning both directions. Client requests are checked for DLP leaks and injection. Server responses are checked for prompt injection and poisoned tool descriptions.

Trust boundary 3: Tool call → Execution. The tool call policy engine evaluates MCP tools/call requests against configurable rules before they reach the server. Destructive operations can be blocked regardless of how the agent was tricked into requesting them.

Security Controls#

Defense in Depth#

No single control is assumed to be sufficient. The scanner pipeline applies 11 layers:

Response scanning adds prompt injection detection on fetched content. MCP scanning adds bidirectional inspection of tool calls and results.

Fail-Closed Design#

All ambiguous states default to blocking:

• HITL timeout → block
• Non-terminal input → block
• JSON parse errors → block (configurable)
• Context cancellation → block
• Unknown policy actions → treated as block

Evasion Resistance#

DLP and injection scanners are tested against encoding chains (base64, hex, multi-layer URL encoding), Unicode confusables (Cyrillic, Greek, Armenian, Cherokee), combining marks, control character insertion, field splitting, and whitespace manipulation. See the test suite for the full evasion catalog.

What Pipelock Does NOT Protect Against#

Honest assessment of limitations:

• Model-level attacks: If the model itself is compromised or fine-tuned to be malicious, Pipelock cannot detect this. We operate at the communication boundary, not inside the model.
• Novel evasion techniques: Pattern-based detection catches known techniques. Novel bypasses require scanner updates. We do not claim complete coverage.
• Encrypted or steganographic exfiltration: Data hidden within legitimate-looking content (e.g., encoded in image pixels or timing channels) is beyond pattern-based detection.
• Insider threats: If the agent operator intentionally configures Pipelock to be permissive, the tool respects that configuration.
• Attacks that don't cross a boundary: If an agent and its tools run in the same process with no proxy, Pipelock has nothing to inspect.

Compliance Mappings#

Detailed mappings to security frameworks:

• OWASP Top 10 for Agentic Applications (coverage of ASI01–ASI10)
• OWASP Agentic AI Threats & Mitigations (coverage of T1–T15)
• EU AI Act Compliance Mapping (Articles 9, 12–15, 26 with NIST AI RMF crosswalk)

Verification#

Security claims are verified through four testing layers, static analysis, and supply chain controls.

Testing Layers#

1. Unit and integration tests: Full test suite with race detector enabled in CI. See README testing metrics for current numbers.
2. Evasion test suite: Encoding chains (base64, hex, base32, double-encoding), Unicode confusables (Cyrillic, Greek, Armenian, Cherokee), combining marks, control character insertion, field splitting, and whitespace manipulation tested against all scanner layers.
3. Black-box binary tests: End-to-end tests run against a built binary, exercising the full proxy and scanner pipeline through real HTTP, WebSocket, and MCP requests.
4. Private adversarial corpus: A separate adversarial test suite covers real-world evasion and attack classes against the production binary. This corpus is private for the same reason mature security vendors do not publish every regression: a test suite should improve defense, not double as an attacker playbook.

The adversarial suite covers:

• Encoded data exfiltration via DNS subdomains and HTTP parameters
• Traffic blending with legitimate request profiles
• Multi-encoding evasion chains (layered encoding, interleaved noise)
• Scanner layer boundary testing (entropy thresholds, label length limits)
• Config downgrade and hot-reload state attacks
• Operator terminal injection (escape sequences, bidirectional overrides)
• MCP response injection via non-standard result shapes
• Tool description manipulation and session binding attacks
• Scan API authentication, rate limiting, and fail-closed behavior

The suite is updated alongside every release and whenever new evasion classes are discovered. Every confirmed finding becomes a permanent regression test.

Static Analysis and Supply Chain#

• Static analysis: CodeQL (security-and-quality) and golangci-lint with gosec
• Dependency monitoring: Dependabot alerts, govulncheck in CI
• Signed releases: Cosign signatures, SLSA provenance attestations, CycloneDX SBOM
• Vulnerability disclosure: Responsible disclosure via GitHub Security Advisories