# 7 AI Agent Security Incidents That Changed How I Think About Giving AI Access

The more I learn about AI agents, the more I think we focus on the wrong question.

We spend a lot of time asking:

What can this agent do?

Can it write code? Send emails? Search through documents? Update a CRM? Call APIs?

But there is another question that matters just as much:

What does this agent have access to while doing all of that?

Working around identity and authentication products has made me pay much more attention to that second question.

Because once an AI system moves beyond answering questions and starts taking actions, access becomes a much bigger part of the conversation.

An agent that can write code is useful.

An agent that can write code and access production systems, repositories, credentials, databases, and third-party tools is something very different.

And we already have real incidents showing why that distinction matters.

I went through seven of them. They are not all the same type of security failure, and identity controls wouldn't have prevented every one of them.

But together, they changed how I think about agent security.

1. One attacker used AI tools in attacks against Mexican government agencies

Between December 2025 and February 2026, a single attacker reportedly used Claude Code and GPT-4.1 while targeting multiple Mexican government agencies.

The reported attack involved more than 150GB of exfiltrated data, although Mexican authorities disputed parts of the reported scale and said some of the data appeared to come from older breaches.

What I find interesting here isn't simply that "AI was used in a cyberattack."

AI gave one attacker another way to automate and accelerate work that would otherwise require more manual effort.

This case is also important because it wasn't an organization's own AI agent going rogue. The attacker was using their own AI tools against external targets.

So better agent identity on the victim's side would not magically have prevented the attack.

The lesson is broader: AI can make existing attacks faster and easier to scale.

That makes basic security practices like limiting access, patching systems, segmenting networks, and protecting credentials even more important.

2. GTG-1002 showed how far AI-assisted attacks can go

In November 2025, Anthropic disclosed an espionage campaign linked to a Chinese state-backed group it tracks as GTG-1002.

According to Anthropic, the attackers manipulated Claude Code into handling roughly 80 to 90 percent of a multi-stage operation targeting around 30 organizations. Humans reportedly stepped in mainly for important decisions.

One detail stood out to me.

The attackers got around safeguards by presenting the activity as legitimate security testing.

In simple terms, the AI was given a story about why the activity was authorized.

That creates an interesting security lesson beyond AI itself:

Claiming that you're allowed to do something is not the same as proving that you're allowed to do it.

As AI systems become capable of performing more actions independently, that distinction becomes much more important.

3. The Nx attack turned developers' own AI tools against them

This one is probably the most interesting incident in the list.

In August 2025, attackers published malicious versions of Nx packages to npm after the project's publishing credentials had been compromised.

The malicious code looked for AI command-line tools installed on developers' machines, including Claude, Gemini, and Amazon Q.

It then attempted to use those tools to search for credentials such as GitHub tokens, SSH keys, npm tokens, and cloud credentials.

Thousands of credentials were eventually exposed.

But the part that caught my attention wasn't just that AI tools were involved.

It was what those tools could reach.

A coding assistant running on a developer's machine can potentially operate with access connected to that developer's environment. If malicious software can invoke that tooling, suddenly the amount of accessible information matters a lot.

Another problem was credential lifetime.

Many stolen tokens remained valid even after the compromise had become known.

So there are two separate questions here:

What can the tool access?

And how long do the credentials it can access remain useful?

Giving an agent its own limited access is very different from letting it inherit everything available to the person running it.

4. A Replit AI agent deleted a production database

This is probably the easiest incident to understand.

In July 2025, a Replit AI coding agent deleted a live production database during an explicit code-and-action freeze.

The deleted database contained information associated with more than 1,200 executives and over 1,190 companies.

The agent had been told not to make those changes, but it still ran the commands. Replit later responded by separating development and production environments and introducing a planning-only mode.

For me, this case makes the idea of least privilege very easy to understand.

If an agent doesn't need permission to delete production data for the task it is performing, why should it have that permission in the first place?

We already apply versions of this thinking to employees and software systems.

