An engineer measured what his coding agent reaches with his Azure login

An engineer gave a coding agent his own Azure login and then measured what the agent could actually reach. On one production database the token held 2 permissions. On another, reached from the same login an hour later, it held 107. The environment where the agent could delete rows from a secure database was the only one with the audit trail switched off.

The piece is a sponsored article on The New Stack by Naseeb Ahmed Mian, an engineer placed at Vantaca through Andela. Andela sells remote tech talent, not database products, and what Mian measures are Microsoft Azure defaults.

The setup almost everyone has

Eleven agent skills in his working repository connect to databases the same way. sqlcmd --authentication-method ActiveDirectoryAzCli asks the Azure CLI for its cached token and presents it. No stored password, no credential belonging to the agent itself. When the agent runs a query, the database sees Mian. He ran a sys.dm_exec_sessions query from inside the connection and found exactly three identity fields: login_name, program_name, host_name. No fourth field for an agent to declare itself, so no downstream guardrail can be conditional on the agent.

What the token actually says

Mian decoded the access token the CLI hands over. The scope reads user_impersonation, which RFC 8693 defines as a principal receiving all rights of another while remaining indistinguishable from it. The amr claim carries mfa, so every agent action arrives with an attestation that a human satisfied a second factor, even if that factor was completed hours earlier. The 84-minute token lifetime looks like a safety boundary, but the CLI refreshes automatically, so an unattended run continues until the refresh token itself expires.

Standard role listings returned a single row for his account, Reader on a non-production subscription. The token's groups claim carried 37 entries, with 34 nested memberships inside production-named groups like SQL Database Manager and Resource Contributor. A reviewer checking agent authority through standard role assignments sees that one row and believes the agent can reach almost nothing. The directory and the database both show it can reach much more.

The gap between two production stores

Running fn_my_permissions on the production SQL server showed 1,382 visible databases, with CONNECT and SELECT on the business tier and a login error on the secure tier. Running the same token against the production analytics endpoint over the same lakehouse an hour later returned 430 tables and 107 permissions covering read, write, schema definition and database administration. The restriction on the secure tier was enforced in one engine and not the other. The instruction file the agent reads before touching that endpoint says the surface is read-only. "Code enforces one restriction, while the other is a sentence in a file. The agent reads both, verifies neither."

Audit coverage ran in the opposite direction. Production had server-level auditing with statement-level action groups. The non-production environment, where the token could write and delete on both tiers, had auditing switched off entirely at the server level, and the six database specifications marked enabled were remnants from past environment copies.

Mian also ran the checks against an unattended agent on a managed identity with per-resource grants. The managed identity is used for storage and key vault, and at the database falls back to a shared SQL login set at deploy time. A per-agent service account changes the name in the log, and leaves the attribution problem exactly where it was.

Mian closes with the Model Context Protocol authorization specification, which prohibits servers from forwarding client tokens so downstream services can verify the caller's identity, and recommends command-line tools adopt the same rule.

Source

The audit log says my name: what an agent inherits when you hand it your credentials, Naseeb Ahmed Mian, The New Stack (sponsored by Andela)