The audit log says my name: what an agent inherits when you hand it your credentials
The New Stack Naseeb Ahmed Mian
I handed an AI agent my Azure creds and checked what it could really do. It showed my name in the logs, with my permissions and my blind spots.
Based on reporting by The New Stack, Naseeb Ahmed Mian — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
I tested what happens when an AI agent borrows a human’s database credentials, and the result was uglier than the usual “least privilege” sermon. The token it used literally said user_impersonation. That wasn’t a metaphor; it was the scope string.
The first surprise was attribution. Database session records showed my login name, my workstation, and the client tool. Nothing in the record said “agent,” because there is no place for that identity to appear. So the database treats a query typed by a person and a query kicked off by software as the same event, which is convenient right up until someone wants to know who did what.
Then came authorization, which turned out to be mostly invisible to the normal checks. A standard role lookup showed only one direct assignment. Group membership told the real story: 34 active memberships in one view, 37 in the token, with the difference coming from nested groups. Those groups carried the actual access. The agent could hit one production store with two permissions and another, reached an hour later, with 107 permissions. The secure database was locked down; the analytics path was much looser. In non-production, the scope opened up all the way to read and write on both tiers.
Auditing made the whole setup feel almost sarcastic. One environment could delete from a secure database and had no audit trail. Another showed auditing as enabled inside the database, but the monitoring sink stayed empty. The server-level settings told a different story again: one environment had statement-level auditing switched on, the other had nothing attached at all. The logs, in other words, were good at describing the credential and terrible at describing the machine using it.
The repo also had a properly built unattended agent with its own managed identity for things like Key Vault and storage. But when that agent reached the database, it still used a standard SQL login and password set at deploy time. So even the better setup hit the same wall. The name in the log changed, but the underlying problem did not: the system still couldn’t separate the actor from the subject.
My take — AI-written commentary, not fact-checked reporting
This is the part where enterprise teams discover that “just use the human’s token” is not an identity model, it’s a shrug with MFA. Open systems are fine; impersonation by default is not. If the log says a person did it and the agent did the work, that’s not security — that’s a future incident report with good formatting.
Read more about this at: The New Stack