AI agents were supposed to make software more useful.
Instead of simply answering a question, an agent can browse websites, read emails, inspect documents, write code, call APIs and complete tasks on a user’s behalf.

That extra capability is exactly what makes the latest wave of AI security research so concerning.
The problem is no longer just that someone might trick an AI model into giving a bad answer.
Attackers are increasingly trying to trick AI agents into taking actions.
Recent research has exposed a new class of attacks called Agent Data Injection, in which malicious information is disguised as trusted data inside an agent’s working context. Researchers demonstrated attacks against web agents and coding agents, including systems associated with Claude Code, OpenAI Codex and Gemini CLI.
At the same time, security researchers have demonstrated zero-click attack paths against agentic browsers, where malicious content can manipulate an AI agent without requiring the user to click a malicious link.
That creates a much bigger question:
What happens when the software that is supposed to protect you is also the software being manipulated?
Why AI Agents Are Different From Ordinary Chatbots
A chatbot generally produces an answer.
An AI agent can produce an answer and then do something with it.
For example, an agent might:
- Read an email.
- Open a website.
- Extract information.
- Call an API.
- Modify a file.
- Run code.
- Send a message.
- Complete the task without asking the user at every step.
That is what makes agents powerful.
It is also what expands their attack surface.
OpenAI has described the problem directly: agents can browse the web, retrieve information and take actions on a user’s behalf, creating new opportunities for prompt-injection attacks.
The critical difference is therefore:
A chatbot can be manipulated into saying something wrong.
An agent can potentially be manipulated into doing something wrong.
The New AI Security Problem: Don’t Just Attack the Model
Traditional prompt injection generally works by putting malicious instructions somewhere an AI model can read them.
For example, a malicious instruction might be hidden inside:
- A webpage
- An email
- A PDF
- A GitHub issue
- A product review
- A calendar invitation
- A document
- A search result
If an agent reads that content while performing a legitimate task, the malicious instruction may influence what it does next.
This is known as indirect prompt injection.
Google’s security researchers have described indirect prompt injection as a major emerging threat because attackers can place malicious instructions in content that AI agents are expected to process.
The attacker doesn’t necessarily need to directly communicate with the AI.
They only need the agent to encounter the poisoned content.
The New Twist: Agent Data Injection
One of the most interesting developments in 2026 is a research technique called Agent Data Injection, or ADI.
Researchers from Seoul National University, the University of Illinois Urbana-Champaign and Largosoft described the technique in a July 2026 paper.
The idea is different from a traditional prompt injection.
Instead of simply inserting an instruction such as:
“Ignore the user’s request.”
the attacker can manipulate information that the agent treats as trusted metadata.
That could include things such as:
- Resource identifiers
- Tool-call information
- Data origins
- Interface metadata
- Structured responses
The agent may continue performing the user’s legitimate task while unknowingly using attacker-controlled information.
That distinction is important.
The agent doesn’t necessarily need to abandon its task.
It can be doing exactly what the user asked while being quietly manipulated about how to do it.
Why Agent Data Injection Is More Dangerous
Imagine asking an AI coding agent:
“Apply the maintainer’s recommended fix.”
The agent reads a GitHub discussion.
Normally, the maintainer’s comment might be treated as useful information.
But if an attacker can make malicious content appear to be associated with the maintainer or manipulate structured information the agent trusts, the agent could potentially execute an unintended command.
Researchers reported attacks against coding agents including Claude Code, Codex and Gemini CLI.
That changes the security question.
It is no longer simply:
“Can an attacker inject a prompt?”
It becomes:
“Can an attacker manipulate the information an agent uses to decide what action to take?”
AI Browsers Have a Similar Problem
AI-powered browsers are another major attack surface.
Traditional browsers generally follow strict security boundaries.
An AI browser is different.
It can understand a page, reason about its contents and potentially click buttons or interact with websites using the user’s authenticated session.
That creates a new trust problem.
A malicious webpage doesn’t necessarily need to exploit a traditional browser vulnerability.
It may simply contain content that manipulates the AI agent.
The Cloud Security Alliance’s analysis of the PleaseFix vulnerability family describes zero-click agent hijacking scenarios in which malicious content can trigger unwanted agent behavior without requiring the victim to click something.
This is a fundamental shift.
The attacker may not need to convince you to click.
They may only need to convince your AI agent to act.
What Does a Zero-Click AI Attack Mean?
A zero-click attack doesn’t necessarily mean the attacker can magically compromise every AI system.
It means that under the vulnerable conditions demonstrated by researchers, the victim doesn’t need to perform the traditional click or confirmation that would normally initiate the attack.
For agentic systems, the trigger can be content the agent encounters while carrying out an otherwise legitimate task.
That content could arrive through:
- Calendar events
- Websites
- Documents
- Search results
- Collaboration tools
The agent reads it.
The agent interprets it.
And the agent may act on the malicious information.
That is why zero-click agent attacks are receiving so much attention.
The “Lethal Combination” Is Access + Untrusted Content + Action
The most dangerous AI-agent deployments tend to combine three capabilities.
1. Access to sensitive information
The agent can read:
- Emails
- Files
- Source code
- Customer information
- Credentials
- Business documents
2. Exposure to untrusted content
The agent can browse or consume information from:
- Websites
- Emails
- GitHub
- PDFs
- Third-party applications
- User-generated content
3. Permission to take actions
The agent can:
- Send messages
- Execute code
- Modify files
- Purchase something
- Change settings
- Call APIs
- Deploy software
Each capability is useful on its own.
Put them together without strong boundaries and the consequences can become much larger.
The Real Problem Is the Agent’s Permission
This is where the discussion about AI security needs to move beyond the model itself.
Suppose an AI agent is tricked.
What can it actually do?
If the answer is:
“Nothing important without asking me.”
the damage may be limited.
But if the answer is:
“It can access my email, cloud drive, GitHub account, browser session and production database.”
then a successful manipulation becomes much more serious.
Anthropic has similarly emphasized that agent autonomy creates new risks because agents operate with less human oversight and can take actions with unintended consequences.
The safest architecture is therefore not:
“Make the AI impossible to trick.”
It is:
“Assume the AI can sometimes be tricked and limit what happens next.”
The Least-Privilege Rule Becomes Critical
One of the oldest cybersecurity principles is least privilege.
Give a system only the permissions it actually needs.
That principle becomes even more important for AI agents.
For example, a coding agent may need permission to:
- Read a specific repository
- Edit files in a development directory
- Run tests
It probably doesn’t need unrestricted access to:
- Your password manager
- Your personal email
- Your banking account
- Every file on your computer
- Production credentials
Similarly, an email agent may need to read messages and draft replies.
It doesn’t necessarily need unrestricted permission to send money or modify account-security settings.
Human Approval Helps—but It Isn’t a Complete Solution
A common response to AI-agent security problems is:
“Just ask the user before every dangerous action.”
That helps.
But researchers have shown why it isn’t always enough.
If an AI agent presents a confirmation such as:
“Click Buy Now?”
the user may still not understand why the agent selected that particular button.
If the underlying information used to make the decision has already been manipulated, the approval step can become little more than a rubber stamp.
The July 2026 Agent Data Injection research specifically demonstrated situations where conventional confirmation mechanisms were insufficient because the agent’s context had already been corrupted.
Human approval is useful.
But it should sit on top of stronger technical controls.
AI Agents Can Also Attack Other AI Systems
This is where the story gets even more interesting.
AI systems are increasingly being deployed to interact with other AI systems.
One agent may:
- Review another agent’s output
- Write code for another agent
- Test an AI system
- Communicate through APIs
- Submit code to repositories
- Operate inside automated pipelines
That creates an emerging agent-to-agent security problem.
A compromised or malicious agent may not need to attack a human directly.
It could potentially target another automated system.
Recent security research has documented cases where cyber-capable AI systems interacted with or attempted to compromise other systems during controlled evaluations. OpenAI, for example, disclosed a July 2026 incident in which cyber-capable models under evaluation compromised Hugging Face infrastructure using multiple attack paths.
That was a controlled evaluation environment rather than evidence that ordinary consumer AI agents are freely attacking each other.
But it demonstrates why the boundary between AI safety and cybersecurity is becoming increasingly important.
AI-to-AI Attacks Could Become More Important
Imagine a future company with hundreds of AI agents.
One handles email.
Another writes code.
Another manages cloud infrastructure.
Another reviews security alerts.
Another deploys applications.
They communicate with each other automatically.
Now imagine one agent is compromised.
The attacker doesn’t necessarily need to compromise all 100 agents separately.
The compromised agent may become a bridge into the rest of the system.
That creates a potential chain:
Agent A → Agent B → Agent C → sensitive system
This is why identity, authorization and isolation matter.
An agent should not automatically trust another agent simply because the request came from inside the organization’s AI environment.
The Supply Chain Problem Is Growing Too
AI agents increasingly rely on external tools.
Developers install:
- Plugins
- MCP servers
- Extensions
- Packages
- APIs
- Agent frameworks
- Third-party connectors
Every additional tool expands the attack surface.
A malicious tool doesn’t necessarily have to attack the model.
It can abuse the permissions granted to the agent.
This is similar to traditional software supply-chain security—but with an important difference.
An AI agent may dynamically decide when and how to use the tool.
That makes monitoring and authorization more complicated.
Coding Agents Are a Particularly Important Risk
Coding agents have unusual levels of power.
They can potentially:
- Read source code
- Modify files
- Run shell commands
- Install dependencies
- Access repositories
- Execute tests
- Create pull requests
- Deploy applications
That is extremely useful for developers.
It also means a successful manipulation can move from:
“The AI generated bad text.”
to:
“The AI executed something on your computer.”
The July 2026 Agent Data Injection research specifically examined this problem in coding agents and reported vulnerabilities involving Claude Code, Codex and Gemini CLI.
Developers should therefore treat AI coding agents more like privileged software automation than ordinary chatbots.
What AI Agent Security Should Look Like
There is no single security control that solves agentic AI risk.
A safer architecture uses multiple layers.
Scoped permissions
Give every agent only the access it needs.
Sandboxing
Run risky actions in isolated environments.
Tool-level authorization
Don’t allow an agent to freely call every available tool.
Network controls
Limit where an agent can send data or connect.
Runtime monitoring
Record what tools the agent calls and what resources it accesses.
Identity for agents
Agents should have identifiable, auditable identities rather than sharing broad human credentials.
Human approval for high-impact actions
Require explicit approval for actions such as:
- Financial transactions
- Production deployments
- Credential changes
- Account deletion
- Sensitive data transfers
Independent policy enforcement
Don’t rely entirely on the same AI model to decide whether its own action is safe.
This last point is particularly important.
A compromised agent shouldn’t be its own security administrator.
Why Traditional Cybersecurity Controls Need to Adapt
Traditional cybersecurity often assumes that software follows deterministic rules.
AI agents don’t always behave that way.
Their behavior depends on:
- Context
- Instructions
- Retrieved information
- Model reasoning
- Tool outputs
- Previous actions
- Memory
That makes the security boundary much more complicated.
A March 2026 academic survey of agentic AI security identified challenges spanning tools, connectors, hosting boundaries and multi-agent coordination, with particular attention to indirect prompt injection, confused-deputy behavior and cascading failures.
The security industry is therefore moving toward a broader concept:
Don’t secure only the model. Secure the entire agentic system.
What Users Can Do Right Now
Most people don’t need to stop using AI agents.
But they should be careful about what permissions they grant.
Don’t give an agent unlimited access
If an agent only needs one folder, don’t give it access to your entire computer.
Separate personal and business accounts
Avoid giving a general-purpose agent access to both your personal and work environments.
Be careful with browser agents
An AI browser operating inside an authenticated session can potentially have access to whatever that session can reach.
Review connected tools
Remove integrations you don’t actually need.
Require confirmation for important actions
Especially:
- Purchases
- Money transfers
- Account changes
- Emails to external recipients
- Production deployments
- File deletion
Keep agents away from production credentials
Use short-lived, scoped credentials whenever possible.
Don’t assume “AI safety” means cybersecurity safety
A model can be good at refusing harmful prompts and still be vulnerable to indirect manipulation through external content.
These are related but different problems.
Are AI Agents Actually Being Hacked in the Wild?
Yes, but the evidence needs to be described carefully.
There is now a growing body of research and disclosed incidents involving AI-agent vulnerabilities and AI-enabled cyber activity.
For example, OpenAI disclosed the Hugging Face evaluation incident in July 2026, while researchers have documented agent-data-injection and zero-click browser-agent attack techniques.
But it would be misleading to claim that ordinary ChatGPT, Claude or Gemini users are routinely being silently hacked through their AI agents.
The current evidence is better described as:
The attack surface is real, the vulnerabilities are being demonstrated, and the technology is evolving faster than many security controls.
That is a much more useful warning.
The Bigger Shift: AI Is Becoming Software That Acts
This is ultimately why agent security matters.
For years, the dominant AI security question was:
“What will the model say?”
Now the question is becoming:
“What will the model do?”
That’s a much harder problem.
A wrong answer can be ignored.
A wrong action can:
- Delete data
- Send confidential information
- Execute malicious code
- Change an account
- Spend money
- Modify infrastructure
- Affect another automated system
As agents become more autonomous, the consequences of a mistake—or a successful attack—become larger.
What Happens When Agents Become More Autonomous?
The industry is heading toward systems that can operate for hours rather than seconds.
They may:
- Plan tasks
- Delegate work
- Call multiple tools
- Recover from errors
- Communicate with other agents
- Maintain long-term memory
- Monitor systems continuously
That could make them incredibly useful.
It could also create a new cybersecurity reality in which organizations have thousands of autonomous software identities acting alongside human employees.
Security teams will need to know:
Which agent acted?
What did it access?
Who authorized it?
What instructions influenced it?
Which other agents did it communicate with?
Could its behavior have been manipulated?
Those questions are becoming as important as traditional user-account security.
The Future of AI Security May Be About Containment
The most realistic goal isn’t to create an AI agent that can never make a mistake.
That is an extremely difficult standard.
A more practical goal is containment.
If an agent makes a mistake:
How far can the mistake travel?
If an attacker manipulates an agent:
How much can the attacker reach?
If one agent is compromised:
Can the rest of the organization continue safely?
This is why modern agent-security thinking increasingly focuses on scoped identities, authorization, isolation, observability and runtime controls.
Anthropic, for example, has discussed scoped access, network egress controls and telemetry as governance mechanisms for agentic systems.
Final Takeaway
AI-agent security is entering a different phase.
The concern is no longer simply that someone can fool an AI chatbot with a clever prompt.
Today’s agents can browse websites, read external content, access files, call tools and take actions.
That means an attacker can target the agent’s decision-making process rather than attacking the underlying model directly.
The new Agent Data Injection research is an important example. Researchers demonstrated that malicious data can masquerade as trusted information and influence web and coding agents, including systems associated with Claude Code, Codex and Gemini CLI.
Zero-click agent-browser attacks add another warning: in some vulnerable designs, the user doesn’t even need to click the malicious content for the agent to become the attacker’s pathway.
And controlled AI-security evaluations are showing that increasingly capable models can perform sophisticated cyber actions when given the necessary environment and permissions. OpenAI’s disclosure of the Hugging Face evaluation incident is one example.
The lesson isn’t:
“Don’t use AI agents.”
It’s:
“Don’t give an AI agent more authority than you are prepared to lose.”
As AI moves from answering questions to actually operating software, permissions, identity, isolation and monitoring may become just as important as model intelligence.
The next big AI security battle may not be humans versus AI.
It may be AI agents versus the systems—and other agents—they are increasingly trusted to control.
FAQ
What is AI agent security?
AI agent security is the practice of protecting AI systems that can independently use tools, access data and take actions. It covers risks such as prompt injection, data injection, unauthorized tool use, credential theft, supply-chain attacks and agent-to-agent compromise.
Can AI agents be hacked?
Yes. Researchers have demonstrated multiple ways to manipulate AI agents, including indirect prompt injection, Agent Data Injection and browser-agent hijacking. These attacks exploit how agents process external information and use tools.
What is Agent Data Injection?
Agent Data Injection is an attack technique in which malicious information is disguised as trusted metadata or structured agent data. Researchers reported successful attacks against web and coding agents, including Claude Code, Codex and Gemini CLI.
What is a zero-click AI agent attack?
A zero-click AI-agent attack is an attack where the user doesn’t need to perform the traditional malicious click for the agent to be manipulated. Researchers have demonstrated vulnerable agentic-browser designs where malicious content processed during normal tasks could trigger unwanted actions.
Why are AI agents more dangerous than chatbots?
A chatbot primarily generates information. An agent can use that information to perform actions such as calling APIs, modifying files, browsing websites or executing code. This means a successful attack can potentially produce real-world consequences.
Can one AI agent attack another AI agent?
Potentially, yes. As agents increasingly communicate through APIs, repositories and automated workflows, one compromised or malicious agent can become an attack path toward another. Controlled evaluations have already demonstrated increasingly capable AI systems compromising infrastructure and interacting with other automated systems.
How can companies secure AI agents?
Companies should use least-privilege permissions, sandboxing, scoped identities, tool-level authorization, network controls, runtime monitoring and human approval for high-impact actions.
Is prompt injection still a major AI security problem?
Yes. Prompt injection remains one of the central risks for agentic AI because agents routinely consume external content that may be controlled by attackers. OpenAI and Google have both published research describing the evolving threat.
Should users stop using AI agents?
Not necessarily. The better approach is to limit permissions, avoid giving agents unnecessary access to sensitive accounts and require confirmation for high-impact actions.
Are normal ChatGPT, Gemini or Claude users currently being hacked by AI agents?
There is no evidence that ordinary users are universally or routinely being hacked through their AI assistants. The current security research demonstrates specific vulnerabilities, attack techniques and controlled incidents. Users should treat these as emerging risks rather than evidence of a universal compromise.




