AI agents inherit full user permissions, breaking audit trails and security boundaries

A recent security investigation into how AI agents authenticate within enterprise environments has exposed critical gaps in identity management and audit logging. When developers allow coding agents to use their own cached credentials, the agents inherit the full scope of human permissions, often bypassing intended security boundaries. The study, published on October 8, 2026, demonstrates that this practice collapses attribution, making it impossible to distinguish between human intent and automated actions in database logs.

What happened

The author, a full-stack engineer, measured the actual permissions held by an AI agent when it authenticated using their personal Azure credentials. This setup is common in development workflows where agents connect to databases via command-line tools that piggyback on a developer’s existing session. The investigation revealed that the agent did not have a limited or scoped identity; instead, it operated with the exact same privileges as the human user, including group memberships that were invisible to standard permission checks.

The results varied drastically across different production stores accessed within an hour. In one environment, the agent had only two permissions, correctly restricted to read-only access. In another, the same token granted 107 permissions, including write, schema definition, and database administration rights. Most concerning was the finding that the environment where the agent could delete data from a secure database was the only one with auditing completely disabled at the server level. The database reported auditing as enabled due to leftover configuration objects, but no logs were actually being written.

Key details

• Credential inheritance: Agents using cached CLI tokens authenticate as the human user, with the token scope explicitly set to user_impersonation.
• Invisible permissions: Authorization relies heavily on group membership, which standard role assignment queries often miss, leading to a false sense of limited access.
• Audit gaps: The environment with the highest risk (delete access) had no active audit trail, while safer environments were fully logged.
• Attribution collapse: Database logs record the human’s login name and workstation, making it impossible to prove whether a query was typed by a person or executed by an agent.
• Token longevity: Although access tokens have short lifetimes, automatic refresh mechanisms allow unattended agents to maintain access indefinitely until the user account is deactivated.
• Service account limitations: Even properly configured machine identities failed to provide distinct attribution at the database layer, as they often fell back to standard SQL logins that do not distinguish between callers.

Background

To understand these risks, it is helpful to distinguish between authentication and authorization. Authentication verifies who is connecting, while authorization determines what they can do. In modern cloud environments, this is often managed through tokens and group memberships. When an AI agent uses a developer’s credentials, it engages in "impersonation," meaning it becomes indistinguishable from the user.

Audit logs typically capture metadata such as login names, host machines, and client interfaces. However, these logs do not currently include a field for "agent intent." Consequently, security teams rely on the assumption that a human is behind every action. When an autonomous agent performs thousands of operations, this assumption breaks down. Furthermore, "just-in-time" access groups may remain active in a cached token even after they have been deactivated in the directory, creating a window of vulnerability that standard checks cannot see.

Why it matters

For teams running their own software, this issue strikes at the heart of operational security and compliance. Self-hosted environments often rely on strict access controls to protect sensitive data. If an AI agent inherits broad permissions, a single misconfigured prompt or buggy script could lead to data deletion or exposure that is traced back to a senior engineer. This not only complicates incident response but also creates liability issues, as the engineer cannot easily prove they did not personally execute the harmful command.

Moreover, the inconsistency in audit coverage poses a significant blind spot. Teams may believe they are protected by comprehensive logging, only to discover that high-risk environments are silently failing to record activity. This is particularly dangerous in non-production environments, which are often left unmonitored to save costs. As agents become more autonomous, the volume of automated actions will increase, making it essential to have accurate, attributable logs for debugging and security reviews.

What you can do

• Avoid credential sharing: Do not allow AI agents to use personal cached credentials; instead, provision distinct service accounts or managed identities for each agent.
• Implement delegation tokens: Use authentication standards that support delegation, where the token carries both the subject (human) and the actor (agent), allowing logs to record both identities.
• Enforce least privilege: Ensure agent permissions are an intersection of required tasks, never exceeding the specific actions needed for the workflow.
• Verify audit trails actively: Regularly test audit configurations by performing sample actions and confirming they appear in the monitoring sink, rather than relying on status flags.
• Decouple revocation: Design systems where agent access can be revoked independently without deactivating the human user’s primary account.
• Scope by action: Move away from broad role-based access for agents and implement permissions tied to specific operations or API endpoints.