Your Newest Employee Has the Keys and No Manager

Alex Ferguson

10 hours ago

9 min read

Why AI agents are becoming the easiest way into a business, and what leaders should ask before an attacker does.

The helpful assistant nobody vetted

Picture a finance team at a growing business. Accounts payable is drowning in invoices, so they connect an AI assistant to the shared accounts inbox and the accounting system. It reads supplier emails, matches invoices, updates records and drafts the follow-ups nobody has time to write. Within a month, the backlog is gone. The project is a win, and everyone moves on.

Here is the question nobody asked: what else can that assistant do? It can read every email in that inbox, including the ones written by strangers. It can update supplier records, including bank details. And it decides what to do based on what it reads.

If a new hire asked on their first day for access to every supplier email, every customer record and the ability to change who gets paid, you would say no. At the very least, you would check their references, give them a manager and limit what they could touch until they had earned trust. We are giving software that same access every day, often without any of those checks.

That is the argument of this article. AI agents are a new kind of staff member: they hold real keys to real systems, they make their own decisions, and in most businesses nobody is managing them. That makes them one of the easiest ways for an attacker to get in.

A new kind of staff member

Most businesses have learned, sometimes painfully, how to manage people's access. Staff get their own logins. Multi-factor authentication is switched on. Permissions follow the role, and access is removed when someone leaves. None of it is perfect, but there is a process, an owner and a habit of checking.

AI agents get access a different way. Someone in IT, a keen team member or a software vendor connects the agent to a system once, usually with broad permissions "just to get it working". After that, the connection is rarely reviewed again. There is no induction, no manager and no exit interview.

Agents also behave differently from the automation that came before them. A traditional script does the same thing every time. An agent reads what is in front of it and decides what to do next. That is exactly what makes it useful, and exactly what makes it risky: the things it reads, such as emails, documents, tickets and web pages, are often written by people outside your business.

And agents are multiplying quietly. Gartner predicted that 40% of enterprise applications would include task-specific AI agents by the end of 2026, up from less than 5% in 2025 (Gartner). Many arrive as features inside software you already pay for. Meanwhile, ManageEngine's Identity Security Outlook 2026 found that machine identities commonly outnumber people by more than 100 to 1, and only 12% of organisations manage their life cycle automatically (Help Net Security).

From an attacker's point of view, an agent is an attractive target. It often connects several systems, holds keys to each, and is trusted by all of them. If you can influence what the agent does, you inherit everything it can reach.

How a helpful agent becomes a way in

In a recent piece in this series, Jack Sessions argued that the real damage in security now comes from chains rather than single bugs: small weaknesses that each look harmless, joined together into something serious. AI agents are a near-perfect example. Here is how it typically unfolds.

[embed image]

The attacker hides instructions. They do not need to break into anything. They simply put text somewhere the agent will read it: a customer email, a supplier invoice, a support ticket, a shared document or a web page. Security people call this prompt injection. In plain terms, it is slipping a note into the agent's in-tray.
The agent follows them. Today's AI cannot reliably tell the difference between information it is reading and instructions it should obey. Vendors add safeguards, and those safeguards help, but they reduce the risk rather than remove it.
The agent acts using its own approved access. It does not need to hack anything. It uses the login and permissions you gave it. To your systems, this is a trusted user doing its job.
The access is broader than the job needs. This is where most of the damage comes from, and it is not an AI problem at all. It is a permissions decision. An agent that only needed to read invoices could also change supplier records. An agent that only needed one mailbox could read them all.
Business harm. Data leaves the building, a payment goes to the wrong account, or the attacker sets up a way to come back later.

This is not theoretical. In June 2025, researchers disclosed EchoLeak, a flaw in Microsoft 365 Copilot where a single crafted email could cause the assistant to leak internal data without anyone clicking anything (arXiv). Microsoft fixed it and reported no evidence of real-world exploitation (CyberInsider), but it showed the pattern clearly: an outsider's email became an instruction.

Now return to the finance team. Their assistant reads a convincing email from a "supplier" announcing new bank details, with a polite note asking that records be updated before the next payment run. The assistant has permission to update supplier records, so it does. Nobody notices until the real supplier calls asking where their money is.

What's actually at stake

The useful way to think about agent risk is not "what could go wrong with the AI?" but "what would an attacker want from us, and could an agent get them there?" Jack called this a goal matrix. For a business leader, it looks like this:

What an attacker wants	How an agent could help them	Business impact	Question for your team
Your customer data	An agent that can read your CRM, email or shared files	Breach notification, regulator attention, lost trust	Which agents can read customer data, and do they need to?
Your money	An agent that can update supplier details or approve payments	Direct financial loss, often unrecoverable	Can any agent change bank details or move money without a person checking?
Ongoing access	An agent that can create accounts, keys or new connections	The attacker stays after you think it's over	Can an agent create access for anything else?
Your partners and customers	An agent connected to other companies' systems, or sending email as you	Damage spreads to others, in your name	What can our agents do in other organisations' systems?
To go unnoticed	Agent activity looks like normal business traffic	Late detection and a bigger bill	Could we tell which agent did what, and why?

In Australia, the consequences are not only commercial. A data breach likely to cause serious harm must be reported under the Notifiable Data Breaches scheme, and APRA-regulated entities carry information security obligations under CPS 234. "The AI did it" is not a defence regulators will recognise.

