When a team connects an AI agent to a real system (a payments API, a CRM, a document store), the fastest way to get it working is to hand it an existing credential: a service account, or the API key a developer already has in their environment. It works on the first try, and that's the problem.
From then on, every action the agent takes is recorded as that credential's owner. The audit log is not missing anything. It is confidently wrong. It says a person approved a transfer, edited a record or pulled a file, when an agent did it on that person's behalf, possibly hours after the person last looked.
Why this matters more than it sounds
For most software, "who did this?" is a debugging question. In regulated work it's the question an examiner, an auditor or a customer's security team asks first:
- Payments and banking: who initiated this money movement, and under what authority?
- Brokerage: who authorized this trade?
- Healthcare: which process read this patient's record, and was it the minimum necessary?
- Legal: who retrieved this privileged document?
If the honest answer is "an agent, using a person's key", your records can't show that, because they only know about the key.
Three questions to ask about any agent you've connected
- What identity does each tool call run as? Not what the architecture diagram says. Pick one real call and trace it.
- What can that identity reach, compared with what the task needs? An agent that summarizes one account usually holds a key that can read every account.
- Could you prove afterwards what the agent did, separately from what a human did? If agent actions and human actions land in the log under the same name, the answer is no.
What good looks like
- The agent has its own identity, distinct from any human's.
- Its credentials are scoped to the task, not inherited from whoever set it up.
- Every call is logged with the agent, the grant that allowed it, and the human who approved it where approval exists.
- Credentials for sandboxes and production are separate, and production keys never sit where a coding agent can read them.
None of this is exotic. It's ordinary least-privilege and audit-trail practice, applied to a new kind of actor that most access models were never designed around.
I'm Jonathan Melton. I run FusionAL, which reviews how AI agents and MCP tools are permissioned when they reach regulated systems.
Top comments (1)
The real teeth are in question 3 — most "agent identity" stories stop at a distinct name, but a distinct name with the same reach as the human's key is just a service account with better marketing. From real experience, the failure mode is ambient credentials: the agent's identity means nothing if production keys sit in env vars or shared config it can read. I'd add a fourth question: what can this identity reach that its current task doesn't need — least privilege per task, not per agent. It's the kind of operational detail we're seeing agents compare notes on at agenshive.com, where the Q&A comes from real runs.