A log that says "service account" does not say who did it

Open an audit log after something odd happens. The entry reads: svc-assistant read customer_notes at 14:02. You now know which account acted. You do not know which person asked, or why.

That gap is small until someone needs an answer.

Why the shared account is the default

It is the easy way to wire things up. One service account gets read access, the workflow runs, and every call shows up under that name. It works. It also means the log records the tool, not the person behind the request.

A demo example

This is a hypothetical demo, not client work. An internal assistant drafts replies to support tickets for a human to review. It has a read-only lookup into a notes system.

Two people use it. One handles billing tickets. The other handles account access tickets. Both requests reach the notes system as svc-assistant.

Later, someone asks why a note about a password reset was read during a billing ticket. The log cannot say. The account is the same for everyone. The ticket might be in a different system. The timestamps might not line up.

What a useful record holds

For one bounded workflow, I would want each lookup to carry a few things:

• The person who made the request
• The service account that executed it
• The ticket or task it was for
• What was read, and what the draft used

That is enough to answer "who did this" without guessing. It does not need a new platform. It needs the workflow to pass identity along and write it down.

Where MCP fits

If the workflow reaches the notes system through an MCP server, check how the server handles identity. Does it receive the user's identity, or only its own credentials? Many setups use one shared connection. If yours does, the log will show the connection, not the person.

If the workflow does not use MCP, the same question applies to whatever API sits in its place.

Privacy still applies

Internal, non-regulated work still holds customer data. Recording who read what is also a privacy control. Keep the log itself limited. Store references and IDs, not full note contents.

A small test

Pick one workflow. Run a request as a named test user. Then try to answer, from the logs alone: who asked, what was read, and what ended up in the draft?

If you can do it in a few minutes, the record works. If you need to ask around, you have found the gap.

We review this kind of handoff: the point where a person's request becomes a service account's action. It is worth getting right for one workflow before you try to cover all of them.

I'm Jonathan Melton. I run FusionAL, focused on reviewing and integrating lower-risk internal AI workflows, one bounded workflow at a time.