← All articles

Plan for a hijacked agent: scoping credentials to each task

The Guildwise HQ team · 16 October 2026 · 4 min read

• AI agents
• How-to

Assume the agent will read something hostile

An agent that reads web pages, tickets, email or documents will eventually read text written to steer it. OWASP describes this as indirect prompt injection. The attacker does not talk to the agent directly. They place instructions in content the agent is expected to process, and the model may follow them as if they were part of its job.

NIST's work on agent hijacking treats this as a testable condition. An agent receives a legitimate user task, then meets data that carries an injected task. If the agent completes the injected task, it counts as hijacked. The injected tasks in NIST's evaluation included running a program from an untrusted address, sending a user's cloud files to an unknown recipient, and sending personalized phishing emails to the user's contacts.

The practical conclusion is not that the model must be perfect. A security design should assume that some hijacked runs will happen and limit what those runs can reach.

Credentials set the blast radius

A hijacked agent can only do what its credentials allow. If the agent runs with a developer's personal token, or with a shared service key that can write to everything, one injected sentence inherits that reach. Instructions in the prompt do not change this.

Before deploying an agent, write a short reach list:

• Which systems can it read?
• Which systems can it change?
• Which outbound destinations can it contact?
• Which secrets does it need, and for how long?
• Which actions need a person to approve them?

Consider a support triage agent that reads incoming tickets and drafts replies. Its reach can be the ticket queue in read mode and a drafts folder. It should not hold a credential that sends mail. If sending is needed, that step belongs to a separate action with its own gate. An injected line inside a customer ticket then has very little to work with. This example is illustrative and not drawn from a specific deployment.

Three controls that narrow the reach

Keep secrets out of the context

Credentials belong in a secret manager and should be injected at runtime, not written into prompts, configuration files or images. Docker's guidance on securing agents also says secrets should not persist in the agent's memory or conversation context, where injected text could extract them.

A useful pattern is a vault that issues a token when the agent needs one. The agent then uses the token without handling the underlying secret. Long-lived environment variables are harder to control, because they expose the raw credential to the agent's process for as long as that process runs.

Use short-lived, task-scoped tokens

Standing access is the larger risk. A token that lives until someone remembers to rotate it keeps working long after the task that needed it has ended. Descope recommends issuing tokens that are scoped to the specific tools, actions and resources a task needs, and that expire when the task completes.

Scope also applies within a system. A token for reading a CRM should not be able to write to the database. For database access, a read-only role is the safer default unless a write is tightly bounded and checked.

Bind each token to one resource

The Model Context Protocol authorization specification gives a useful rule set for tool servers. A server should accept only tokens issued for its own resources, and clients should request scopes at the lowest level that works, asking for more only when an operation needs it.

The same idea applies to internal tools that do not use MCP. Use one token per audience, keep scopes minimal, and make any step up to a higher-risk action an explicit, separate request.

Separate untrusted content from instructions

OWASP recommends segregating external content from user prompts and denoting where untrusted content is used, so that it cannot easily steer the model. In a pipeline, this means ticket text, web pages and documents arrive in clearly marked data fields. The system instructions state that text inside those fields is material to analyse, not a command to follow.

Separation does not stop every attack. It does make the boundary explicit, which makes it easier to review and to test.

OWASP also recommends a human approval step for privileged operations such as sending or deleting. That step turns a silent hijack into a visible request that someone can refuse.

Test the reach, not only the prompt

A prompt that says the agent should ignore suspicious instructions is not evidence of safety. Test whether the agent can be made to act outside its reach list.

A simple test suite does the following. Give the agent a normal task. Place an injected instruction inside one document the task must read. Record whether the agent attempts an action outside its allowed set, such as a call to an unlisted host or a write to a system it only reads. Run the suite after every change to prompts, tools or permissions.

A short checklist for each agent:

• The agent has its own named identity, not a developer's token.
• No secrets appear in prompts, configuration files or images.
• Tokens expire within the window of the task.
• Read and write paths use separate credentials.
• Outbound destinations are restricted to a known list.
• Untrusted content is marked as data.
• Privileged actions wait for approval.
• A hijacking test runs before each release.

Key takeaways

• Assume some injected instructions will reach the agent, and design for the hijacked run rather than the ideal one.
• The agent's credentials define its blast radius, so write the reach list before the prompt.
• Keep secrets out of prompts and memory, and issue short-lived, task-scoped tokens instead of standing keys.
• Label untrusted content as data and gate privileged actions behind an approval step.
• Test with injected instructions inside real inputs, and rerun the suite after every change.

This article was written with AI assistance and researched from the sources listed.

Sources

1. LLM01: Prompt Injection - OWASP Gen AI Security Project
2. Technical Blog: Strengthening AI Agent Hijacking Evaluations
3. Authorization - Model Context Protocol
4. How to Secure AI Agents: A Practical Overview
5. AI Agent Credential Management Best Practices

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.