AI agent security: when valid access goes wrong

An artificial intelligence (AI) agent can change a supplier’s bank details with a valid API key after reading a malicious invoice. That is the failure in Token Security’s fictional accounts-agent scenario: the agent has permission, but the action is wrong. You can use this example to trace access paths, check approvals, plan detection and identify the human authority behind each action. AI agent security needs controls over what agents do, not just what they are allowed to reach.

The article is sponsored and written by Token Security. The agent is imaginary; this is not a disclosed customer incident. Its workflow is concrete, though. It reads email, matches invoices against an ERP system and posts summaries to Slack. The problem sits in the personal API key that makes the automation useful: that same key also permits changes to vendor bank details.

Why confident teams still miss agents

In the Cloud Security Alliance’s April 2026 survey announcement, confidence and discovery tell different stories. Of the respondents, 68% reported strong visibility into their agents. Yet 82% had discovered previously unknown agents during the preceding year. Those figures make confidence alone a poor place to stop the inventory review.

CSA ran the survey online in January 2026 and collected responses from 418 IT and security professionals. Token Security commissioned and financed the research, and it co-developed the questionnaire. CSA’s analysts handled the analysis and interpretation.

I’d test confidence in an inventory against actual access rather than treat it as evidence that discovery is finished. CSA says unknown agents commonly turned up in internal automation, scripting environments, platforms for language models, SaaS automation and developer-created workflows. That is a wider review than an identity-team inventory alone can provide; the review has to include those places too.

Trace AI agent security through each access path

I find an agent’s borrowed authority more revealing than its name. The accounts scenario makes the distinction clear: email access comes through an OAuth consent screen, ERP access through a personal API key, and Slack access through the builder’s connector. Each connection deserves its own examination.

John Donovan’s explanation of agent access separates four underlying patterns. He also describes a combined path, where an agent stacks several of those patterns together. That combined case is the messy one to follow.

Donovan’s combined example shows why logs that look useful in isolation can still leave attribution unanswered. A user’s OAuth token passes to a sub-agent. That sub-agent calls an MCP server, which reaches a database through a shared service account. The database records the service account, the SaaS audit records the user, and the identity provider sees no corresponding activity. Following the action means following that whole path, not just reading one of those records.

Revoking one credential does not close every access path. Donovan warns that OAuth grants issued directly by a SaaS application are not flagged in the identity provider. Those grants can survive the normal workflows used to offboard a human.

Break the invoice-to-bank-change path

The accounts agent becomes dangerous because it combines outside content, private data and the ability to act. In Token’s scenario, an invoice attachment contains instructions written in white text on a white background. No person opens the email. The agent nevertheless reads the hidden text and changes the vendor’s bank details.

Amber Bennoui, a product leader for AI and cybersecurity at DataRobot, applies the Agents Rule of Two, published by Meta’s AI security team in October 2025. The rule puts a limit on this combination: until prompt injection can be reliably detected and refused, an agent should have no more than two of these capabilities in one session:

• It processes untrusted input.
• It reaches sensitive systems or private data.
• It changes state or communicates externally.

The invoice example has all three, with no need to infer extra capabilities. Incoming invoices supply the untrusted content. Vendor records expose private data, and permission to edit those records gives the agent consequential write access.

I’d keep bank-detail changes outside this summariser’s unattended actions. Bennoui’s proposed intake questions give builders a direct way to examine the same problem: does the agent read outside content, see private data and act without a person checking? If the answer is yes to all three, the agent needs an AI agent security review before activation.

Review production AI agents in this order

For this workflow, I’d start by checking what the ERP credential can actually do, then follow the rest of the access and accountability chain. This ordered checklist applies the practitioners’ advice to the accounts agent, from identifying its owner through preserving the authority behind an action.

1. Record the owner and every access path. Identify who owns the agent today and which systems it reaches. For each connection, establish whether it uses a human session, OAuth, a static credential or a dedicated identity. The builder’s connector names are not enough: record the downstream identity that actually performs the work, rather than stopping at the connection shown to the builder.

2. Compare the intended job with the actions the credential permits. This agent needs to match invoices and publish summaries, but its creator’s ERP key also allows bank-detail edits. Apply Bennoui’s review before enabling a workflow that combines outside input, sensitive access and unattended action.

3. For AI agent security, baseline behaviour, not just compliance with permissions. Chad Kalmes, identified in the article as CISO and CIO at Benchling, recommends learning what an agent actually does over a trustworthy window. In the invoice workflow, the first ERP write matters. So does the new sequence from email to payment record. Both are meaningful signals even though the credential permits the actions involved.

4. Prepare to contain the agent without losing the evidence. The article’s response advice is to suspend the agent without destroying it, revoke its credential, and retain memory and transcripts. The malicious invoice may still be present. Check the other access paths as part of that response: the scenario explicitly leaves an inbox OAuth grant active after the ERP key has been revoked.

5. Capture authority at the time of the action. Rajesh Seshadri Appikulam, senior director of identity security services at Simeio, identifies the audit questions: which agent acted, under what entitlement, with whose approval and on whose authority? Record the human requester and delegation chain when the action happens. His warning is specific: authority cannot be reconstructed afterwards.

Appikulam offers a test that makes the accountability question concrete. Select an agent action from 60 days earlier and identify the human it acted for. Then choose a production agent and identify its current owner. If either answer takes more than five minutes, start remediation there rather than making another claim of strong visibility.

An agent identity does not establish legitimate intent

Purpose-built identities address attribution, credential lifetime and access policy. They do not replace Bennoui’s separate review of what an agent can read and do. Registering an agent does not prevent it from being the actor behind an unwanted action. In Token’s example, the malicious instruction leads to work carried out through an authorised tool using a valid credential; the access itself is valid.

The evidence has limits that need to stay attached to it. CSA’s figures describe respondents’ reported experiences. The invoice sequence, by contrast, is an illustration, not an incident record. Neither establishes a measured success rate for any particular defence.

For an inbox-to-ERP workflow, I’d put that requirement into the workflow before allowing unattended payment edits: keep the automation read-focused, require human review for consequential changes, and record delegation at the time of the action.