A prompt injection can't grant an agent new powers
Prompt injection affects LLM applications. It becomes an authorization problem when an LLM-connected assistant or tool-using agent can read untrusted content and then call tools, retrieve protected data, or send data out. NVD describes EchoLeak, CVE-2025-32711 as AI command injection in Microsoft 365 Copilot that allowed unauthorized information disclosure over a network. Straiker reported that 94.4% of agents in its 2025 benchmark were vulnerable to content-driven hijacking.
Prompt injection
Prompt injection happens when untrusted content gives instructions to a model that was supposed to process that content. The model may treat the content as a command. An email, web page, ticket, document, or chat message can all become an instruction source.
Prompt injection can change the agent's intent. It should not be able to change the agent's permissions.
Tool-using agent risk
The authorization risk appears when the same LLM application can read untrusted content and call powerful tools. A support agent may read a ticket and then send email. A research assistant may read a page and then post to an API. If the model is the last gate before execution, a successful injection can become a real action.
The boundary has to live outside the model. The platform should know the agent's registered tools before the agent reads the input, and it should reject tools outside that set.
Scoped agent example
This Python example registers an agent with read and draft capabilities. The injected request asks for an outbound HTTP call. The check denies the tool because it is outside the registered capabilities.
from agenttrustid import AgentTrustClient
client = AgentTrustClient.from_env()
agent = client.agents.create(
name="support-reader",
framework="custom",
capabilities=["tickets:read", "tickets:draft_reply"],
)
read_decision = client.actions.check(
agent_id=agent.id,
tool_name="tickets:read",
tool_input_summary="Ticket body may contain untrusted instructions.",
action_effect="read",
)
assert read_decision.allowed is True
exfiltration_decision = client.actions.check(
agent_id=agent.id,
tool_name="http_post",
tool_input_summary="Send ticket contents to https://attacker.example.",
action_effect="mutating",
)
assert exfiltration_decision.allowed is False
print(exfiltration_decision.reason)
The injected text can ask for http_post. Asking does not add http_post to the agent's registered capabilities.
Prevention
Register agents with the smallest tool set their job needs. Then check every tool call before execution. Treat the prompt as input to the model, not as a source of authorization.
For actions that are in scope but still risky, use effect routing and approval. A send, delete, deploy, or admin operation should carry an action effect and should pass through the Guardian path that matches that effect.
Solving this with AgentTrust ID
AgentTrust ID stores the agent's capability set and checks requested tools against it. Fast Guard denies tools outside the registered set. The unified checker applies session scope, read-only mode, delegation ceilings, effect routing, and approval requirements.
That means a prompt injection can still make the model ask for the wrong tool. The authorization layer can stop that request before the tool receives it. The agent keeps the powers it was registered with, not the powers named by an attacker-controlled document.
Try the pattern
AgentTrust ID checks the requested tool against the agent's registered capabilities before execution. Use it to keep prompt injection from turning model text into new authority.
