Agent Tool Security Preflight

The result you are building

Finished Result:

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.

Stop Before Proceeding:

Reject connection when the tool can access secrets or irreversible actions outside a hard-coded/externally enforced policy, when its origin or update channel is untrusted, or when it lacks a fast revocation path.

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

  Start with the row that most closely matches the evidence. The first test is meant to isolate a layer; it is not
  permission to make every change listed on the internet.

    Evidence                  Likely layer       First decisive check               What the result means

    Tool can execute          Unbounded          Try allowlist bypass, traversal,   Require structural validation, sandbox,
    arbitrary                 authority          redirects, and argument            allowlists, and separate narrow operations.
    command/path/URL                             injection

    Tool reads untrusted      Injection chain    Place hostile instructions in      Model must not turn data into authority; add
    content then can act                         retrieved data                     policy gate and confirmation.

    One credential            Blast radius       Attempt cross-scope resource       Use per-user/tenant tokens and server-side
    reaches many                                 identifiers                        ownership checks.
    tenants/resources

    Tool output/log           Secret leak        Canary-secret and redaction        Redact at source and response/logger
    contains credentials                         test                               boundaries; rotate exposed secrets.

    Timeout leaves            Ambiguous side     Cancel/retry same operation        Need durable idempotency and reconciliation
    unknown state             effect                                                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.

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.

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.

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.

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.

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.

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

Starting Problem:

A browser tool can visit any URL and an email tool can send messages without confirmation.

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.

Proof Of Completion:

Injected content cannot authorize email; sensitive pages are unreachable from the public browser profile; sends require bound approval; caps and kill switch pass.

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 Add a narrow explicit rule; do not weaken the incomplete. whole boundary.

Agent bypasses approval by Limits are per call rather than per Aggregate by user, task, destination, and time splitting logical job/window. window.

Secrets appear only in errors Exception or upstream body bypasses Redact centrally before serialization/logging normal redaction. and test failures.

Tool update adds permission Update channel lacks change review Pin version and require a new preflight for or permission pinning. 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

• https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
• https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices