How should security teams design agent controls to reduce prompt injection risk across tool calls and browser actions?

Why This Matters for Security Teams

Agent controls are not just about preventing a bad prompt from producing a bad reply. Once an AI agent can call tools, open browser pages, query internal systems, or submit actions on a user’s behalf, prompt injection becomes an execution-risk problem. The attacker is no longer only trying to influence text generation; they are trying to steer decision-making, expand tool use, or cause a privileged side effect.

That is why current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward layered controls, explicit oversight, and continuous validation rather than a single prompt filter. Security teams need to assume that web content, retrieved documents, and even internal workflow data may contain adversarial instructions.

In practice, many security teams encounter agent abuse only after a browser action, file transfer, or API mutation has already occurred, rather than through intentional testing of those paths.

How It Works in Practice

Effective agent design starts by separating the model’s language ability from its authority to act. The agent should not receive broad standing access to tools, sessions, or credentials. Instead, each tool call should be mediated by policy that checks the task, the destination, the data being handled, and whether the action is reversible. For browser automation, that means restricting navigation to approved domains, stripping ambient cookies where possible, and blocking page content from silently changing the agent’s plan.

Security teams should also classify actions by impact. Reading a public webpage is different from submitting a form, sending email, approving a payment, or exporting records. High-impact actions need explicit human approval or a separate policy engine, especially when the agent is processing untrusted content. The more the workflow resembles an operator action, the less it should depend on free-form model interpretation.

A practical control stack usually includes:

• Tool allowlisting with per-task scope and short-lived credentials.
• Content sanitisation for web pages, emails, tickets, and retrieved documents.
• Policy checks on each call, not only at session start.
• Step-up approval for destructive, external, or irreversible actions.
• Logging that captures prompt, retrieved content, tool output, and final action.

Threat modelling should include prompt injection across the full chain: user input, retrieval, browser content, hidden text, and tool output. The MITRE ATLAS adversarial AI threat matrix is useful for mapping adversarial techniques to detection and response, while NIST control thinking helps teams translate those scenarios into enforceable policy. These controls tend to break down when agents inherit long-lived browser sessions or broad internal API scopes because injected instructions can ride along with legitimate workflow context.

Common Variations and Edge Cases

Tighter agent controls often increase friction, latency, and operational overhead, requiring organisations to balance automation speed against the cost of more approvals and stricter scoping.

There is no universal standard for how much autonomy is safe, because the right answer depends on the action’s impact, the trustworthiness of the input, and whether the environment is internet-facing or internal. For low-risk summarisation, lighter controls may be acceptable. For browser-based workflows that can send messages, change records, or move data, best practice is evolving toward explicit action gating and domain-aware policy.

One recurring edge case is “trusted retrieval” that is not actually trustworthy. Search results, shared documents, and internal knowledge bases can all contain hostile instructions if the source is weak or polluted. Another is multi-step agent chaining, where a harmless first tool call produces a state change that later becomes the basis for a high-impact action. Organisations also need to think carefully about AI-to-AI or agent-to-agent handoffs, because policy gaps often appear at the boundary between systems.

For governance, the practical question is not whether the model can ignore an injected instruction in the abstract. It is whether the control stack can prevent the instruction from becoming a tool call, a browser action, or a credentialed side effect when the content path is adversarial.

Related resources from NHI Mgmt Group

• How should security teams reduce indirect prompt injection risk in AI systems?
• How should security teams reduce prompt injection risk in AI agents?
• How should security teams use browser controls to reduce account takeover risk?
• How should security teams control browser prompt injection risk in LLM tools?