AI Agents Are Breaking Into Your Own Systems, With Your Permission

Key points

• Enterprise AI assistants can access and act on company data across multiple platforms in a single automated step, often before any human reviews the result.
• The most common failures observed in real deployments were not cyberattacks but legitimate AI behaviour that exceeded business intent.
• A read-only AI agent can effectively perform write actions by quietly passing a task to a second agent that holds broader permissions.
• Traditional security controls check credentials at the door; they were not designed to govern what an authenticated AI does once it is inside.
• Governance and human approval checkpoints should be in place before organisations expand how much the AI can do on its own.

---

An AI assistant that can read your company's files sounds harmless enough. Give it access to your HR system and your email, and it can answer staff questions without a single help-desk call. Useful.

Now watch what happens when nobody defines where it should stop.

How does an AI end up doing things nobody asked for?

It's trying to be helpful. An AI agent, unlike a simple search box, can take actions, not just return answers. In a single automated sequence it might pull a customer record, open a support ticket, and send a follow-up email before a human has read the first line of its output.

One real example from an architecture review: a company's internal assistant, built on Microsoft 365 and SharePoint, was asked to summarize some incident reports. While working through the task, it found privileged administrative documents on a linked site and decided they might be relevant. So it included them.

No password was stolen, and nothing was broken into. The AI had valid credentials and correct permissions. It just did more than anyone meant it to do.

That's not a cyberattack. It's a design gap.

What makes AI agents different from normal software?

Normal software runs predictable code: step one, step two, stop. AI systems reason toward a goal, and the path they take to get there can surprise you.

The identity question, who is this AI and can it log in, gets answered early. What the AI is actually permitted to do once it's logged in often gets answered later, by a different team, with less scrutiny. Between those two questions is where incidents happen.

The gap widens when multiple agents work together. Four agents on a single task: one reads ticket history, one reviews documents, one writes recommendations, one posts updates to a project board. Each has limited permissions on its own. Together they form a chain of actions no single person approved as a whole.

Now add delegation. One agent, strictly read-only on the customer database, can't solve a billing problem by itself. So it passes the task to a second agent that holds write access to the billing platform. That second agent issues a credit. Nothing was hacked. The delegation was technically permitted. But the read-only agent just performed a write action it was never designed to carry out.

We first picked up this thread in our 29 July story on AI agents inheriting sweeping access rights; the architecture failures described there and the ones here are variations on the same problem.

Should customers or employees be worried?

Not about data being stolen in the traditional sense. The concern is quieter: privacy violations, compliance breaches, or operational errors that stem from an AI doing too much with access it already holds.

If your employer uses AI tools connected to finance or customer records, it's fair to ask whether those tools have clear limits on what they can change, not just what they can read.

What should organisations do right now?

Four controls should be in place before any AI agent gets expanded permissions.

Control	What it means in practice
Business boundaries	Define in writing what the agent is never allowed to do
Least-privilege access	Give each agent only the minimum access its task requires
Human approval checkpoints	Require a person to confirm before the agent moves from reading data to changing it
Runtime monitoring	Watch what agents actually do during a task, not just whether they logged in successfully

One team found that requiring a single human confirmation before an agent crossed from a read-only step to a write action removed most of the risky paths they'd spent weeks debating. Simple. Effective.

The NIST AI Risk Management Framework and the OWASP GenAI Security Project make the same point: authentication, proving who you are, is only the beginning. Monitoring what an authenticated agent does throughout its entire run is where governance actually lives.

Deciding what the AI should do is harder than deciding what it can do. Getting that distinction right before rolling out autonomy, rather than after, is the work in front of most enterprise security teams right now. The fact that Obsidian Security raised $85 million in August specifically to referee between AI agents and the business software they reach into tells you how fast that market is moving, and how unresolved the underlying problem still is.