AI Agents Are Impersonating Others: The Hidden Crisis in Audit Logs

When teams connect AI agents to real systems (payment APIs, CRMs, document repositories), the fastest approach is often to hand them a ready-made credential: a service account, or an API key already present in the developer environment. It works on the first try—and that's exactly where the problem lies.

From that moment on, every action the agent takes is recorded as an operation by the credential's owner. The audit log misses nothing, yet it is confidently wrong—it shows that someone approved a transfer, edited a record, or pulled a file, when in fact the agent did it on that person's behalf, possibly hours after the person last looked at the system.

Why This Is More Serious Than It Sounds

For most software, "who did this" is just a debugging question. But in regulated domains, it's the first question examiners, auditors, or customer security teams ask:

• Payments and banking: Who initiated this fund movement? Under what authority?
• Brokerage: Who authorized this trade?
• Healthcare: Which process read this patient's record? Was the minimum necessary principle followed?
• Legal: Who retrieved this privileged document?

If the honest answer is "an agent, using someone's key," your records can't show that, because they only recognize keys.

Principle of Least Privilege is a foundational principle in information security: any subject—user, process, or service—should receive only the minimum permissions necessary to complete its current task, and hold them only for as long as necessary. First systematically articulated by Saltzer and Schroeder in 1975, the principle is now written into compliance frameworks including HIPAA, PCI DSS, and SOX. For agents, the practical difficulty is that permissions are often inherited along with credentials: a developer, for convenience, reuses their own API key, and the agent automatically gains all permissions under that developer's name—far beyond what a single task requires. Least privilege demands dynamically issuing short-lived, narrowly scoped credentials per task, rather than long-term reuse of broad-permission keys.

In audit and compliance contexts, non-repudiation means the system can conclusively prove that an operation was indeed initiated by a specific subject, and that the subject cannot later deny it. Traditional access models assume "the credential holder is the operator," so the identity field in logs inherently carries non-repudiation. But once an agent reuses a human credential, that assumption breaks: the log records the credential owner while the actual operator is the agent, making the record formally complete but substantively distorted. In scenarios like financial transactions and medical record access, this distortion directly breaks the audit chain—examiners cannot determine accountability from it, nor verify whether operations received proper authorization.

Three Must-Ask Questions About Connected Agents

To assess any agent already connected to a system, start with three concrete questions:

1. Under what identity does each tool call run? Don't look at the architecture diagram—pick a real call and trace it.
2. How does the reach of that identity compare to what the task actually needs? An agent responsible only for summarizing a single account typically holds a key that can read all accounts.
3. Can you later prove, separately, what the agent did versus what a human did? If agent operations and human operations are attributed to the same person in the logs, the answer is no.

These three questions target identity attribution and permission boundaries—the smallest entry point for risk investigation.

What the Ideal State Should Look Like

An auditable agent integration should meet the following conditions:

• The agent has its own identity, distinct from any human identity.
• Its credentials are scoped per task, not inherited from its builder.
• Each call records three elements: the agent, the authorization grant, and (if applicable) the approver.
• Sandbox and production credentials are isolated from each other; production keys are never placed where a coding agent can read them.

These are not novel requirements. They simply apply conventional least-privilege and audit-trail practices to a new kind of subject that most access models were never designed to consider.

Service accounts are machine identities designed for non-human subjects, common in cloud platforms and operating systems. Their key difference from human accounts is that they aren't tied to an individual, typically don't enable interactive login, and have rotatable credentials with finely configurable permissions. However, assigning an agent a static service account is still insufficient—service accounts tend to be long-lived and broadly permissioned, and multiple agents may share the same account, making it impossible to distinguish which agent instance acted in the logs. A better approach is to issue an independent identity for each agent instance and combine it with short-lived tokens (such as OAuth 2.0's client credentials mode or workload identity standards like SPIFFE), aligning credential lifetime with task duration.

Consensus and Divergence Across Multiple Perspectives

The core argument of this article aligns with observations from Jonathan Melton (founder of FusionAL, focused on reviewing permission configurations when AI agents and MCP tools connect to regulated systems). Taken together, there is clear industry consensus on this issue: identity impersonation is the default trap of agent integration, not an occasional mistake.

On specific solutions, views diverge slightly: some emphasize starting from the identity layer, establishing independent identities and fine-grained authorization for agents; others prioritize runtime monitoring and log separation, arguing it's more pragmatic to first make behavior distinguishable and then gradually tighten permissions. The two paths aren't mutually exclusive, but the choice of priority affects the pace of implementation.

Among single-source insights, Melton's "three must-ask questions" are especially actionable—they don't depend on any specific toolchain and can be used directly for self-assessment of existing systems.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024 to standardize how AI models connect to external tools and data sources. It lets agents call filesystems, databases, APIs, and other resources through a unified interface, greatly reducing the cost of tool integration. But MCP itself focuses on "how to connect," not "under what identity to connect"—tool servers typically reuse the deployment environment's credentials, which precisely amplifies identity impersonation risk. Therefore, implementing independent agent identities and fine-grained authorization in the MCP ecosystem requires additionally introducing identity proxies or credential exchange mechanisms on the tool server side, rather than relying on the protocol's default behavior.

Practical Recommendations

For teams preparing to or already connecting agents to production systems, proceed in the following order:

• Audit before overhauling: Pick a high-frequency agent call, trace its full identity chain, and confirm whether humans and agents are conflated in the logs.
• Split credentials: Completely separate the agent's service account from human accounts, and reissue credentials with least privilege per task.
• Isolate environments: Ensure production keys are physically isolated from sandbox and coding environments, preventing development convenience from eroding security boundaries.
• Add approval records: Explicitly record the authorization source and approver in logs, making "who approved, who executed" immediately clear.

The efficiency gains from agents are real, but if identity attribution is vague, the cost of that efficiency may be failing a compliance review. Treating agents as independent subjects with a name, permission boundaries, and an audit trail is the sustainable way to integrate them.