Recent measurements of an AI‑driven coding agent revealed that the agent was authenticating with a developer’s Azure CLI token, causing every database request to appear as if it originated from the human user. The lack of a distinct machine identity means that audit logs, permission checks, and operational safeguards cannot differentiate between manual and automated actions.
Authentication vs. Authorization in Agent Workloads
The agent invokes sqlcmd with the flag --authentication-method ActiveDirectoryAzCli -C. This flag tells sqlcmd to ask the Azure CLI for its cached access token and present it to Azure SQL. The token contains the claim scp: user_impersonation, which RFC 8693 defines as a principal receiving all rights of another while remaining indistinguishable. The token also carries amr: ['pwd','mfa'], indicating that a human satisfied multi‑factor authentication, even if the factor was completed hours earlier for an unrelated task. Although the token’s lifetime field (iat/exp) suggests an 84‑minute window, the CLI automatically refreshes the token, allowing an unattended agent to run indefinitely until the refresh token expires or the user account is disabled.
Audit Gaps When Agents Inherit Human Tokens
Querying sys.dm_exec_sessions for the current session returns the human’s login name, the sqlcmd program name, the workstation host name, and the client driver. No field records the intent or the fact that a machine issued the command. Consequently, downstream controls—rate limits, approval steps, retention policies—cannot be conditioned on the caller being an agent. In practice, the environment where the agent could delete from a secure database was the only one with auditing turned off, creating a blind spot that would not exist if the agent had a separate identity.
Design Implications for Credential Management
Borrowing a human token for an automated skill produces three observable effects: attribution collapses, the agent inherits every permission the human accumulated, and revoking the agent’s access also revokes the human’s access. Standard role‑assignment queries returned a single Reader role on a non‑production subscription, suggesting a small blast radius. However, the token’s groups claim listed 37 entries, and a directory query showed 34 direct group memberships, with additional nested groups. Those groups live in the data plane and grant actual data access, but they are invisible to control‑plane role checks. Permission scoping differed by two orders of magnitude between two production stores examined an hour apart, demonstrating that group‑based access can vary dramatically across environments.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
Teams that embed AI agents in CI/CD pipelines, monitoring bots, or data‑processing workers should stop reusing a developer’s Azure CLI token. Instead, provision a dedicated service principal or managed identity with the minimal set of scopes required for the agent’s function. Verify that audit logging is enabled for every environment where the agent can perform write operations, and confirm that the audit records capture sufficient context (e.g., a custom tag or separate client name) to distinguish automated activity. Regularly reconcile control‑plane role assignments with data‑plane group memberships to avoid hidden permission expansion. Finally, treat the token’s user_impersonation scope as a red flag: it signals that the agent is operating with full user rights, which is rarely appropriate for production workloads.
