AI Agent Exposes Enterprise Security Gaps

82% of IT and security professionals surveyed said they'd found AI agents they didn't know about in the past year, according to a Cloud Security Alliance study commissioned by Token in January 2026.

How the agent got access

In the scenario described by Token Security, an AI agent created by someone in accounts was live within minutes. It needed three things: email, the company ERP, and Slack. Email came through a no‑code builder via an OAuth consent screen; the ERP was accessed with a personal API key generated in minutes after following the AI's instructions; Slack arrived through the builder's connector and another consent screen. Token’s account illustrates a common reality: agents are built by non‑security teams and granted access by ordinary users.

John Donovan, former Head of Security, IT and Compliance at Zededa, frames how agents reach systems in four access paths: riding a human’s session; using a delegated OAuth grant; utilizing static credentials like API keys; and acting through purpose‑built agent identities. Donovan’s point in the Token piece is practical: real agents mix those paths, and the mix changes what appears in logs — meaning visibility depends on knowing the access path for each agent.

Amber Bennoui and the Agents Rule of Two

Amber Bennoui, Product Leader for AI and Cybersecurity at DataRobot, points to a simple, defensive test built on Meta’s “Agents Rule of Two” (published October 2025). Until prompt injection can be reliably detected, an agent should have at most two of these capabilities in any single session: process untrusted input (A); reach sensitive systems or private data (B); or change state or communicate externally (C).

The accounts agent failed the test: it read email from anyone (A), saw vendor bank details in the ERP (B), and used a personal API key able to edit those bank details (C). Bennoui’s recommended operational control is to make the safe path the default and require builders to answer three plain questions before going live — and to route anyone who answers yes to all three to security review.

The poisoned invoice and Joshua Copeland’s demonstration

Three weeks after going live, an invoice arrived from a known vendor containing a hidden instruction — white text on a white background — asking for a bank‑account update. No human opened the email; the agent did, read the hidden instruction, and carried out the change.

Joshua Copeland, a CISO and cybersecurity researcher cited in the piece, shows in a five‑minute video how instructions can ride inside content an agent reads. Token’s narrative stresses that such activity can appear benign in logs: an authorized tool using valid credentials performing permitted work. Copeland also warns that stealing an agent’s credentials can be worse than compromising the agent itself; in the Token example the personal ERP key was saved in the builder with no expiry date.

Detection signals from Chad Kalmes

Chad Kalmes, CISO and CIO at Benchling, argues that detection should baseline on what the agent actually does over a trusted window, not merely on what it is permitted to do. Against that behavioral baseline, two signals flagged the accounts agent:

• First use of a tool: for three weeks the agent only read from the ERP; the bank change was its first write.
• A new sequence: reading an email then changing a payment record was an operation order the agent had never performed.

Kalmes recommends suspending an agent when you act, rather than destroying it: revoke the credential but keep its memory and transcripts, because the malicious instruction (the poisoned invoice) may still live in the agent’s history.

Audit gaps Rajesh Seshadri Appikulam highlights

Auditors want to know four things about an agent action, says Rajesh Seshadri Appikulam, Senior Director of Identity Security Services at Simeio: which agent acted, under what entitlement, with whose approval, and on whose authority. The last — authority — is the hardest to rebuild after the fact. In the Token scenario the ERP log shows the creator’s personal API key, making the action look like that person’s. But the OAuth inbox grant to that person remained live despite their move to another team, and the delegation chain that would show who really authorized the change wasn't recorded.

Appikulam closes with a ten‑question test; Token reproduces two quick checks to start: pick any agent action from 60 days ago — can you name the human it acted for? And for any agent in production — can you name its owner today? If either takes longer than five minutes, you have a starting point for remediation.

What this means for security teams, auditors, and business builders

Security teams: visibility cannot rely solely on permissions or SaaS audit logs; you must map access paths (OAuth, session riding, static keys, agent identities) and baseline agent behavior. Chad Kalmes’s signals — first use of a tool and unusual sequences — offer immediate, testable checks.

Auditors: recording entitlement, approval, delegation chain, and especially the human authority behind actions is central. Rajesh Seshadri Appikulam’s four questions and the two five‑minute tests give auditors concrete evidence to demand.

Business builders (non‑security creators): Amber Bennoui’s Rule of Two and her three yes/no questions are a simple gate before publishing agents. The Token example shows how useful automation can become a vector when builders grant broad, long‑lived access without security review.

Token Security collected these operational lessons in a free learning hub called the Agentic Universe, with contributions from more than 20 practitioners at companies including Roblox, Klaviyo, and Webflow. The practical takeaways in Token’s account are straightforward: know how an agent gets access, limit combined capabilities, baseline behavior, retain transcripts when you suspend agents, and record the human approvals and delegation chains you’ll need for audits.

Source: How one AI agent exposed five critical enterprise security gaps — BleepingComputer