Security teams should treat every external prompt, email, ticket, or chat message as untrusted input until it is validated against policy. The strongest control is runtime enforcement at the point of tool invocation, where the system can block risky actions before they reach CRM, email, or other sensitive tools.
Why This Matters for Security Teams
AI agents do not just “read” malicious input. They can turn a poisoned email, ticket, or chat message into action if the prompt is allowed to influence tool use, routing, or decision-making. That makes prompt injection, indirect prompt injection, and tool abuse operational risks, not just model-quality issues. Guidance from the OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework both point to the same reality: the control point has to be runtime, contextual, and policy-driven.
NHIMG research shows the confidence gap is already material: only 1.5 out of 10 organisations are highly confident in securing NHIs, even though agentic systems depend on those identities to reach downstream tools. When the agent is allowed to act on untrusted text, the attack path often becomes email to workflow, workflow to credentialed action, and action to data exposure. That is why the risk is less about whether the model “understands” the prompt and more about whether the system can stop a dangerous invocation before it leaves the agent. In practice, many security teams encounter abuse only after the agent has already executed a valid-looking but maliciously induced action, rather than through intentional testing.
How It Works in Practice
The practical answer is to separate interpretation from execution. The agent may inspect untrusted content, but the system must enforce policy again at the moment a tool, connector, or API call is about to happen. That means every action request is checked against the current context, the requested object, the user/session, and the agent’s allowed task scope. Current guidance suggests treating this as a zero-trust decision point, not as a one-time prompt filter.
A robust pattern uses layered controls:
- Normalize and classify all external input before it reaches the agent.
- Restrict tools by default, then grant only the minimum runtime capability needed for the task.
- Apply policy-as-code so risky actions can be blocked or downgraded at invocation time.
- Require human confirmation for high-impact actions such as sending email, moving funds, deleting records, or sharing secrets.
- Log both the triggering content and the exact policy decision for forensic review.
That runtime model aligns with the defensive direction described in the OWASP NHI Top 10 and NHIMG reporting on AI credential abuse, including the AI LLM hijack breach, where exposed identities and overly broad access made agent misuse far easier to operationalize. In environments with short-lived workload identities, tightly scoped tokens, and real-time policy checks, malicious input has far less room to convert into action. These controls tend to break down when agents are chained across multiple tools with shared credentials because a single untrusted instruction can propagate through the full workflow before any policy gate re-evaluates it.
Common Variations and Edge Cases
Tighter runtime control often increases friction, requiring organisations to balance safety against automation speed. That tradeoff is most visible in customer support, IT operations, and developer-assistant workflows, where agents legitimately need broad access some of the time but not all of the time. Best practice is evolving here, and there is no universal standard for how much autonomy should be delegated without a human checkpoint.
Two edge cases matter most. First, indirect prompt injection hidden inside retrieved documents, web pages, or support tickets can look harmless to a human reviewer but still influence the agent’s tool selection. Second, multi-agent systems may pass malicious intent downstream even if the first agent only summarises or triages content. The CSA MAESTRO agentic AI threat modeling framework is useful here because it pushes teams to model where trust boundaries actually exist, not where they are assumed to exist. For a broader threat lens, the MITRE ATLAS adversarial AI threat matrix helps map prompt injection and downstream abuse to concrete adversary behaviours.
Security teams should also watch for agent behaviour that changes after tool output is returned. A prompt that looks safe at ingestion can become dangerous once the agent receives fresh context from CRM, ticketing, or code repositories. In practice, the hard part is not detecting hostile language; it is preventing a normal-looking workflow from being steered into an unsafe action path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | LLM03 | Prompt injection and tool misuse are the core risk in this question. |
| CSA MAESTRO | TA-02 | Threat modelling should trace how malicious input reaches downstream actions. |
| NIST AI RMF | AI RMF governance applies to runtime controls for unsafe agent behaviour. |
Define governance, monitoring, and incident response for agent decisions in production.
Related resources from NHI Mgmt Group
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
