Pipeline

Pipeline

The Pipeline is the 32-step engine that runs on every governed call.

Every LLM call (via the LLM Gateway) and every tool call (via the MCP Broker) flows through it. PII and secret detection, exfil patterns, schema ACLs, loop guard, audit signing — all live here.

Already shipped as tappass/pipeline/.

At a glance

What it does	Runs a sequence of detection and decision steps on every governed call
Runs at	The two cross-cutting layers (LLM Gateway + MCP Broker)
Input	One call (LLM prompt+completion, or tool invocation+response) plus the relevant Compiled Policy aspects
Output	Allow / Deny / Redact decision, plus a signed audit row
Status	Shipped on main today (tappass/pipeline/, ~470 tests green)

The 32 steps

Roughly grouped:

Group	Examples
Identity & scope	verify_capability_token, enforce_session_scope, check_sandbox_active
Prompt-side detection	detect_pii, detect_secrets, detect_prompt_injection, detect_jailbreak, redact_pii_in_prompt
Policy decision	apply_compiled_policy, tools_allowed, tools_denied, schemas_acl
Tool-call governance (MCP Broker only)	schema_acl, loop_guard, tool_arg_validation, denied_tool_categories
Response-side detection	scan_output, detect_pii_in_response, detect_secrets_in_response, redact_response, enforce_no_train_flag
Budget / rate	enforce_token_budget, enforce_dollar_budget, enforce_rate_limit
Audit & signing	emit_audit_row, hash_chain_link, sign_mandate (ES256), persist_to_wal

The exact list lives in tappass/pipeline/; this card is the conceptual frame.

Why a pipeline (not a monolith)

Three properties matter:

1. Composable — each step is a small, well-tested function. New detectors plug in without touching others.
2. Configurable — which steps run is determined by the Compiled Policy's compliance_tags and the authoring resolver's enabled-detectors list. Different agents use different subsets.
3. Auditable — every step's decision is recorded. The audit row tells you not just "denied" but which step denied, which Compiled Policy aspect it consulted, and why.

The pipeline is what gives TapPass per-call reasoning that no single-detector tool can match.

Where the pipeline runs

Position	What runs
LLM Gateway	Identity → prompt-side detection → policy decision → upstream call → response-side detection → budget → audit
MCP Broker	Identity → schema_acl → loop_guard → tool-arg validation → upstream tool call → response data-class tagging → audit
Pre-deployment evaluation	Same pipeline, run against Probes before deployment to verify policy conformance

The pipeline is the single shared decision engine across both cross-cutting layers — same code, different inputs.

Step-level decisions feed the audit

Every step emits an audit fragment:

{
  "step":          "detect_pii",
  "decision":      "block",
  "evidence":      { "pii_type": "ssn", "redacted_count": 1 },
  "compiled_policy_aspect": "tools.deny_if_tainted.phi",
  "rule_provenance": { "tier": "org_floor", "compliance_pack": "hipaa" }
}

These fragments compose into one audit row per call. The full audit row includes:

• trace_id — one call (LLM or tool)
• session_id — which Session this call was part of
• agent_id / sandbox_id — who acted
• policy_version — which Compiled Policy was applied
• step_decisions[] — the sequence above
• mandate — Ed25519-signed final decision
• prev_hash — for hash-chain integrity

Auditors can verify any row offline using the JWKS-published TapPass public key.

Compiled Policy aspects the pipeline reads

The pipeline is a consumer of the Compiled Policy. It reads:

Aspect	What the pipeline does with it
tools.allow / tools.deny	Per-call gating in apply_compiled_policy
network.deny_categories	Egress detection in detect_exfil
budget.tokens_per_day	Per-org enforcement in enforce_token_budget
compliance_tags	Selects which detector subset runs (e.g. HIPAA tag → strict PHI mode in detect_pii)
interpreter.host_functions	Validates LLM-emitted codemode against allowed host calls
identity.tier	Coarse trust-tier defaults (observer disables more steps; full enables all)

Pipeline ≠ Cascade

Easy confusion worth flagging:

• Cascade = Policy authoring time. Org floor → project floor → agent override merged into one effective Policy.
• Pipeline = runtime enforcement time. The 32-step engine that runs on each call against the resulting Compiled Policy.

Cascade produces the Compiled Policy; Pipeline runs against it. Different layers of the stack.

Engines that operate on the Pipeline

Engine	What it does	Status
Pipeline runner	Executes the 32 steps in order; short-circuits on deny	shipped
Step registry	Per-org list of enabled steps + parameters	shipped
Detector library	Individual step implementations (PII, secrets, exfil, loop_guard, schema_acl)	shipped (most); new detectors per Compliance Pack
Audit emitter	Hash-chained WAL write	shipped
Mandate signer	ES256 mandate per call	shipped
Replay tool	Operator surface to re-run pipeline against historical inputs	concept (Q4 2026)

Status snapshot

Capability	Source	Status
Pipeline runner	tappass/pipeline/	Shipped (~470 tests green)
Standard detectors (PII, secrets, prompt-injection, exfil, scan_output)	tappass/pipeline/steps/	Shipped
schema_acl + loop_guard (MCP Broker steps)	concept	Q3 2026
Per-pack detector additions	concept	Q3-Q4 2026 (with each Compliance Pack)
Budget enforcement (token + dollar)	shipped	Live on main
Hash-chain audit + ES256 mandates	shipped	Live on main
Replay tool	concept	Q4 2026

Related concepts

• runs at → LLM Gateway and MCP Broker (the two cross-cutting layers)
• consumes ← Compiled Policy (per-aspect)
• emits to → Audit log (hash-chained, signed)
• tested by → Probe (pre-deployment evaluation runs the same pipeline)

Authoritative docs

Topic	File
Vision	governed-agents.md §2.2 — what the pipeline does
Threat coverage mapping	governed-agents.md §3.2 — OWASP LLM Top 10 → which step catches it
Component cards	Pipeline-step components live under q03-interactions-we-govern/ and per-pack detector libraries
Code	tappass/pipeline/ (live on main)

Common confusions

• Pipeline ≠ Pipeline (CI/CD). "Pipeline" in TapPass is the runtime enforcement engine, not a CI/CD pipeline. The TapPass repo also has a CI/CD pipeline; they're unrelated concepts.
• Pipeline ≠ Cascade. Cascade is policy-authoring; Pipeline is per-call enforcement.
• The 32 number isn't sacred. The catalog grows as Compliance Packs add detectors. The "32-step pipeline" is shorthand for the current shipped state; the architecture is "a configurable pipeline of steps," not "exactly 32 steps."
• Each step is independent. Adding a detector doesn't touch the others; removing one doesn't break the rest. This is what makes per-pack detector contributions tractable.