How should security teams prevent prompt injection in AI agent workflows?

How should security teams structure AI agent workflows to resist prompt injection?

Security teams should treat the agent workflow as a trust boundary problem, not a text-filtering problem. The key design choice is to keep untrusted content from directly shaping control decisions, then require policy evaluation before any action with external side effects. That means the workflow must distinguish what the agent can read from what it is allowed to do.

Prompt injection becomes dangerous when the agent is allowed to treat retrieved text, tickets, emails, web pages, or logs as if they were instructions. In practice, that means the workflow needs clear separation between data ingestion, instruction handling, and action execution. If those layers blur together, the agent can be steered by attacker-controlled content even when the original user prompt looks harmless.

Good workflow design also makes authority explicit. A tool call should be blocked or downgraded unless the request is authorised for that context, that identity, and that destination. In other words, the agent should not inherit broad authority simply because it can reason about a task. The safest pattern is to grant the minimum capability needed for the current action, then re-evaluate before the next step.

Where does prompt injection usually enter the workflow?

Indirect prompt injection is the common failure mode because the malicious instruction arrives inside a trusted business object rather than in the user’s visible prompt. That object might be a support ticket, document, page fragment, spreadsheet cell, or web result. The agent then reads the content as evidence, but the injected text is actually trying to change the agent’s behaviour.

Trust breaks when the system lacks a content provenance model. If the workflow cannot tell whether a string came from a user, a retrieved document, a tool response, or an internal system instruction, it will eventually give attacker-controlled text too much influence. This is why prompt filtering alone is weak: it inspects text, but it does not preserve the security meaning of the source.

Security teams should also watch for prompt injection at tool boundaries. When an agent can search, summarise, send messages, update records, or invoke APIs, the attacker often aims to convert a single piece of poisoned content into a real action. AI Agent Authorisation Guide is useful here because the workflow needs per-action policy decisions, not blanket permission.

What controls work best before the agent acts?

The strongest controls are structural. Separate system instructions from retrieved content, label and preserve source provenance, and require the orchestrator to classify a proposed action before the model can execute it. A good design treats the model as a reasoner, not as the final authority on whether an action is safe.

Runtime policy checks are the practical choke point. Before a tool call is allowed, the system should confirm the current request, the destination, the data class, and the allowed side effects. That is where outbound communication, file writes, email sends, ticket updates, and API mutations should be screened. Zero Trust for AI Agents fits this model because each action should be verified rather than assumed safe.

Teams should also design for containment. If an agent is tricked once, the next question is whether the blast radius is limited to a single task or expands across systems, sessions, and connected tools. The workflow should therefore use narrow scopes, short-lived access, and explicit approval for high-impact actions. Agentic AI Security Guide is a useful broader reference for the layered controls around inputs, tools, orchestration, and identity.

Risk and Threat Considerations

Prompt injection is risky because it weaponises trust in ordinary content. The attacker does not need to break the model first; they only need the agent to process untrusted text as though it were an instruction or a policy signal. That creates exposure to data exfiltration, unauthorised tool use, and action hijacking across otherwise normal workflows.

Failure mechanism: the agent consumes attacker-controlled content from a trusted source, then lets that content influence tool selection, destination choice, or response generation before a policy gate can stop it.

Impact: the agent can leak secrets, send data to unapproved destinations, update records incorrectly, or perform actions the user never intended, especially when outbound actions are not independently validated.

Practitioner Guidance

What to verify: confirm that every agent action is evaluated against a policy decision point after retrieval and before execution. If the workflow cannot show where untrusted text stops and executable intent begins, the design is still too permissive.

Common mistake: teams often over-invest in prompt sanitisation and under-invest in action control. Filtering may reduce noise, but it does not stop an injected instruction from influencing a downstream tool call if the system still trusts the model’s interpretation.

What good looks like: the agent can read broad content, but it can only act through tightly scoped, observable, and reversible operations. High-impact actions require explicit confirmation or another independent check, and outbound destinations are monitored for abuse patterns.

Practitioner takeaway: build prompt injection defences around authority and execution control, not around text hygiene alone, because the real failure is letting untrusted content become a decision.

Related resources from NHI Mgmt Group

• Prompt Injection (Agentic)
• What steps should security teams take to prevent Shadow AI risks?
• How should security teams protect AI assistants from indirect prompt injection in email and document workflows?
• What breaks when permission scoping is the only defense against prompt injection in AI agent workflows?