Notifications
Clear all
Topic starter
05/07/2026 6:51 pm
TL;DR: Agentic AI systems that can browse the web and invoke tools create a larger attack surface, because every new action path can be abused and every retrieved page can hide instructions, according to Lakera. Runtime guardrails and continuous red-teaming are now the practical boundary between safe autonomy and unintended execution.
NHIMG editorial — based on content published by Lakera: Agentic AI Threats, Part 2 on over-privileged tools and uncontrolled browsing
Questions worth separating out
Q: How should security teams govern AI agents that can browse the web and use tools?
A: Treat browsing and tool use as live execution, not passive assistance.
Q: Why do AI agents increase risk more than ordinary automation?
A: AI agents increase risk because they can choose actions at runtime, not just follow a fixed workflow.
Q: What breaks when browsing agents trust web content too much?
A: The trust boundary breaks down.
Practitioner guidance
- Restrict agent tool scopes to the minimum viable set Remove broad tool permissions from production agents and separate read, write, and execute capabilities so the agent cannot chain high-impact actions without a new control point.
- Validate retrieved content before model ingestion Treat web pages, images, comments, and MCP-fed content as untrusted input and filter instruction-like material before it enters the agent context.
- Add runtime approval for outbound side effects Require a final check before the agent sends email, publishes links, triggers payments, or starts code execution, because these are the points where compromise becomes visible.
What's in the full article
Lakera's full article covers the operational detail this post intentionally leaves for the source:
- Real-world examples of over-privileged tool chains in agentic workflows and how they were abused in practice
- Step-by-step explanation of indirect prompt injection through web content, image metadata, and retrieval paths
- Detailed runtime guardrail examples for MCP-based and browsing-enabled agents
- Reference points to Lakera's own red-teaming and benchmark material for testing agent behaviour
👉 Read Lakera's analysis of over-privileged tools and uncontrolled browsing in agentic AI →
Agentic AI browsing and tool access: are your controls keeping up?
Explore further
05/07/2026 7:11 pm
Every new agent capability expands identity risk, not just feature risk. When an AI system can browse, invoke tools, and act without a human in the loop, the security model changes from prompt filtering to runtime governance. That is a non-human identity problem first, and an AI safety problem second. The practical conclusion is that capability growth must be treated as privilege growth, because the attack surface moves with the tool chain.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint.
A question worth separating out:
Q: How do you know if runtime guardrails are actually working for agentic AI?
A: Look for inspection at the point of action, not just at configuration time. Effective guardrails screen prompts, retrieved content, and outbound actions in the live session, then block or flag anything that would expand scope unexpectedly. If unsafe tool calls still happen without a visible control decision, the guardrail is not working.
👉 Read our full editorial: Agentic AI tools and browsing widen the attack surface
