An AI agent built by someone in accounts at a mid-sized company can be enough to expose weak points across access, review, detection, and audit tracking. In this case, the agent was made to read email, match invoices against an ERP, and post a daily summary to Slack, and the security team did not know it existed.
How the agent got its access
The agent needed access to email, the ERP, and Slack. Email came through a no-code builder with an OAuth consent screen, the ERP through a personal API key created from the AI’s instructions, and Slack through the builder’s Slack connector and another consent screen.
John Donovan, former Head of Security, IT and Compliance at Zededa, lays out four access paths for AI agents. One is riding a human’s session through browser extensions and in-app copilots that act as the user. Another is a delegated OAuth grant that gives access after a single click and lasts until someone revokes it. A third is static credentials such as API keys and service account passwords that anyone who finds them can use. The fourth is purpose-built agent identities that are registered, short-lived, and tied to one agent, which he describes as the ideal and rarest setup.
He says real agents mix these paths, and that mixture changes what appears in logs. If an agent passes a user’s OAuth token to a sub-agent, which then calls an MCP server that queries a database with a shared service account, the database log shows the service account, the SaaS audit log shows the user, and the identity provider shows nothing. OAuth grants also deserve attention because they usually do not get revoked by the identity provider and can stay active long after the person who approved them changes jobs.
The review that never happened
The agent went live the next morning without a review because no one had been asked to review it. Amber Bennoui, Product Leader for AI and Cybersecurity at DataRobot, uses the Agents Rule of Two, which Meta’s AI security team published in October 2025, to show why that matters.
Until prompt injection can be reliably detected and refused, an agent should have no more than two of three traits in a single session: it processes untrusted input, it can reach sensitive systems or private data, and it can change state or communicate externally. This agent had all three. It read email from anyone who knew the address, saw vendor bank details in the ERP, and ran on a personal API key that could do anything its creator could do in the ERP, including editing those bank details.
Bennoui says the safe path should be the default, and builders should answer three questions before an agent is switched on: whether it reads anything from outside the company, whether it can see private data, and whether it can act without a person checking first. If the answer to all three is yes, security has to be involved before launch.
The malicious email no one opens
The Slack summaries worked, and the owner was satisfied. While they were thinking about what else could be automated, an invoice arrived from the address of a known vendor. Its attachment held a note in white text on a white background asking for an ERP update because the vendor had changed its bank.
Joshua Copeland, a CISO and cybersecurity researcher, shows in a five-minute video how instructions can reach an agent directly from whoever can talk to it or through the content it reads, including an email nobody opened. In both cases, the logs can look clean because the work uses an authorized tool, a valid credential, and permitted access.
Copeland also says stealing an agent’s credentials can be worse than compromising the agent itself. For this agent, the credential was the personal ERP key created on day one and stored in the builder with no expiry date. The source treats every input an agent reads as something that can issue orders to it, and it says no single input should be able to trigger an action that cannot be undone.
Catching the bank change
The bank change went through on a Thursday, and whether anyone noticed depended on what the detection logic compared the agent against. If the baseline is only the agent’s permissions, nothing alerts, because a misbehaving agent can stay within its grants.
Chad Kalmes, CISO and CIO at Benchling, bases detection on what the agent actually does over a trusted window, including the tools it calls and the places it sends data. Against that baseline, two signals fired here. The first was the first use of a tool, since the agent had only read from the ERP for three weeks and then made a write. The second was a new sequence, because reading an email and then changing a payment record was an order of operations the agent had never used before.
Kalmes draws a line between a compromised agent, which follows an attacker’s instructions, and a rogue one, which causes damage while following legitimate instructions. He says the signals mostly overlap. When action is taken, the agent should be suspended without being destroyed, the credential should be revoked, and its memory and transcripts should be kept because the poisoned invoice may still be there.
What the audit needed
Two months later, auditors pulled the bank change from the agent’s history and asked who approved it. Rajesh Seshadri Appikulam, Senior Director of Identity Security Services at Simeio, says an auditor asks four questions about an agent action: which agent did it, under what entitlement, with whose approval, and on whose authority.
The first question is easy, and the last one is hard because authority cannot be rebuilt later. If the human behind the request and the delegation chain were not recorded when the action happened, they are gone. In this case, the ERP log showed the creator’s personal API key, so the bank change appeared to be theirs. The response team revoked that key, but the agent owner had moved to another team the month before, and the OAuth grant to the inbox was still live.
Appikulam ends with a ten-question test that should take under five minutes each. The first asks whether you can name the human behind any agent action from 60 days ago. The second asks whether you can name the owner of any production agent today. If either takes longer than five minutes, that is where work should begin.
One agent out of hundreds
The agent is imaginary, but agents like it are not. The survey cited at the start found that 82% of 418 IT and security professionals had discovered agents they did not know about in the past year, even though 68% reported strong visibility into their AI agents. The fixes described above came from people who first met the problem in production and wrote down what worked.
More than 20 contributors, including security leaders at Roblox, Klaviyo, and Webflow, cover how agents work and how to respond when one goes wrong in the Agentic Universe. The material includes short videos and checklists that can be run against a local environment, and it is free and ungated.
Licensed under CC BY-ND 4.0 International