Skip to content

Ways to connect

There’s no single way to adopt TapPass. Pick the shape that fits how your agents already run — you can mix them, and every path produces the same governed, audited decisions.

Surface Shape You change Best when
Gateway TapPass in the request path, OpenAI-/Anthropic-compatible One line — your base_url You want model traffic governed and provider keys handled, with zero code change
Verdict API TapPass beside your app; you execute One call at each decision point You keep execution in your own runtime, incl. non-LLM actions
Hooks The verdict API from a hook you already have A few lines in a pre-execution hook Your agent/IDE/gateway has a pre-tool or pre-call seam (Claude Code, Cursor, LiteLLM)
Governed MCP A governed MCP endpoint Point your MCP client at it Your agent speaks MCP and you want every tool call brokered
  • Want the least work and you’re calling an LLM? Swap your base URL for the gateway. Your agent never holds a provider key, streaming and audit come for free, and a block comes back as a readable message instead of an error.
  • Governing things that aren’t model calls — tool calls, database writes, state transitions — or you don’t want a proxy in the path? Use the verdict API: ask, then act on allow / block / needs_approval.
  • Already have a hook point (Claude Code PreToolUse, a LiteLLM guardrail, your framework’s tool wrapper)? Drop the verdict call into that hook — ambient governance, no rewrite.
  • Your agent speaks MCP? Point it at the governed MCP endpoint and every tools/call is governed without touching agent code.

Whichever surface you use, you authenticate with a tp_ key, the decision is made server-side against the agent’s policy, obligations (like redaction) are applied, and the outcome is written to a tamper-evident audit trail. An allow carries a short-lived signed mandate your downstream can verify offline.