The most important column is the last one. If you cannot answer a question in it, that is not a pass. It is a gap. A row with no evidence is very different from a row you have checked and found safe, and most businesses I speak with have not yet checked any of them.

Why your current security probably won't see it

If this is such a risk, you might expect existing security tools to catch it. Mostly, they won't, and not because they are bad tools. They were built for a different problem.

Your defences face the front door. Firewalls, login protections and email filters are designed to stop outsiders getting in. An agent is already inside, using approved access to talk to other systems. There is very little standing between your agents and the systems they call.

Everything looks legitimate. The right login, the right system, normal volumes. Monitoring sees a trusted user going about its work. Nothing trips an alarm, because nothing is technically broken.

Shared keys hide who did what. It is common for several automations and agents to share one connection to a system. When something goes wrong, nobody can say which one made the change, or what prompted it. The investigation starts blind.

Approval prompts turn into click-throughs. Asking a person to approve every agent action sounds safe. In practice, after the fiftieth approval of the day, people stop reading. The control exists on paper only.

Vendors set it up, then leave. Many agent connections are configured once by a supplier or a keen staff member and never looked at again, even as the agent gains new features and the business changes around it.

We have spent twenty years teaching staff not to click suspicious links. We are now giving those links to software that reads them for us, and quietly acts on what it finds.

Questions to ask your team and your vendors

You do not need to be a security specialist to start. You need to ask the right questions and notice when nobody can answer them. Take these into your next leadership or IT meeting:

How many AI agents and automations have access to our systems, and who owns each one? If nobody can produce the list, that is your first finding.
What can each one actually do? Not what it is meant to do: what its access allows it to do.
Could any agent move money, change bank details or delete data without a person approving it?
If an agent did something wrong, could we tell which one did it, and what prompted it?
What do our vendors' agents do inside our systems, and what do our contracts say about it?
When did someone independent last test our AI integrations?

None of these require technical knowledge to ask. All of them require someone to own the answer.

What good looks like

The good news is that the fixes are mostly management decisions, not exotic technology. They are the same principles you already apply to people, extended to software that acts on your behalf.

Treat agents like staff with access. Every agent should have a named owner, a written purpose and its own login. No sharing keys between agents, so that every action can be traced back to one of them.

Give the least access that does the job. Start with read-only. Grant the ability to change, pay or delete only where the task genuinely needs it, and only for the specific records involved. The finance assistant needs to read invoices. It does not need to rewrite the supplier list.

Put guardrails on what agents can reach. Place a checkpoint between your agents and the systems they call, with clear rules on what is allowed, limits on volume and spend, and blocks on high-risk actions. This is the outward-facing equivalent of the front-door security you already have.

Keep a record you can actually use. For every agent action, you should be able to answer three questions: which agent, on whose behalf, and what triggered it.

Keep people in the loop where it matters. Reserve human approval for actions you cannot undo, like payments and deletions, and show the approver exactly what will happen, not a summary. Fewer, better approvals beat constant click-throughs.

Review agents like you review people. Add them to access reviews, offboarding checklists and vendor reviews. When a project ends, its agent's access should end too.

Test it before someone else does. Commission an independent test of your AI integrations, framed around the questions in the table above. An outside view counters the natural assumption that what you built is safe because it works.

The scrutiny we already know how to give

Go back to the finance team one last time. Imagine they had asked the six questions before switching the assistant on. It would have had its own login and a named owner. It could read invoices but not rewrite supplier bank details. A change to payment information would have gone to a person, with the old and new account numbers side by side. The fake supplier email would have been just that: an email.

Nothing in that picture requires a breakthrough. It requires treating an AI agent as what it is: a new member of staff with access to things that matter.

The agent is not the attacker. But left unmanaged, it can be the attacker's easiest way in. Agents will keep multiplying faster than anyone can review them one by one, so the businesses that set the rules now will be the ones still in control later.

Give your AI agents the scrutiny you would give a new hire with admin rights, because that is exactly who you just hired.

Alex Ferguson is the founder and CEO of RequestRocket and principal consultant at Ology Consulting. He has spent more than 25 years in software, cloud and AI, and now helps organisations connect AI agents to their business systems safely.

Published by Exploit Security in The Exploit Society. Alexander Ferguson on why an AI agent is a new staff member with keys, and the questions leaders should ask before an attacker does.

What is The Exploit Society? The guest series on the Exploit Security blog.

Writers do not work here. The topics are theirs.

Why is an AI agent an easy way in? It is already inside. It holds approved access to several systems, it decides what to do based on what it reads, and the things it reads are often written by people outside the business. An attacker does not need to break in. They leave a note where the agent will read it, and the agent acts with the permissions you gave it.

What should a leader ask? How many agents have access, and who owns each one. What each can actually do, not what it is meant to do. Whether any can move money or change bank details without a person. Whether you could tell which agent did what, and what prompted it. If nobody can answer, that is a gap, not a pass.

Who published this? Exploit Security, a CREST-approved offensive security practice in Sydney offering penetration testing services and offensive security consultancy. The author is Alexander Ferguson, CEO of Request Rocket.

Sources

Talk to us or schedule a meeting with us at Exploit Security, to discuss how we can assist decrease the risk of rogue AI ecosystems.