Opt-in TAP mode — reach any service with no keys in the agent process

[nanaknihal]

Opt-in TAP mode — reach any service with no keys in the agent process

What this adds

An optional, off-by-default way to connect OpenTag's sources without
holding service API keys in the agent process. Set one env var
(TAP_AGENT_KEY) and the agent reaches GitHub, Linear, Notion, PostHog —
and any other service the team connects — through the
TAP
credential proxy: the secret is injected server-side, pinned to that
service's own API host, and every call is audited.

Without TAP_AGENT_KEY, nothing changes. No new dependencies (stdlib
urllib only). It composes per service with the existing integrations: any
key still set in .env keeps its direct MCP connection; each key you leave
out moves that service behind TAP. No all-at-once migration.

# .env — instead of LINEAR_API_KEY / NOTION_MCP_AUTH_TOKEN / POSTHOG_PERSONAL_API_KEY / …
TAP_AGENT_KEY=tap_...

Why

OpenTag's confirm_write card is good conversation UX, but the service
keys still live in the agent process — one prompt injection away from
env | grep -i key. TAP mode removes the thing that can leak, and makes
the write gate enforced rather than advisory where it matters:

• Any service, zero code. Two generic tools (tap_discover +
  tap_call) cover every service without a direct MCP connection here.
  Connect a new service in the TAP dashboard and the bot can use it on the
  next Slack message.
• No keys in the process. For TAP-covered services, a prompt-injected
  agent has no key to leak and nowhere else to send one — the credential is
  injected server-side and destination-pinned to the service's own host.
• One human approval per write — never two. tap_call reads the
  credential's declared TAP policy: when TAP will hold the call for an
  approver, that enforced server-side approval is the single gate (the
  in-channel card is skipped); when TAP auto-approves the route, the usual
  confirm_write card appears. Any doubt falls back to showing the card.
• Lazy setup from inside Slack. Ask for a service that isn't connected
  and the bot replies with an origin-verified setup link — the secret goes
  into the TAP dashboard, never into chat.

What it looks like

Boot, with no service keys anywhere in the process:

[TOOLS] TAP mode: no direct service keys set — all services are reached via tap_call, no keys in process
[TOOLS] TAP connectivity OK — credentials available: github, linear, notion, posthog
[AGENT] Main tools: ['tap_discover', 'tap_call', 'tap_check_approval']

Security notes (reviewed adversarially before submission)

• The agent never dials upstream targets itself — only the proxy.
  Destination pinning and SSRF guards are server-side.
• Human-facing TAP links (credential setup, approvals) are
  origin-checked before the model may relay them; anything that isn't
  TAP's origin is stripped. This closes the "injected model swaps the setup
  link for a phishing page" seam.
• Model-supplied x-tap-* headers are dropped (spoof-tested); header names
  are validated against the RFC 7230 token charset.
• The read/write split fails toward confirmation: ambiguous calls and
  body-less GraphQL POSTs are treated as writes.
• TAP_PROXY_URL requires https except toward loopback (it receives the
  agent key).
• Parallel tool calls are disabled: an interrupt freezing a multi-call step
  corrupts the Responses API's bookkeeping on resume (found in live
  testing; this also protects the stock MCP write interceptor, which
  interrupts the same way).

Testing

• 130 agent unit tests pass (cd agent && uv run pytest); TAP mode adds
  coverage for the policy-rule matcher and precedence, spoofed-header
  rejection, link origin validation, approval poll states (approved /
  denied / expired / pending), fail-closed fallbacks, and the read/write
  split table. All hermetic — no network.
• Verified end-to-end against a live Slack workspace: reads, a held write
  approved from the TAP dashboard, the lazy credential-setup flow, denials
  failing closed, and a time-boxed approval grant.

Files

• agent/tap_tools.py — tap_discover, tap_call, tap_check_approval
  (stdlib-only)
• agent/prompts/tap.py — system-prompt addendum (only added in TAP mode)
• agent/internal_sources.py — per-service compose + boot diagnostics
• agent/agent.py, agent/main.py — single-call steps; recursion budget
  carried into the AG-UI per-run config (with_config was being dropped)
• docs/tap.md, setup.md, README.md, .env.example,
  .railway/railway.ts — setup docs, presented as a per-service choice at
  the credential step

---

Demo video to follow in a comment.

🤖 Generated with Claude Code