SAYLOR The result you are building
Finished Result:
An enforceable action-authority policy that distinguishes advice, drafting, reversible staging, and external execution, then proves that sensitive actions cannot occur without current, scoped approval.
Use this guide when
- An agent can send, publish, spend, delete, deploy, trade, invite, or change access.
- Different users or roles have different authority.
- You need a reliable audit record for approved, denied, expired, and altered actions.
Do not use it as a substitute for
- A generic 'yes' prompt detached from the final action payload.
- Using prior approval after the recipient, price, file, scope, or deadline changes.
Before you change anything
Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- Complete action inventory and side-effect classification.
- User, role, organization, and resource ownership mapping.
- Canonical action payload and risk tier.
- Approval channel, authentication strength, expiry, and revocation behavior.
- Evidence for bypass, replay, race, payload-change, and timeout tests.
Stop Before Proceeding:
Stop external execution when identity, ownership, final payload, risk class, or approval state is ambiguous. Do not ask the model to decide whether its own action is authorized.
Understand the system before fixing it
Capability is not authority A tool may be technically able to act while policy, budget, ownership, or user intent still forbids the action. Keep execution permission explicit and revocable.
Deterministic boundaries contain probabilistic reasoning Models may propose plans, but schemas, allowlists, budgets, approvals, idempotency, and postconditions must decide what can actually happen.
Approval must bind the final payload Hash or canonicalize action, target, amount, constraints, and expiry after planning but before execution. Any material change invalidates approval.
Higher impact needs stronger ceremony Reading public data and transferring funds should not share the same default. Match authentication, review detail, and quorum to consequence.
Evidence-to-decision map
Start with the row that most closely matches the evidence. The first test isolates a layer; it is not permission to
make every available change.
Evidence Likely layer First decisive check What the result means
Approved action Payload Compare approved digest to Approval authorizes a proposal, not the final request.
executes with binding execution digest
changed amount
Agent can call write Enforcement Attempt invocation without Approval exists only in UI or prompt, not at the tool boundary.
tool directly approval token
Old approval works Expiry/replay Replay token after expiry and Nonce, one-time use, or expiration is missing.
later after first use
Wrong person Identity/owner Resolve approver role against Authentication succeeded but authorization did not.
approves resource ship target ACL
User cannot tell what Consent UX Compare approval display to Material recipients, cost, data, or irreversibility are hidden.
will happen canonical payloadStep-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
01 Classify every action by consequence Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Separate advice, draft, preview, reversible staging, limited write, external communication, spend, privilege change, deletion, and irreversible execution. Assign default deny where impact is high.
Read the result: Every tool/action maps to one documented risk and approval class.
Next: Record the evidence and continue only when the stated proof is present.
02 Resolve identity, role, and ownership Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Authenticate the approver and evaluate their role against the exact target resource, organization, wallet, channel, or account.
Read the result: The approval service can prove who may authorize this target.
Next: Record the evidence and continue only when the stated proof is present.
03 Canonicalize the proposed action Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Freeze method, target, recipients, amount/max, data fields, files, timing, side effects, idempotency key, and expiry into a deterministic payload.
Read the result: Equivalent actions hash identically; any material change changes the digest.
Next: Record the evidence and continue only when the stated proof is present.
04 Collect informed approval Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Show the final human-readable effect, cost, destination, reversibility, data disclosure, and deadline. Use step-up authentication or multiple approvers for the highest class.
Read the result: The approval record contains identity, digest, policy version, decision, time, and expiry.
Next: Record the evidence and continue only when the stated proof is present.
Procedure continued 05 Enforce at the execution boundary Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Require a signed or server-side approval reference at the tool gateway. Re-evaluate policy immediately before execution; do not trust model text or UI state.
Read the result: Direct invocation, missing approval, wrong digest, wrong target, and expired approval all fail closed.
Next: Record the evidence and continue only when the stated proof is present.
06 Test replay, races, and partial failure Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Attempt duplicate execution, conflicting reuse, expiry, revoked approval, concurrent callers, dependency timeout, and payload mutation. Make side effects idempotent.
Read the result: One approval cannot create more effect than its explicit scope.
Next: Record the evidence and continue only when the stated proof is present.
07 Monitor and revoke Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Expose pending/used/expired/revoked state, alert on bypass attempts, and provide a kill switch for each high-impact action class.
Read the result: Operators can stop new actions without corrupting evidence or completed records.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet Evidence record Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- Complete action inventory and side-effect classification.
- User, role, organization, and resource ownership mapping.
- Canonical action payload and risk tier.
- Approval channel, authentication strength, expiry, and revocation behavior.
- Evidence for bypass, replay, race, payload-change, and timeout tests.
Acceptance scoreboard
- Every side-effecting tool has an enforced authority class.
- Approver identity and target ownership are verified independently.
- Approval binds the exact final payload, policy version, expiry, and maximum effect.
- Missing, changed, expired, revoked, replayed, and wrong-role approvals fail closed.
- Duplicate requests cannot duplicate side effects.
- Operators can revoke or kill high-impact actions while preserving evidence.
Decision rule SHIP / AUTOMATE GATE Proceed only when every required acceptance check is supported by direct evidence, rollback is available, and the remaining risk is explicitly owned. Unknown is not a pass.
Minimum handoff record
- Versioned human approval and action authority scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Starting Problem:
A deployment agent receives approval for a staging release, then reuses the same approval after its plan changes the target to production.
Evidence collected
- The approval text says 'deploy the fix' without environment.
- The execution tool accepts a free-form reason but no approval digest.
- Production and staging share the same deploy capability.
- Logs record the deploy but not the approving identity or policy version.
Decision The approval is not scoped and must not authorize production. Split capabilities, bind the final target, and enforce approval at the gateway.
Actions taken
- Created distinct staging and production action classes.
- Added canonical payload digest with environment and release hash.
- Required step-up approval for production.
- Added replay, mutation, and direct-call negative tests.
Proof Of Completion:
A staging approval cannot call production; altered release or target invalidates approval; one current production approval creates one audited deployment.
Why this example matters The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Every side-effecting tool has an enforced authority class.
- Approver identity and target ownership are verified independently.
- Approval binds the exact final payload, policy version, expiry, and maximum effect.
- Missing, changed, expired, revoked, replayed, and wrong-role approvals fail closed.
- Duplicate requests cannot duplicate side effects.
- Operators can revoke or kill high-impact actions while preserving evidence.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear What happened What it usually means Next safe move
Approved action executes Approval authorizes a proposal, not the Compare approved digest to execution digest with changed amount final request.
Agent can call write tool Approval exists only in UI or prompt, Attempt invocation without approval token directly not at the tool boundary.
Old approval works later Nonce, one-time use, or expiration is Replay token after expiry and after first use missing.
Wrong person approves Authentication succeeded but Resolve approver role against target ACL resource authorization did not.
Reusable handoff record
- Versioned human approval and action authority scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
Field Type Requirement
target object Versioned environment, resource, identity, or workflow being evaluated.
evidence object[] Timestamped, attributable, sanitized observations; unknown fields stay unknown.
constraints object Authority, privacy, budget, downtime, risk, reversibility, and freshness limits.
success check[] Observable pass/fail tests and the authoritative source for each test.
Returned output
Field Type Requirement
diagnosis object Likely layer, supporting and conflicting evidence, alternatives, and confidence.
plan step[] Ordered bounded actions with owner, risk, expected proof, and stop condition.
verification check[] Observed pass/fail/unknown results, not inferred success from command exit alone.
handoff object Sanitized evidence record, recovery state, remaining risk, and next review trigger.
Agent refusal and escalation rules
•
Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
•
Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
•
Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
•
Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule
Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low
confidence; a controlled test that isolates the layer and passes verification can support high confidence.Official reference starting points
- https://pages.nist.gov/800-63-4/
- https://www.nist.gov/itl/ai-risk-management-framework
- https://genai.owasp.org/initiative/agentic-security-initiative/