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.

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.

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

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.

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.

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

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.

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.

• Explore the capability database, see the capabilities a prompt maps to
• Lifecycle & rollout, shadow first, then enforce
• Rule reference, the vocabulary behind --from-rules