I measured what an AI agent actually holds when it authenticates as me. Authentication turned out to be a token whose scope string literally says user_impersonation. Authorization came almost entirely from group membership that standard permission checks cannot see.
Permission scoping differed by two orders of magnitude between two production stores reached an hour apart, and audit coverage ran inversely to what the credential could do. The environment where the agent could delete from a secure database was the only one with no audit trail.
When I measured the machine identity our own unattended agent runs under, built properly and scoped per resource, it broke in the same place mine does.
“The environment where the agent could delete from a secure database was the only one with no audit trail.”
I gave a coding agent my own Azure credentials, which is standard practice, and then investigated what it could reach. The answer: two permissions on one production store and 107 on another. The environment where it could delete from a secure database was the only one with auditing switched off. None of that was a misconfiguration. All of it was reasonable when the only thing holding that credential was a human.
Eleven agent skills in our working repository connect to databases. They all authenticate the same way:
That flag tells sqlcmd to ask the Azure CLI for its cached token and present it. No connection string, no stored password, and no credential belonging to the agent itself. When the agent runs a query, the database sees me.
Source link







