Autonomous AI agents are creating an identity-management challenge for enterprises: they can use credentials, access sensitive systems and act at machine speed, while many existing controls were designed around human users. Danelle Au, a cybersecurity and AI executive, argues that organizations need to treat agents as distinct identities rather than as extensions of the employees who prompt them.
The concern resembles a longstanding problem with legitimate accounts: an organization may verify a user at onboarding, issue credentials and then trust activity associated with that account. Au points to North Korean operatives who posed as remote IT workers using stolen identities as an example of how identity checks can fail. In her view, agent deployments risk carrying forward the same assumption—that an authorized identity is necessarily being used as intended.
AI agents can be connected to databases and other enterprise tools, and may operate with permissions inherited from an employee. As a result, activity carried out by an agent could appear in logs as an ordinary action by that person. The identity attached to a session may not show whether a human or an agent performed the work, or whether an agent’s behavior was altered after it received access.
Trust can be exploited at runtime
Au says an agent may be manipulated through prompt injection, hidden instructions or a compromised external tool after an organization has approved its use. That creates a gap between reviewing an agent before deployment and monitoring what it does during execution. Agents may also call other tools or spawn sub-agents, making it harder to track each action back to an authorized task and accountable person.
She cites a Google Threat Intelligence Group report describing a financially motivated intrusion in which attackers used a multi-agent framework inside a victim’s cloud environment. According to Au’s account, the agents planned and carried out credential harvesting in less than six hours, compromising thousands of enterprise secrets. Because the activity originated within the victim’s environment, it illustrated how malicious actions by a trusted proxy can blend into internal traffic. The example underscores the need to assess identity and behavior together, rather than relying only on network location or initial authorization.
Conventional identity and access management processes typically include provisioning, periodic access reviews and offboarding. Those controls are difficult to apply at the same pace as agents that can start quickly, make many queries, invoke connectors and stop running before a human review occurs. Au identifies three questions security teams should be able to answer: who approved an agent, which human is responsible for its outputs, and how access can be withdrawn while it is acting.
Controls for agent identities
Au proposes several measures to reduce the risks. They focus on establishing an agent’s provenance, limiting its authority and making intervention possible while it is running:
-
Track provenance with an AI Bill of Materials. Before granting access, teams should identify an agent’s code lineage, system-prompt integrity, models, skills and data connectors. The proposed AI Bill of Materials (AIBOM) adapts the inventory approach used by a Software Bill of Materials (SBOM) to AI components. Au also emphasizes runtime checks: she refers to researchers’ August documentation of a malicious MCP server that passed an install-time review and later directed connected agents to collect SSH keys and cloud credentials after its third call.
-
Give agents their own workload identities. Rather than allowing an agent to inherit a person’s long-lived credentials, organizations should issue distinct, short-lived tokens scoped to specific tasks. Au recommends binding each token to a named human sponsor, so responsibility for authorizing the agent is traceable and a compromise has a more limited scope.
-
Separate risky capabilities. Meta’s “Rule of Two,” as described by Au, says an agent should combine no more than two of three capabilities: processing untrusted input, accessing sensitive data, and changing systems or communicating externally. If a task requires all three, a deterministic broker outside the model should hold the action for human approval. Database deletions and financial transfers are examples she gives. She also calls for denying outbound traffic, including DNS, by default.
-
Enable machine-speed revocation. Automated circuit breakers should be able to interrupt an agent’s execution when it breaches a defined budget or behavioral limit. Au argues that waiting for a human-speed security alert can leave too much time for an agent acting at machine speed.
The recommendations reflect a broader shift in identity governance: authorization at launch is not enough when software can act autonomously and its instructions or connected tools may change the risk during a session. Au cautions that assigning accountability may also be difficult when an agent’s actions involve a model provider, an application developer and a business user. Regardless of how responsibility is ultimately allocated, organizations need an auditable link between each agent, its permissions, its sponsor and its actions.
For security teams, the practical objective is to make agent access identifiable, narrowly scoped and revocable. Treating non-human agents with controls comparable to those applied to human accounts can help organizations understand what is acting inside their systems—and respond when that activity no longer matches its authorized purpose.
