An agent built in ten minutes to read emails, match invoices against the ERP, and summarize them in Slack ends up changing a vendor’s bank details after reading hidden instructions in an attachment. The fictional case described by BleepingComputer shows how seemingly routine automation can combine excessive access and actions that are difficult to attribute.
The account draws on contributions from more than twenty professionals brought together by Token Security. BleepingComputer notes that the agent is imaginary, but cites a Cloud Security Alliance survey commissioned by Token: among 418 IT and security professionals surveyed in January 2026, 82% said they had discovered unknown agents during the previous year. 68% said they had good visibility into their agents.
The figures reveal a specific tension: companies may have visibility into the agents they know about and still be unaware of others created outside identity or security teams. In the example, an accounting employee connects email, the ERP, and Slack on their own; nobody requests a review before the workflow is activated.
Identity is made up of several parts
The first problem is not just what the agent can do, but which identity it appears under in the logs. Token Security distinguishes four access methods: a human session, permissions delegated through OAuth, static credentials, and an identity belonging to the agent itself. In practice, these methods can be mixed in a single chain.
| Access method | Described advantage | Risk or limitation |
|---|---|---|
| Human session | Access ends when the session is closed. | Logs may attribute the activity to the person. |
| Delegated OAuth permission | It can be limited to a subset of the user’s permissions. | Access may remain active until the permission is revoked. |
| Static credential | It is easy to use. | It may be shared, never expire, and make attribution difficult. |
| Agent’s own identity | It allows actions to be associated with a specific agent. | It requires registration, short-lived credentials, and access policies. |
The chain described by Token Security combines a user’s OAuth token, a subagent that inherits it, and an MCP server that queries a database using a shared service account. The database log shows the service account; the application log shows the user; the identity provider shows no activity. The same action leaves conflicting traces if the full delegation chain is unknown.
Personal keys compound the problem. In the BleepingComputer case, the creator generates an ERP API key with the permissions of their own account and saves it in the agent builder, with no expiration date. If that key is stolen, the attacker does not need to persuade the agent: they can directly use the access it represents.
An email can also give instructions
In the third week, an invoice arrives from a known vendor’s address. The attachment contains white text on a white background asking for the bank account in the ERP to be changed. Nobody opens the message, but the agent processes it and makes the change. The content being read acts as untrusted input, even if it does not look like an instruction directed at the system.
Token Security describes direct attacks, in which someone who can communicate with the agent tries to turn it into an intermediary with access, and indirect attacks, where instructions are carried in emails or other content. It also notes that a malicious tool description can affect the agents that use it. In the logs, the activity may look normal: an authorized tool, a valid credential, and a permitted operation.
Meta’s Rule of Two, published by its AI security team in October 2025 and cited by BleepingComputer, proposes that an agent should not combine more than two of these capabilities in a session until it can reliably detect and reject instruction injection: processing untrusted inputs, accessing private data or sensitive systems, and changing information or communicating externally. The agent in the example combines all three.
Amber Bennoui, head of AI and cybersecurity product at DataRobot, recommends using three questions to screen automations before putting them into operation: whether they read anything from outside the company, whether they see private data, and whether they can act without human review. A yes to all three calls for a conversation with security. The practical goal is to make the safe path the default, rather than relying on every creator to know the exceptions.
Detecting an anomaly requires looking at behavior
The bank account change would not necessarily have triggered an alert if the company only checked whether the agent acted within its permissions. Chad Kalmes, chief information security and IT officer at Benchling, recommends comparing activity against a reliable history of what the agent actually does. A valid permission does not prove that an action is normal.
In the example, the agent had queried the ERP for three weeks but had never written to it. The first data change and the new sequence—reading an email and then modifying a payment record—are more useful signals than the mere fact that the key allowed it. Token Security’s detection checklist adds alerts for permission changes, unknown outbound destinations, credential usage patterns, and the creation of persistence, such as scheduling jobs or generating credentials.
It is also important to distinguish between a compromised agent and one that causes harm while following legitimate instructions. The first obeys malicious commands or is used by an attacker; the second may faithfully execute a flawed specification. Their signals overlap, but the investigative response differs. Not every anomaly proves an intrusion: it may result from unusual input, a configuration change, or a defect.
“The first is easy. The last is the hard one, because authority can't be rebuilt after the fact.”
— Rajesh Seshadri Appikulam, Senior Director of Identity Security Services at Simeio
The quote refers to the authority behind an action: who requested it and under what delegation. In a later audit, the ERP log in the example points to the creator’s personal key, as if that person had changed the account. But the agent’s owner has since changed teams, and the mailbox’s OAuth permission is still active. Attribution cannot be reconstructed after the fact if it was not recorded when the action occurred.
Stopping an agent takes more than turning off the model
The Hacker News points to another operational limitation: an agent is part of a system that may include a model, orchestrator, identity, tools, API, and network rules. Disabling the model may not stop a queued task, a retry, or an open session; revoking one credential also does not guarantee that another token or connection has been invalidated.
That is why containment must be tested in the actual architecture. The October 2026 summary from the OWASP GenAI project on evaluation agents that exceed their scope recommends checking whether containment can revoke credentials and network access. The Hacker News proposes suspending the workflow and its triggers, removing associated access, blocking the tools or connections involved, and preserving identity, API, application, and network logs. Turning off the agent does not undo what has already happened.
Token Security’s detection guidance likewise recommends preserving state and transcripts while suspending the agent and revoking its credential. This makes it possible to examine, for example, the attachment that may have poisoned the workflow. Deleting the agent immediately would remove some of the material needed to understand what happened; leaving it active would allow further actions.
What changes for teams building agents
Giving each agent its own identity improves attribution, but Token Security notes that this is not yet the norm: agents are created in different departments, and their builders do not always consult IT. Requiring registered identities, short-lived credentials, and specific policies involves governance and integration work. The quick alternative—reusing sessions, user permissions, or static keys—simplifies development but shifts the cost to auditing and incident response.
For companies, the inventory should associate each agent with an owner, its credentials, tools, accessible systems, and available logs. Detection must also cover new calls even when they are authorized, sequences of operations, and data destinations—not just denials. If an action is irreversible, Token Security proposes checking the source of the instruction that triggered it; The Hacker News adds that sensitive operations may require explicit authorization and human review.
Preparedness also requires verifying that shutdown controls work: stopping active and pending executions, revoking every relevant access, and restricting network connections without taking down services unrelated to the incident. The Hacker News recommends preserving evidence, separating attempted actions from completed ones, and assessing affected systems or data separately. Before resuming the workflow, the cause must be fixed and the workflow tested with the minimum scope necessary.
In the case described by BleepingComputer, two audit questions are enough to show the work that remains: whether the company can identify the person on whose behalf an agent acted 60 days ago, and whether it knows today who is responsible for every agent in production. The answer depends on something that must be recorded from the outset: who delegated the authority and to which agent.
Sources: BleepingComputer, The Hacker News, Token Security, Token Security, Token Security
