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

  1. What identity does each tool call run as? Not what the architecture diagram says. Pick one real call and trace it.
  2. 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.
  3. 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.