How can organisations reduce risk from untrusted AI agent inputs?

Why This Matters for Security Teams

Untrusted AI agent inputs are dangerous because they do not need to be “malicious” in the classic sense to cause harm. A pasted prompt, an extension payload, a remote document, or a poisoned tool output can redirect an agent toward data disclosure, privilege misuse, or unsafe actions. The risk is not the model alone, but the agent’s ability to turn instructions into execution. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward containment, not trust, as the right control posture.

NHI Management Group research shows how fast this becomes operational: in the AI Agents: The New Attack Surface report, 80% of organisations said AI agents had already acted beyond intended scope, including unauthorized access and credential exposure. That is the core problem security teams must solve before the first agent is allowed to ingest external content or call privileged tools. In practice, many security teams encounter prompt injection only after an agent has already forwarded sensitive data or triggered an unsafe workflow, rather than through intentional testing.

How It Works in Practice

The practical control is to separate reading untrusted content from acting on it. An agent should not be able to directly convert any external input into a privileged action without a policy decision at runtime. That means constraining the tools it can reach, limiting the data it can see, and requiring explicit approval or policy evaluation before high-impact steps.

Security teams usually implement this as a layered workflow:

• Isolate external inputs such as email, web content, documents, and extension-fed context from the agent’s core instruction set.
• Classify input sources and treat remote or user-supplied content as untrusted by default.
• Apply request-time policy checks using policy-as-code or a control plane before tool invocation.
• Use short-lived, task-scoped credentials so a compromised instruction cannot be reused later.
• Log the exact input, tool call, and policy decision so the chain of action is auditable.

This approach aligns with the OWASP NHI Top 10 because the issue is often not identity theft alone, but identity misuse after the agent has been manipulated. It also matches the CSA MAESTRO agentic AI threat modeling framework, which treats agent behaviour, tool access, and trust boundaries as first-class risks. For implementation, the strongest patterns today use workload identity, ephemeral secrets, and real-time authorization rather than static allowlists and long-lived API keys.

These controls tend to break down when agents can chain multiple tools across loosely governed SaaS systems because the policy boundary no longer matches the actual path of execution.

Common Variations and Edge Cases

Tighter input containment often increases friction, requiring organisations to balance safety against workflow speed. Some teams need near-real-time agent responses, while others can tolerate human review for high-risk actions. Best practice is evolving here, and there is no universal standard for when to block automatically versus when to ask for approval.

One common edge case is retrieval-augmented generation. If the retrieval layer can fetch remote or user-controlled content, the agent may inherit malicious instructions hidden inside otherwise legitimate documents. Another is plugin or extension ecosystems, where instruction changes arrive through a trusted integration path and bypass the normal review process. A third is multi-agent systems, where one compromised agent can influence others through shared context or downstream tool outputs.

NHIMG research on LLMjacking and OWASP Agentic Applications Top 10 shows why static trust assumptions fail when attackers can pivot from input manipulation to credential abuse. For teams mapping this to broader governance, the NIST Cybersecurity Framework 2.0 supports this work by tying asset visibility, access control, and detection into one operating model. The practical takeaway is simple: if the agent can read it, it may try to act on it, so the safest default is to make every action earn its trust at runtime.

Related resources from NHI Mgmt Group

• When do AI agent credentials create more risk than they reduce?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does AI agent access create more risk than it reduces?
• When should organisations treat an AI agent as a privileged system?