Skip to content
TapPass

Govern an agent from a sentence

The hardest part of governing an agent is the blank policy screen: which tools, which models, which arguments? TapPass closes that gap. Describe the agent’s job in a sentence and it derives the smallest capability envelope that lets the agent do that job — and nothing else.

The command

Section titled “The command”
Terminal window
tappass policy create \
  --org-id acme \
  --name support-agent \
  --from-prompt "handles customer support email — reads tickets, drafts replies"

TapPass reads the intent, maps it to the capabilities that job implies, and writes a policy named support-agent:

created policy pol_7f3a…  name=support-agent

That’s a least-privilege policy — a support agent gets email-read and draft capabilities, not the ability to send wire transfers or read your source repos.

Preview before you persist

Section titled “Preview before you persist”

Add --dry-run to see the capability envelope the sentence produces without writing anything:

Terminal window
tappass policy create \
  --org-id acme --name support-agent \
  --from-prompt "handles customer support email" \
  --dry-run
draft support-agent — capabilities: email.read, email.draft, ticket.read  (dry run, nothing persisted)

Iterate on the wording until the envelope is exactly what you want, then drop --dry-run to save it. Use -o json to capture the full draft (every capability and rule) for review or diffing in CI.

Co-create it interactively

Section titled “Co-create it interactively”

Add -i and the same command becomes a working session — TapPass proposes, you steer, and nothing persists until you say so:

$ tappass policy create --org-id acme --name support-agent -i     --from-prompt "handles customer support email"
I read that as 4 rule(s):
  [1] AllowCapabilities — capabilities=email.read, email.draft, ticket.read
  [2] BlockPII — threshold=0.6
  [3] MaxSpend — usd=5
  [4] SessionRateLimit — max_events=200
Anything I missed or got wrong? (Enter = looks right; `drop N …` removes; or just tell me)
> it should never email anyone outside our domain
updating with your refinement…
I read that as 5 rule(s):
  …
  [5] ConstrainCapabilityArgs — recipients must end in @acme.com
> drop 3
dropped 1; 4 rule(s) remain
> ⏎
Create policy 'support-agent' with 4 rule(s) as a draft? [Y/n] y
created policy pol_7f2…  name=support-agent
next: test it — `tappass try "…" --dry-run` · `tappass policy explain` · then promote from shadow

Say what’s missing in plain language and the proposal re-derives with your refinement folded in; drop rules by number; confirm — and exactly the rules you approved are what gets created, nothing re-derived behind your back.

When you already have the rules

Section titled “When you already have the rules”

If you’ve authored rules by hand — or exported them from another environment — create the policy from a file instead of a prompt:

Terminal window
tappass policy create \
  --org-id acme --name locked-down \
  --from-rules rules.json --dry-run

rules.json is a JSON list of rule objects ({kind, ordinal, payload, mode?}) drawn from the rule reference. Provide exactly one of --from-prompt or --from-rules.

Roll it out safely

Section titled “Roll it out safely”

A freshly created policy should go out in shadow (watch) mode first — decisions are recorded but nothing blocks — so you can watch the evidence before it enforces. See Lifecycle & rollout for assigning the policy to an agent and promoting it from shadow to enforce.

Prefer to let the agent’s actual behavior write the policy rather than a description? That’s watch mode.

Next steps

Section titled “Next steps”