AI agents at work: the new attack surface nobody is watching

That is a huge time saver, and it is why companies adopt them. But it also creates something new: software that holds accounts, permissions and access to data like an employee, without an employee's common sense or accountability. For an attacker, that is a new kind of target.

The difference between a chatbot and an agent

A plain chatbot is about as dangerous as the text you feed it: the worst it can do is give you a bad answer. An agent is different. To do its job, an agent receives:

• Access: a mailbox, shared folders, a calendar, sometimes business applications
• Permissions: the right to send, change, delete, execute
• Trust: it works unsupervised, because the whole point is that you do not have to watch

When something with that combination of access and trust makes a mistake, or gets tricked, the consequence is not a bad answer. It is a real action in a real system.

How you attack software that follows instructions

A classic attack targets a flaw in code. With AI agents there is a second, stranger path: attacking through the content the agent reads. An agent cannot reliably tell your instructions apart from instructions hidden inside an email, a document or a message it is processing. If a message arrives carrying hidden instructions, the agent may follow them as if they were yours. The industry calls this prompt injection, and it is currently the most serious unsolved problem of this technology.

This is not theory. Security researchers this year documented vulnerabilities in a popular personal AI assistant where a carefully crafted WhatsApp message could lead to credential theft and code execution on the owner's machine. The vendor has since patched the flaws, but the principle stands: an agent with system access is a target, and the attack channel is ordinary content someone sends it.

The other side of the same story: researchers testing the latest large models keep showing they are increasingly capable as a tool in an attacker's hands too, from writing convincing phishing messages to helping find vulnerabilities. The offensive side is automating as well.

Where companies go wrong when adopting agents

The pattern we see is always the same, and it is speed rather than malice:

• The agent gets broader permissions than it needs, because that way it "just works"
• The agent's credentials sit unchanged forever, nobody rotates them and nobody knows everywhere they are stored
• The agent is connected to the whole company's mail and files instead of one restricted account
• Nobody keeps a record of what the agent has done, so a mistake or abuse can be neither noticed nor reconstructed
• When the employee who set the agent up leaves, the agent keeps running, with that person's access

Every one of these would be unacceptable for a new hire. For a software "hire", it passes without a question.

The rule that simplifies everything: an agent is an account

The most useful way to think about it is to treat every agent as a new team member, with all the procedures that implies:

• Its own identity: the agent has its own account and never borrows a person's. You can always tell what the agent did and what a human did.
• Least privilege: access only to what the specific job requires. A meeting scheduling agent does not need to read contracts.
• Human approval for sensitive actions: sending money, deleting data, changing accounts and access do not happen without a person signing off, however "confident" the agent is.
• An activity log: everything the agent does is recorded and reviewable. Without that you do not have an agent, you have a black box with permissions.
• Offboarding: when an agent is retired or replaced, its access is revoked the same day, like an employee leaving. Why leftover accounts cause damage is something we already covered in our article on offboarding.

What a small business should actually do

You do not need to understand the architecture of large language models to keep this under control. Three steps are enough. First, an inventory: which AI tools and agents exist in the company, who introduced them and what they can reach. Experience with Shadow AI says the list will be longer than you expect. Second, rules: which data may go to which tools, and which actions an agent may take alone versus with approval. Third, technical guardrails: accounts, permissions and logging set up so the rules do not depend on goodwill.

This is exactly what we do through our AI and automation service: automation delivers value only once it has guardrails, logging and clear ownership. An agent that saves ten hours a week while holding unlimited access and leaving no trace is not a saving. It is postponed damage. The difference between the two is not the technology, it is whether someone has built the system around it.