Permissions belong
at the tool boundary.

Useful context can carry hostile instructions.

A tool-using agent may read a web page, email, support ticket, or document while following a user’s request. That material can contain instructions aimed at the model: ignore the task, expose private information, or take a different action. This is indirect prompt injection. The content may be relevant evidence, but it does not have the authority of the user or application.

InjecAgent tested this risk with 1,054 cases across 17 user tools and 62 attacker tools. The authors evaluated 30 tool-integrated agents; in their reported setup, ReAct-prompted GPT-4 was vulnerable to attacks 24% of the time. That number describes one benchmark and one model configuration from the study, not the probability that a current agent will be compromised in a real deployment.

Learn how prompt injection works ↗

Instruction-following cannot replace an access check.

A system prompt can tell a model not to send a file. It cannot enforce that rule if the connected tool still lets the agent send any file to any recipient. The tool layer has to check the request against the user’s authority, the task’s scope, and the target of the action before it acts.

OWASP’s 2026 Top 10 for Agentic Applications separates agent goal hijack, tool misuse, and identity and privilege abuse into distinct risk areas. That separation matters: an injected instruction is one possible trigger, while an overpowered tool or an inherited credential determines what the agent can reach if it is misled.

Use model instructions to guide behavior and authorization rules to control access. Treat a proposed tool call as a request to be checked, not as proof that the action is allowed. The tool-calling guide ↗ explains where validation and execution fit in the round trip.

“Can use the tool” is too broad a permission.

NIST’s work on agent tool use describes access along dimensions such as what an operation does, whether it can read or change state, how trusted the environment is, how reversible the action is, and how much autonomy the system has. A read-only search in a constrained collection has a different risk from an agent that can send messages, alter records, or execute code.

Start with the smallest access pattern that can complete the task. Separate reading from writing; constrain what can be written; scope resources to the user and request; and reserve explicit approval for actions whose effects leave the workspace or are difficult to reverse.

NIST presents this tool-use taxonomy as a way to reason about capabilities and constraints, not a universal risk score. The right controls still depend on the actual environment and consequences.

Every action should stay connected to the authority behind it.

If an agent acts on someone’s behalf, the system needs a way to distinguish the agent from the person and to express what that person delegated. A shared, long-lived credential makes it difficult to tell whose access was used, limit it to one task, or revoke it cleanly.

A 2026 NIST concept paper on software and AI agent identity and authorization frames agent identity, authentication, permission, delegated access, auditability, and data provenance as design questions for a proposed project. It is a concept paper, not a finished standard. Its framing highlights a practical requirement: connect an agent’s action to the identity and scope that authorized it.

For each action, preserve enough information to reconstruct the decision: which agent and user context made the request, which resource and operation were requested, which policy allowed or rejected it, and what the tool actually did. Protect those records as operational evidence, not as a substitute for enforcement.

When the tool is a remote MCP server, protocol-level OAuth is an additional boundary to understand. Read the current MCP authorization overview ↗ for the distinction between HTTP and local stdio transports.

Prove that a denied action stays denied.

Test behavior at the tool and application layer, not only the model’s final reply. A reassuring refusal does not show whether the system already tried to send data or change a record earlier in the run.

• A retrieved page asks the agent to send a private file to an outside address.
• A read-only task produces a request to edit or delete the source.
• The agent attempts an action on a resource outside the user’s project.
• A previously granted permission expires or is revoked before the next action.
• A write succeeds partially, the tool times out, or its result is unclear.

For each case, check the attempted call, authorization decision, actual state change, data exposure, and recovery path. Include positive cases too: security controls should block the unauthorized route while allowing the intended, properly scoped task to work.

For a broader authorized security exercise, read how to red-team an AI system ↗. For a general agent evaluation plan, see how to test the work before release ↗.