AI agent security: how one unattended bot exposed five enterprise gaps

An AI agent created by someone in an accounts team automated invoice checks and Slack summaries, then changed a vendor bank account after reading hidden text in an attachment. According to BleepingComputer, the bot had three forms of access to sensitive systems, nobody in security knew it existed, and the resulting change looked legitimate in standard logs.

AI agent security: what happened and why it matters

According to BleepingComputer, the agent was intended to read an inbox, match invoices with the ERP, and post a daily summary to Slack. It was built quickly using a no-code builder, and it gained access via an OAuth consent for email, a personal API key for the ERP, and a Slack connector. The agent read email content that humans did not open, processed a hidden instruction embedded in an attachment, and used its credentials to update ERP payment details.

This matters because the activity appeared authorized in usual audit trails, yet the change originated from unreviewed automation and a hidden input. For organizations with multiple teams building or using agents, this kind of gap creates a risk both for fraud and for audits that cannot reconstruct who truly authorized an action.

How the agent got access

BleepingComputer summarizes four common access paths that change what you can see in logs. John Donovan outlined them as:

• riding a human session, where extensions or copilots act as the user, which shows the user in some logs;
• delegated OAuth grants, where a single user approval grants ongoing access;
• static credentials like API keys and service account passwords that anyone who finds them can use;
• purpose-built agent identities that are short lived and tied to the agent, which are ideal but rare.

In this case the agent mixed access types: an OAuth consent for the inbox, a personal ERP API key created by the agent owner, and a builder-managed Slack connector. That mix left gaps in what the identity provider and service logs could show, and it left long-lived credentials in place.

Where defenses failed

Several design and process gaps let the agent move from useful automation to a dangerous change. BleepingComputer recounts a few points practitioners highlighted:

• No review before deployment. The agent went live because no one asked security to review it. The article cites Amber Bennoui and the Agents Rule of Two as a simple safety heuristic: an agent should not, in a single session, process untrusted input, reach sensitive systems, and change state or communicate externally. This agent did all three.

• Input treated as trustworthy. A hidden note in an invoice attachment gave an instruction the agent followed. Joshua Copeland explains that instructions can arrive inside the content an agent reads, including messages humans do not open.

• Weak credential hygiene. The ERP key was a personal API key saved in the builder with no expiry, which increases exposure if the agent or its owner are compromised.

• Thin audit records. When auditors later examined the change, logs showed the creator's API key, but the human delegation chain and real authority were unclear. The result: it became hard to prove who truly authorized the change.

Detection also almost failed until a behavior baseline was used. Chad Kalmes recommends baselining agents on what they actually do. Against that baseline, two signals triggered in the incident: a first use of a permitted tool that had only been read-only before, and a new sequence of actions, reading an email then changing payment records, that the agent had not previously run. The recommended immediate action is to suspend the agent without destroying it, revoke credentials, and keep transcripts for investigation.

Practical steps you can take now

Based on the issues described by BleepingComputer and the practitioners it cites, consider these concrete actions:

• Inventory and discover agents. Search for agent-style integrations, OAuth grants, and API keys across email, ERP, and collaboration tools, and log any you find.
• Require a security review for risky agents. Ask builders three plain questions: does the agent read outside content, can it access private data, and can it act without a person checking first. If the answer to all three is yes, route the agent to security review.
• Favor short lived, purpose-built identities. Avoid personal API keys with no expiry and limit delegated OAuth scopes and lifetime.
• Treat all inputs as potentially commanding. Design agents so no single external input can cause an irreversible action without human verification.
• Baseline normal behavior, then alert on deviations. Watch for the first write of a tool an agent has only read from, and for new sequences of actions the agent has not performed.
• Preserve evidence when you suspend an agent. Revoke credentials but keep memory and transcripts so you can find poisoned inputs and follow the chain of events.
• Practice quick audit checks. Pick an action from 60 days ago: can you name the human it acted for? For any production agent, can you name its current owner? If not, prioritize fixes.

If you want a place to start assessing what an attacker can learn about your site, see our security page at /security.html.

Where to look for more practical guidance

BleepingComputer notes that Token Security collected hands-on lessons into a free learning hub called the Agentic Universe. More than 20 contributors, including security leaders from several companies, shared short videos and checklists that cover agent behavior, compromise scenarios, and incident response. The examples in that hub mirror the practical fixes described above: focus on access paths, require simple pre-deployment checks, baseline behavior, and keep better audit evidence.

The core point is simple: agents can look legitimate while doing harmful things. Build basic guardrails around who can create agents, how they get credentials, and how you detect changes from their normal behavior, and you will reduce the chance that a quick automation becomes a costly incident.