Test agent policies

Policy tests should exercise grants, denials, changed context and downstream bypass paths.

01 / The operating case

What changes in a real workflow?

A rule intended to allow invoice reads accidentally permits delete_invoice for the same service role.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Build a matrix of subject, task, operation, target, amount, expiry and revocation cases; include mutation tests and executor-path probes.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

Happy-path tests pass while one broad wildcard permits destructive actions.

Evidence to retain

Store policy version, fixture inputs, expected and actual verdict and bypass findings.

04 / Canonical scope

Why this reference stands alone

Simulation evaluates proposed policy against traffic; this page owns deterministic tests and invariants.

Illustrative implementation artifact

Policy negative-test matrix

case: valid grant + matching target -> ALLOW
case: same grant + other target -> DENY
case: revoked parent + matching target -> DENY
case: missing context + write -> INDETERMINATE
case: direct executor route -> equivalent DENY

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation