Your AI agent is signing its work with someone else's name

FusionAL — Sat, 17 Oct 2026 02:02:55 +0000

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.

Ethical walls don't leak through the file browser. They leak through the summary.

FusionAL — Sat, 17 Oct 2026 02:02:53 +0000

Law firms have used ethical walls for decades: when a lawyer is screened from a matter, the document system stops them opening its files. The control is well understood, well tested, and enforced in the place everyone looks, the user interface.

AI assistants connected to document management systems change where the risk sits.

The new path around the wall

A screened lawyer never has to open a walled document to learn what's in it. They can ask an assistant a broad question: "What are our standard indemnity positions in recent SaaS deals?" If the retrieval layer behind that assistant searches across matters the lawyer can't see, the answer can carry walled content back in a summary, a snippet or a citation.

Nobody opened a restricted file. The interface worked exactly as designed. The wall still leaked.

Where to test

If your firm connects an AI tool to its document system, through MCP or any other integration, three checks are worth doing before anyone relies on it:

Is the wall enforced at retrieval, on every call? Permission checks have to happen where the assistant searches, not only where a human browses.
Does it cover snippets and citations, not just full documents? A two-line excerpt in a search result is still disclosure.
Whose permissions does the session carry? If a connection is set up once by an administrator and then shared, every user inherits the administrator's view.

A simple test: sign in as a lawyer screened from one matter and ask the assistant broad research questions that the walled matter would answer well. Then read the citations.

Why it's worth doing now

Ethical walls exist for conflicts and client confidentiality. A wall that holds in the interface but not in the assistant is not a partial control. From the client's point of view it's a breach, and it's much cheaper to find in a test than in a conflicts review.