TapPass — Overview
TapPass — Overview
Section titled “TapPass — Overview”The story in 6 sentences
Section titled “The story in 6 sentences”-
The problem. Within 18 months, every enterprise will install AI agents with read-write access to systems they previously trusted only humans with — Collibra catalogs, Salesforce records, GitHub repos. Their CISOs aren't ready, and existing tools cover one-third of the problem each (framework permissions are cooperative; container sandboxes are blind to meaning; interpreter sandboxes are narrow). None integrate.
-
TapPass is the substrate underneath. Teams own Projects which contain Agents. Operators author one Policy per cascade level. The Policy compiler produces a Compiled Policy per Sandbox. Providers — one per tool — render it into the configs Claude Code, OpenShell, Monty, the LLM gateway, and the MCP broker actually consume. The Policy engine runs pipeline steps on every call. Each Session emits hash-chained, Ed25519-signed events into the Audit log.
-
We govern every framework. Pick no winners. Same Policy governs Claude Code on laptops, LangChain in K8s, custom Python in CI — different Runtimes (recipes of providers) per surface, one Policy across all of them. The compatibility matrix shows what every customer gets with their stack.
-
Three products from one substrate. Runtime (free, open-core, viral developer adoption); Control (SaaS + on-prem, CISO pays per agent); Intelligence (data moat, 2027). Free where it makes us a substrate; paid where the CISO experience lives.
-
The MVP gate is the Minimum Credible Substrate — Q2 2026. Four pieces: canonical Compiled Policy + 2 providers across 2 rings + push/pull/reconcile control loop + agent registry. If these ship together, the architectural claim is provable end-to-end with three reference customers.
-
Why TapPass and not the obvious alternatives. OPA evaluates policy but doesn't deliver. Service mesh handles the network layer (one of five). IDPs issue identity but not capabilities. Per-vendor governance reproduces the problem at meta-level. We are the only substrate that compiles one Rego policy into manifests that govern at every chokepoint, across every framework, on every host.
End-to-end view
Section titled “End-to-end view”The full picture — from the people who author Policy to the audit log that records every governed event:
╔═══════════════════════════════════════════════════════════════════════╗ ║ ORG ║ ║ ║ ║ ┌─────────────┐ own ┌─────────────┐ contain ┌─────────┐ ║ ║ │ TEAMS │────────────▶│ PROJECTS │───────────▶│ AGENTS │ ║ ║ │ SSO-backed │ │ "EU │ │ Claude │ ║ ║ │ org admin │ │ support" │ │ Code, │ ║ ║ │ proj admin │ │ "Finance │ │ Lang- │ ║ ║ │ agent owner │ │ refunds" │ │ Chain, │ ║ ║ │ auditor │ │ │ │ custom │ ║ ║ └─────────────┘ └──────┬──────┘ │ Python │ ║ ║ │ └─────────┘ ║ ║ POLICY cascade ◄───────authored at every level───────────────────── ║ ║ org floor → project floor → agent overrides (strictest-wins) ║ ║ │ ║ ║ │ POLICY ENGINE runs pipeline steps per call (hot path) ║ ║ │ POLICY COMPILER produces signed Compiled Policy (static) ║ ║ │ ║ ╚═════════│═════════════════════════════════════════════════════════════╝ │ │ signed sync push ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ COMPILED POLICY │ │ signed JSON • one per Sandbox • read-only mount │ └─────────┬───────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ PROVIDERS (per target, v1: 4) │ │ claude-code → settings.json monty → host-fn manifest │ │ openshell → YAML profile langchain-sdk → SDK runtime │ │ + cross-cutting: anthropic-gateway · mcp-broker │ └─────────┬───────────────────────────────────────────────────────────┘ │ enforce on ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ SANDBOX (host machine) │ │ │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ AGENT runs as a long process │ │ │ │ │ │ │ │ Has many SESSIONS over its lifetime: │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Session 1│ │Session 2│ │Session 3│ ... │ │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ │ each call goes through │ │ │ │ │ Policy engine → upstream → response │ │ │ │ ▼ │ │ │ │ TOOLS (gmail.send, stripe.refund, custom MCP, ...) │ │ │ │ │ │ │ │ Each Session: tracked for loop_guard, drift baseline, │ │ │ │ audit-chain integrity, capability tokens. │ │ │ └───────────────────────┬───────────────────────────────────┘ │ │ │ every governed event │ └───────────────────────────┼─────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ AUDIT LOG │ │ Hash-chained • signed Ed25519 mandates • offline-verifiable │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ Compliance │ │ Drift │ │ Incident │ │ │ │ reports │ │ detection │ │ response │ │ │ │ (SOC 2, EU │ │ (vs. │ │ (filter by │ │ │ │ AI Act,...) │ │ baseline) │ │ session_id) │ │ │ └──────────────┘ └──────────────┘ └──────────────────┘ │ └─────────────────────────────────────────────────────────────────────┘Read top to bottom: Teams own Projects, Projects contain Agents. Operators on those Teams author Policy at the appropriate cascade level. The Policy compiler produces a signed Compiled Policy. Providers translate it to per-target configs. The Sandbox runs the Agent. Each Session is one continuous run, tracked for loops and drift. Every call through the Policy engine emits a hash-chained audit row. The audit log is the compliance evidence trail — verifiable offline.
For each box's depth, click into the concept cards.
In one (simpler) diagram
Section titled “In one (simpler) diagram” Operator │ authors Policy in Rego (with quick-starts: compliance packs, function/category vocabulary) │ ▼ Compiled Policy (signed JSON, one per Sandbox) │ ▼ Providers per target (4 v1: claude-code, openshell, monty, langchain-sdk + 2 cross-cutting) │ ▼ Runtime = recipe of which Providers per part │ ▼ Sandbox (running Agent, governed at every chokepoint) + Audit log (hash-chained, signed)Why now (3 bullets)
Section titled “Why now (3 bullets)”- Every SaaS vendor is shipping agents into customer environments. Within 18 months every install is a procurement gate.
- Every developer machine runs agentic IDEs (Claude Code, Cursor, Cline) — the most privileged, least-governed surface in modern IT.
- Every CISO is asking "what's our governance story?" — and the honest answer today is we don't have one.
What it is (2 pillars)
Section titled “What it is (2 pillars)”| Pillar | What it does |
|---|---|
| Enforcement Plane | 3 in-process rings (harness / kernel / interpreter) + 2 cross-cutting layers (LLM gateway, MCP broker). Every governable agent action passes through some subset of these 5 positions. |
| Control Plane | OPA cascade → canonical Compiled Policy → providers per target → push/pull/reconcile to every host. The Terraform pattern, applied to agent runtimes. |
Three products from one substrate
Section titled “Three products from one substrate”| Product | Buyer | Motion | Status |
|---|---|---|---|
| Runtime (open-core) | Developer | pip install tappass — viral, zero-friction | MCS Q2 2026 |
| Control (SaaS + on-prem) | CISO / Head of AI / GRC | Enterprise sale | Q3-Q4 2026 |
| Intelligence (data moat) | Existing Control customer | Upsell | 2027 |
The flywheel: Runtime → installed everywhere (telemetry source) → Control sells to the same orgs (deal value) → Intelligence emerges from cross-customer scale (compounding moat).
Five defensibility bullets
Section titled “Five defensibility bullets”- Neutrality across runtimes. We govern every framework; compete with none. Vendors' interests align with ours.
- Three-ring + 2-cross-cutting coverage that no single-layer tool matches.
- Open-core distribution flywheel. Free Runtime seeds the market; CISO pays for Control.
- Compliance-as-product. Pre-mapped against EU AI Act / SOC 2 / ISO 42001 / NIST AI RMF / OWASP LLM Top 10. Procurement-defensible.
- Cross-customer telemetry moat (Intelligence). Late entrants cannot catch up with telemetry they never captured.
The Minimum Credible Substrate (Q2 2026 ship target)
Section titled “The Minimum Credible Substrate (Q2 2026 ship target)”Four pieces. If these ship together, the architectural claim is provable end-to-end. Everything beyond is broadening, not core.
- Canonical Compiled Policy (signed, versioned, schema-stable)
- At least two providers across two rings (e.g. Claude Code harness + OpenShell or nono kernel)
- Push / pull / reconcile control loop
- Agent registry / state store (knows desired vs. applied per agent)
See concepts/minimum-credible-substrate.md for the full MCS framing and what's gated against it.
What's shipped today vs. concept
Section titled “What's shipped today vs. concept”| Capability | Status |
|---|---|
| LLM Gateway (Anthropic / OpenAI-compat / LiteLLM 100+ providers / MCP) | ✅ shipped (tappass/gateway/) |
| OpenShell sandbox (Landlock + L7 network + credential hiding + trust tiers) | ✅ shipped (tappass/sandbox/) |
| Audit hash-chain + ES256 mandates + 32-step pipeline | ✅ shipped |
| Intent-to-policy authoring substrate (function/category/concern/capability resolver) | ✅ shipped on main (~470 tests) |
| BYOK LLM keys + per-org KMS-envelope | ✅ shipped |
| nono capability sandbox (laptop kernel ring) | ✅ shipped |
Compiled Policy derivation engine + signed sync + 3 CLIs (tappass, tappass-host, tappass-agent) | concept (Q3 2026) |
| MCP broker + per-org MCP registry | concept (Q4 2026) |
| Compliance packs (EU AI Act, OWASP LLM, GDPR, …) | concept (Q3 2026) |
| Pre-deployment evaluation harness + probe libraries | concept (Q4 2026) |
| Drift detection | concept (Q4 2026) |
| SOC 2 Type 1 audit | calendar Q3-Q4 2026 |
Compatibility matrix — what governance you get with your stack
Section titled “Compatibility matrix — what governance you get with your stack”This is the buyer's first question. Full breakdown in COMPATIBILITY-MATRIX.md. Highlights:
| Ecosystem | LLM gateway | MCP | Codemode | Harness | Kernel |
|---|---|---|---|---|---|
| Custom code via tappass-agent SDK (canonical) | ✓ | ✓ | ✓ | ✓ | ✓ |
| Claude Code | ✓ | ✓ | partial | ✓ | optional |
| LangChain ReAct | ✓ | ✓ | ✓ | ✓ | ✓ |
| Cursor | ✓ | partial | ✗ | partial | ✗ |
| OpenAI Assistants API | ✓ | ✗ | ✗ | ✗ | ✗ |
| n8n | partial | ✗ | ✗ | ✗ | ✗ |
| LibreChat (self-hosted server) | ✓ | ✓ | ✓ | ✓ | ✓ |
| Element / Slack / Discord / Teams bots | ✓ | ✓ | partial | ✓ | ✓ |
What we're explicitly not doing
Section titled “What we're explicitly not doing”- Not an agent framework. We instrument other frameworks; we don't replace them.
- Not a sandbox from scratch. OpenShell, gVisor, Firecracker exist; we consume them.
- Not deep LLM content filtering. Lakera / Prompt Armor / Robust Intelligence integrate.
- Not pivoting to eval / observability. Arize / Langfuse / Braintrust are partners.
- Not a compliance auditing firm. Auditors are customers, not competition.
Where to go next
Section titled “Where to go next”| If you are… | Read this |
|---|---|
| CEO / partner exec | This file. Then concepts/tappass-strategy-memo-v3.md (the canonical strategic frame). |
| Investor | This file. Then strategy memo §05 (competitive landscape), §11 (product shape), §14 (moats). |
| CTO at a buyer / partner | This file. Then COMPATIBILITY-MATRIX.md. Then concepts/governed-agents-architecture.md. |
| Platform engineer joining | KICKSTART.md → "I'm a platform engineer joining TapPass". |
| Compliance / GRC owner | KICKSTART.md → "I'm a compliance / GRC owner". Then concept-cards/compliance-pack.md. |
| Subagent dispatched to component X | KICKSTART.md → "I'm a subagent dispatched to implement component X". |
| Anyone else | KICKSTART.md — pick your role. |
The thesis in one sentence
Section titled “The thesis in one sentence”Make TapPass the substrate every enterprise trusts to say "yes" to agentic AI — three rings of enforcement, two cross-cutting layers (LLM gateway and MCP broker), and a control plane that pushes, pulls and reconciles policy across every agent surface we can reach.
Last updated: 2026-05-07. Canonical strategic frame: TapPass Strategy Memo v3 (2026-04-28). This OVERVIEW is the one-page rendition; everything else in architecture/ is downstream.