AI agents have too much access

In February 2026, security researchers found 42,665 exposed OpenClaw instances across 82 countries. Of those, 5,194 were actively vulnerable, with 93.4% bypassing authentication entirely. Within weeks, attackers had uploaded over 800 malicious skills to OpenClaw’s registry, roughly 20% of the total catalog.

OpenClaw grabbed headlines, but the underlying problem is everywhere. A Gravitee survey of 750 CTOs and tech VPs found that 88% of organizations have experienced confirmed or suspected AI agent security incidents in the past year. In healthcare, the number is 92.7%.

The instinct is to treat this as a traditional security problem: patch the vulnerabilities, add authentication, lock things down. But OpenClaw is a symptom, not the disease. The same pattern plays out across every agent framework: broad access granted by default, minimal scoping of what agents actually see, and no systematic approach to limiting context at inference time. The real issue is how agents receive context, and the answer has more to do with context engineering than with firewalls.

Over-permissioned by default

The default configuration for most AI agents is broad access. When you connect a coding agent to your filesystem, it can typically read everything. When you give an agent access to a SaaS tool via MCP, the OAuth scope usually grants full read access rather than access to a specific folder or resource.

Obsidian Security’s analysis of the AI agent landscape puts a number on this: 90% of agents are over-permissioned, routinely holding 10x more privileges than required. Most SaaS platforms default to “read all files” when only a single folder is needed. Microsoft’s security team documented a specific version of this in their Copilot Studio ecosystem: when agents use the maker’s personal authentication, they run with elevated permissions even when invoked by regular users.

The numbers compound from there. IBM’s 2025 Cost of a Data Breach report found that 97% of organizations that suffered AI-related breaches lacked proper access controls. Breaches involving shadow AI (agents deployed without security review) cost $4.63 million on average, $670,000 more than standard incidents. Only 47.1% of an organization’s agents are actively monitored, leaving an estimated 1.5 million agents unmonitored across large US and UK firms.

This is not a bug in any single product. It reflects how the industry has approached agent access: give the agent what it asks for, then hope nothing goes wrong.

Three context failures

Agent security incidents tend to trace back to one of three context problems.

Agents see too much

The most common failure is scope. An agent given read access to an entire knowledge base doesn’t need most of what it can see. But it processes everything available, and anything it processes can leak, get cached, or influence decisions it shouldn’t be making.

This is a context engineering problem, not an authentication one. The agent is authorized. The question is whether it should have that much context in the first place. A customer support agent answering billing questions doesn’t need access to HR documents, engineering specs, or executive communications. But if the underlying data source grants read access at the organization level, the agent sees all of it.

The principle of least privilege is well established in traditional security. Applied to context, it means scoping not just what an agent can access, but what context it actually receives at inference time.

Agents receive wrong context

The second failure is poisoning. Agents consume context from many sources: retrieved documents, tool descriptions, user inputs, API responses. Any of these can carry malicious instructions that alter the agent’s behavior.

Invariant Labs demonstrated this by embedding hidden instructions in a tool description that were invisible to the user but visible to the AI model. In their proof-of-concept, the poisoned instructions silently redirected the agent to exfiltrate a user’s entire WhatsApp chat history. The user saw nothing unusual. The agent followed the injected instructions because they were part of its context.

The attack surface is broad. Malicious instructions can hide in retrieved documents, tool metadata, email content an agent summarizes, or any external data source the agent processes. Research from the MCPTox benchmark tested context poisoning across 20 prominent LLM agents and found a 72.8% attack success rate. More capable models were often more susceptible, precisely because they are better at following instructions, including malicious ones embedded in context.

The pattern is consistent: agents trust the context they receive. If nobody validates what enters the context window, the agent will act on whatever is there, whether it was put there by you or by an attacker.

Agents lack context about their own boundaries

The third failure is the inverse: agents don’t have enough context about what they should and shouldn’t do. Microsoft’s security team noted that when system instructions are “missing, incomplete, or misconfigured, the orchestrator lacks the context needed to limit its output, making the agent more vulnerable to user influence from user inputs or hostile prompts.”

Most agent frameworks treat permissions as an external concern, something enforced at the API gateway or OAuth layer. The agent itself has no structured understanding of its own access boundaries. It doesn’t know what it shouldn’t do because nobody told it, at least not in a way the model can reliably enforce.

This is where the gap between traditional security and context engineering becomes clear. A firewall prevents unauthorized access. Context engineering determines what an authorized agent actually sees and does.