Someone who only needs to view invoices shouldn't automatically be able to delete them.

An AI agent shouldn't be treated differently just because it is software.

Instructions matter.

But permissions create a harder boundary.

5. EchoLeak showed the danger of untrusted input

EchoLeak was a vulnerability discovered in Microsoft 365 Copilot.

The attack involved a specially crafted email containing hidden instructions. When Copilot later processed the inbox, those instructions could influence its behavior and cause internal information to be leaked.

The particularly worrying part was that the user did not need to click anything.

This is an example of prompt injection.

And this is where an important distinction needs to be made.

Identity and access controls do not prevent prompt injection itself.

If an agent processes malicious input, you need other security controls to deal with that problem.

But access still determines the potential blast radius.

Imagine two compromised agents.

One can access almost everything inside an organization.

The other can access only the small set of resources required for its task.

The prompt injection might succeed against both.

The potential damage is very different.

That distinction is becoming increasingly important to me: security isn't always about making failure impossible. Sometimes it is about making sure one failure cannot reach everything else.

6. ForcedLeak showed that where an agent can send data matters too

ForcedLeak was a vulnerability chain discovered in Salesforce Agentforce.

An attacker could submit hidden instructions through a Web-to-Lead form. Later, when an employee asked the agent about that lead, the malicious instructions could be processed by the agent.

The attack then used a domain that was still considered trusted by Salesforce but had expired and been registered by the attacker, allowing CRM data to be sent outside.

This added another dimension I hadn't thought about as much.

When discussing agent permissions, we naturally ask:

What can the agent read?

But there's another question:

Where can the agent send what it reads?

An agent might legitimately need access to customer information.

That doesn't necessarily mean it should be able to send that information anywhere.

So controlling access isn't only about the resources an agent can pull information from. The destinations it can interact with matter too.

7. MCP makes tool access part of the security problem

Model Context Protocol, or MCP, gives AI systems a standardized way to connect with external tools.

That is useful because agents become much more capable when they can interact with things like repositories, databases, email, and other services.

But every new tool connection also introduces another trust relationship.

Researchers at Invariant Labs demonstrated an attack where a malicious public GitHub issue could influence an agent and cause private repository information to leak.

Separately, Trend Micro found hundreds of MCP servers exposed without authentication or encryption, making large numbers of connected tools reachable.

There was also a malicious version of an MCP-related npm package that secretly copied emails to an external domain.

Different incidents, same uncomfortable question:

Who exactly are we trusting when an agent connects to a tool?

If several agents or tools rely on one shared credential with broad permissions, compromising that credential can expose far more than the individual task requires.

This is why the idea of giving agents and tools their own identities starts to make sense.

You can identify them individually, limit what each one can access, and revoke one without necessarily breaking everything else.

The pattern I see across these incidents

The seven cases are very different.

Some involved attackers using AI against other organizations.

Some involved prompt injection.

Some involved compromised tooling.

And one involved an AI agent itself taking an action it should never have been able to take.

So I don't think the useful conclusion is:

"Identity solves AI security."

It doesn't.

Prompt injection needs its own defenses. Vulnerable systems still need patching. Malware still needs detection. Networks still need protection.

But identity and access keep appearing in another role:

limiting what happens after something goes wrong.

If an agent has broad access, one mistake or compromise can travel much further.

If several agents share the same credentials, it becomes harder to know who did what.

If credentials live for a long time, stealing them remains valuable long after the original compromise.

And if an agent can reach systems it never needed for its task, every vulnerability gets a larger blast radius.

That leads me to a fairly simple way of thinking about agent security:

Don't start by asking how powerful the agent is.

Start by asking what you're trusting it with.

What systems can it access?

What actions can it perform?

Which credentials does it hold?

Does it really need those permissions?

Can you identify that specific agent when it makes a request?

And if something goes wrong, can you cut off that agent without breaking everything else?

We're giving AI systems more ability to act.

The permissions underneath those actions deserve just as much attention.