SAYLOR Identify dangerous permissions, trust-boundary failures, secret exposure, and irreversible actions before an AI agent receives a tool.
The result you're building
A go/no-go security decision for an agent tool, backed by a mapped authority boundary, tested abuse cases, least-privilege credentials, confirmation and spend limits, safe output handling, and an emergency disable path.
Use this guide when
- Connecting an agent to shell, browser, files, email, messaging, cloud, database, wallet, code execution, or another external tool.
- Reviewing a tool after its permissions or downstream account changed.
- Designing the approval boundary for autonomous work.
Do not use it as a substitute for
- Assuming a sandbox label, tool description, or system prompt prevents misuse.
- Granting broad production access and planning to add restrictions after launch.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- Tool origin, code/dependency provenance, version, and update mechanism.
- Every read/write/network capability and downstream identity.
- Data classification, tenant/account scope, and retention/logging behavior.
- All irreversible actions, monetary limits, and human approval requirements.
- Disable/revoke/rotate procedure and responsible owner.
Understand the system before fixing it
Authority is the product of all connected layers
Agent intent, tool schema, process identity, OS permissions, network reach, API token scope, and downstream policy combine. Restricting only one layer is not least privilege.
Untrusted content can become an instruction
Webpages, documents, emails, search results, issue text, and tool output must be treated as data. They cannot authorize another tool call.
Read access can still be dangerous
Reading secrets, personal data, browser cookies, or private repositories enables exfiltration even without a write tool.
Approval must describe the exact side effect
A generic 'allow tool' prompt is not informed consent. Show destination, amount, data, action, and whether it can be reversed.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Tool can execute arbitrary command/path/URL | Unbounded authority | Try allowlist bypass, traversal, redirects, and argument injection | Require structural validation, sandbox, allowlists, and separate narrow operations. |
| Tool reads untrusted content then can act | Injection chain | Place hostile instructions in retrieved data | Model must not turn data into authority; add policy gate and confirmation. |
| One credential reaches many tenants/resources | Blast radius | Attempt cross-scope resource identifiers | Use per-user/tenant tokens and server-side ownership checks. |
| Tool output/log contains credentials | Secret leak | Canary-secret and redaction test | Redact at source and response/logger boundaries; rotate exposed secrets. |
| Timeout leaves unknown state | Ambiguous sideeffect | Cancel/retry same operation | Need durable idempotency and reconciliation before autonomy. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Map the complete authority graph
Why: Permission names such as 'files' or 'email' hide paths, accounts, destinations, and side effects.
Do: Trace agent to tool process to OS/network to downstream API/account. Record exact resources, verbs, data, credentials, and administrative inheritance.
Read the result: Any wildcard resource, admin token, arbitrary URL, or arbitrary command is a preflight blocker unless strongly isolated.
Next: Define the minimum required graph for the intended task.
Step 02 — Reduce privilege at independent layers
Why: If model policy fails, another layer must still block the action.
Do: Use separate service accounts, narrow API scopes, directory/host allowlists, read-only mounts, egress restrictions, low-balance wallets, per-tenant tokens, and non-production defaults.
Read the result: Attempt the prohibited actions directly through the tool. They must fail without relying on the model to refuse.
Next: Record each enforced boundary and owner.
Step 03 — Separate data, proposal, approval, and execution
Why: Indirect prompt injection succeeds when untrusted data can directly trigger an action.
Do: Mark external content untrusted, generate a structured proposal, validate policy outside the model, and request exact human approval for consequential execution.
Read the result: Approval must bind to immutable action details and expire. Changed details require new approval.
Next: Add tests where content asks to bypass policy or exfiltrate data.
Step 04 — Bound resource and financial exposure
Why: Even legitimate loops can create cost, spam, account bans, or destructive scale.
Do: Enforce per-call, per-minute, daily, and total limits; maximum rows/bytes/recipients; timeouts; concurrency; and circuit breakers. Put monetary caps outside prompts.
Read the result: Splitting actions must not bypass aggregate limits.
Next: Test exhaustion and emergency pause.
Step 05 — Protect outputs, logs, and secrets
Why: Tool results can leak confidential material or carry instructions into later model context.
Do: Return only needed fields, label provenance/trust, cap size, strip active content where appropriate, redact secrets before logging, and prevent tool output from altering authorization state.
Read the result: Canary values should never appear in model-visible output or ordinary logs.
Next: Rotate any credential exposed during testing.
Step 06 — Make release conditional on abuse tests
Why: Happy-path demos reveal little about an agent tool's real risk.
Do: Test traversal, command/argument injection, SSRF/redirects, cross-tenant IDs, prompt injection in tool output, secret canaries, duplicate/cancel, limit splitting, and disabled-tool behavior.
Read the result: Release only when the tool fails closed and the disable path works without a redeploy.
Next: Schedule re-review on scope, credential, dependency, or model changes.
Worked example
Evidence collected
- A webpage can contain hidden instructions telling the agent to email collected data.
- Browser session includes authenticated internal applications.
- Email token can send externally to any address.
- No egress, recipient, content, or daily limit exists.
Decision: This is a complete indirect-injection-to-exfiltration chain with high blast radius.
Actions taken
- Separated a read-only public browsing profile from authenticated internal browsing.
- Restricted destinations and internal domains; labeled page content untrusted.
- Changed email to draft-only by default with recipient/domain allowlists and exact send approval.
- Added canary, hidden-text, redirect, and bulk-recipient tests.
Why this example matters: No prompt wording can make the original design safe. Independent permission boundaries break the chain.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Every capability and downstream privilege has a documented owner and purpose.
- Prohibited paths, hosts, accounts, tenants, recipients, and amounts fail at a non-model control.
- Untrusted tool output cannot grant authority or suppress confirmation.
- Duplicates, cancellation, loops, and limit splitting remain bounded.
- Secrets and canaries are absent from model-visible output and ordinary logs.
- Emergency disable and credential revocation are tested.
Rollback or safe recovery
- Disable the tool/capability first, then revoke or rotate its downstream credentials.
- Restore the prior allowlist/policy version if a change unexpectedly blocks legitimate work.
- Preserve sanitized audit evidence for incident review; do not erase logs to hide a failed test.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Tool refuses legitimate action | Policy context or allowlist is incomplete. | Add a narrow explicit rule; do not weaken the whole boundary. |
| Agent bypasses approval by splitting | Limits are per call rather than per logical job/window. | Aggregate by user, task, destination, and time window. |
| Secrets appear only in errors | Exception or upstream body bypasses normal redaction. | Redact centrally before serialization/logging and test failures. |
| Tool update adds permission | Update channel lacks change review or permission pinning. | Pin version and require a new preflight for scope changes. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- Authority graph and data-flow diagram/table.
- Least-privilege controls at tool, OS/network, credential, and downstream layers.
- Approval/idempotency/limits policy and exact enforcement locations.
- Adversarial test results and unresolved risks.
- Emergency disable, revoke, rotate, and incident owner instructions.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| tool | object | Origin, version, schemas, code provenance, and update channel. |
| capabilities | object[] | Reads, writes, network, identities, resources, and side effects. |
| dataClasses | string[] | Public, internal, personal, secret, financial, or regulated. |
| policy | object | Allow/deny, approvals, budgets, limits, retention, and escalation. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points