Skip to content
TapPass

Authoring policies

This page walks one rule from zero to enforced: block prompt injection above a threshold, for one agent, proven in shadow mode first.

1. Stage the rule

Section titled “1. Stage the rule”

Rules are added as control + params. BlockPromptInjection reads findings.injection_score and blocks above its threshold:

Terminal window
tappass policy rule add support-agent BlockPromptInjection \
  --org-id acme -p threshold=0.7

Staging prints a plan: the blast radius (which agents the change reaches), the rule diff, and any warnings. Nothing is enforced yet — the change sits in a draft version.

List the full authoring vocabulary (all controls with their params):

Terminal window
tappass policy controls

2. Prove it in shadow mode

Section titled “2. Prove it in shadow mode”

Apply the staged draft in shadow mode — evaluated on real traffic, recorded in decision evidence, never blocking:

Terminal window
tappass policy rule add support-agent BlockPromptInjection \
  --org-id acme -p threshold=0.7 --shadow

(One command: stage + apply-as-shadow. Or apply an earlier stage explicitly with tappass policy rule apply <policy-id> <version-no> --scope-id support-agent --shadow.)

Shadow results land in decision.evidence.shadow — the dashboard and audit trail show exactly which calls the rule would have blocked. For a what-if against historical traffic:

Terminal window
tappass audit replay <event-id> --policy-overrides draft-policy.yaml

3. Enforce

Section titled “3. Enforce”

Flip the same rule to active enforcement:

Terminal window
tappass policy rule apply <policy-id> <version-no> --scope-id support-agent

Or, for whole-version lifecycle management, publish — activating the version, retiring the previous one, and recompiling every reached agent’s bundle atomically. If any reached agent’s bundle fails to compile, the publish fails and nothing changes:

Terminal window
tappass policy v2 version publish <policy-id> <version-no>

Enforcement begins on the next governed call. No agent restarts.

4. Roll back

Section titled “4. Roll back”
Terminal window
tappass policy v2 version pull-back <policy-id> <version-no>

Pull-back moves the version to draft and restores the version it superseded. Note: a version that has governed a real call is hard-locked — it stays in the audit trail’s provenance forever. You can supersede it, never erase it.

Policies beyond a single rule

Section titled “Policies beyond a single rule”

The rule add flow is the fast path for agent-scoped rules. For multi-rule policies assigned at team/project/org scope, work with versions and assignments directly:

Terminal window
tappass policy v2 create --org-id acme --name frontline --description "Customer support baseline"
tappass policy v2 assignment create <policy-id> --scope-type team --scope-id team_frontline
tappass policy v2 version diff <policy-id> --from 3 --to 4

The same flow via API

Section titled “The same flow via API”
Step Endpoint
Stage changes POST /api/v2/policies/changes:stage
Apply POST /api/v2/policies/changes:apply
Inspect compiled output GET /api/v2/agents/{agent_id}/compiled
Publish impact preview GET /api/v2/policies/{policy_id}/publish-impact
Effective policy for an agent GET /api/agents/{agent_id}/policy/effective

Explain a hypothetical decision without touching traffic:

Terminal window
tappass policy explain support-agent --event-type TOOL_CALL --input '{"tool":"send_email"}'

Authoring rules of thumb

Section titled “Authoring rules of thumb”
  • Shadow first, always. Activate enforcement only after shadow evidence shows the rule fires where you expect.
  • Prefer redact over block for PII in prompts — the agent’s task usually survives without the SSN.
  • Compose, don’t clone. Assign broad baselines at org scope, tighten at project or agent scope; the strictest rule wins automatically.
  • Cap in one place. Token and spend caps merge as the minimum across layers — set them at the scope that owns the budget.

Next steps

Section titled “Next steps”