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”