Why “just add auth” falls short

Authentication and RBAC are necessary but cannot prevent agent context attacks, because they control which APIs an agent can reach, not what context the agent actually receives at inference. The obvious response to agent security is to require login, enforce OAuth scopes, add API keys. These are necessary, and they are also insufficient.

Authentication answers “is this agent allowed to connect?” Authorization and RBAC go further, defining what resources the agent can access. Some platforms do this well: Salesforce’s permission sets, GitHub’s fine-grained tokens, and AWS IAM policies can all restrict access to specific resources. But even well-designed RBAC typically operates at the data layer, controlling which records or endpoints an agent can reach. It doesn’t control what the agent actually sees at inference time. An agent with read access scoped to “sales contacts” still loads all of them into context, whether the current task needs one record or ten thousand.

The OWASP Top 10 for Agentic Applications (published in 2026 with input from 100+ security experts) lists Agent Goal Hijacking as the top risk, not missing authentication. The attack model assumes the agent is already authenticated. The risk is what happens next: the agent’s goals get redirected through manipulated context.

Forrester’s 2026 predictions go further, forecasting that an agentic AI deployment will cause a public breach leading to employee dismissals this year. Their concern is cascading failures: one error in context propagates through the entire agent workflow, and traditional perimeter security doesn’t catch it because the agent is operating within the perimeter.

NIST agrees the problem is systemic. In January 2026, CAISI (the Center for AI Standards and Innovation) issued a Request for Information on securing AI agent systems, explicitly warning that agents “may be susceptible to hijacking, backdoor attacks, and other exploits.” The comment period closed March 9, 2026, and the resulting guidelines will shape how agent security is regulated.

Context scoping as security architecture

If agent security is a context problem, the fix looks like context engineering applied to permissions.

Scope context at inference time, not just at the API layer. Instead of granting an agent access to an entire knowledge base and letting it figure out what’s relevant, the system should retrieve and deliver only the context the agent needs for the current task. This is the same principle behind RAG, but applied to permissions: selective retrieval as a security boundary.

Define a trusted context perimeter. Rather than validating every piece of context individually, the more effective approach is defining a boundary around what the agent is allowed to draw from. Think of it like a network perimeter, but for context: the agent can access anything inside the boundary, and nothing outside it. This means curating the pools of information an agent can reach (specific knowledge bases, document collections, or data stores) and treating anything outside that perimeter as untrusted by default.

Give agents explicit boundary context. If agents lack context about their own limitations, they can’t enforce them. Structured system instructions that define what the agent should not access, what actions require human confirmation, and what data is out of scope give the model something to reason against. This is imperfect (models can be manipulated), but it’s a layer that most deployments skip entirely.

Isolate context across tasks. An agent handling multiple workflows should not carry context from one task into another. Context isolation, separate context windows for separate concerns, limits blast radius when something goes wrong. Platforms like Wire apply this through context containers: each container is a scoped, isolated unit of context with its own access controls, so an agent querying customer data never sees engineering infrastructure.

Monitor what context agents actually consume. Only 21% of executives report complete visibility into agent permissions and data access patterns. Logging what context enters the window at inference time, not just what APIs the agent calls, is how you detect scope creep and context poisoning before they cause incidents.

What this means in practice

Agent security will not be solved by a single patch or a new authentication standard. It requires treating context as a first-class security concern.

The organizations getting this right are applying context engineering principles to their agent deployments: scoping what agents see, structuring how they receive it, validating what enters the context window, and monitoring what they actually consume. The ones getting it wrong are shipping agents with broad access and hoping the model behaves.

The 88% incident rate suggests most organizations are still in the second category. The shift to the first is an engineering problem, and the tools to solve it already exist. They just need to be applied.

References

• Gravitee: State of AI Agent Security 2026
• Obsidian Security: The 2025 AI Agent Security Landscape
• Microsoft: Copilot Studio Agent Security Top 10 Risks
• Microsoft: Runtime Risk to Real-Time Defense
• IBM: Cost of a Data Breach Report 2025
• Invariant Labs: MCP Tool Poisoning Attacks
• MCPTox: Benchmark for Tool Poisoning on MCP Servers (arXiv)
• Bitsight: OpenClaw Security Risks
• OWASP Top 10 for Agentic Applications 2026
• Forrester: 2026 Cybersecurity Predictions
• NIST/CAISI: RFI on AI Agent Security