Audit Trail Requirements
A shared service account can compromise the compliance posture for material non-public information because reads run under an identity that is not a person.
A Log Entry Is Not Enough
When teams build software that uses an AI agent, one of the first design decisions is which identity the agent's calls should run under. A single shared service account looks clean. It is one credential, one set of permissions, and one place to manage access. For many engineers it feels like the obvious default. This article examines why that default can fail in a regulated setting, and why identity is not just a setup detail but a compliance requirement.
What do you think happens?
Suppose every sensitive read by an agent produces a log entry. Does that mean the audit trail meets the compliance requirement for material non-public information?
Reveal answer
No. The entry must also tie the read to the human responsible.
The source is explicit that the problem is not that a read happened or that something was logged. A log entry can exist and still fail the requirement if the entry points at an identity that is not a person. Audit trails must tie read events to the human responsible.
The Appeal of a Shared Account
The reasoning behind a shared service account is easy to follow. The agent is the system, not the user, so the agent's calls should carry the system's identity. The reasoning seems to treat the agent as a neutral tool that simply acts on its own behalf. That view is tidy, and it is not obviously wrong about how software components are usually modeled.
The belief that a shared service account is sufficient for compliance is a misconception that comes from treating the agent as the system rather than treating the user as the party whose access matters. Keep that rationale in mind as you read the rest of the article. The question is not whether the architecture is tidy or whether the agent is technically a system component. The question is what the audit record says afterward when someone asks who read a piece of sensitive information.
The Research Summarization Case
The source describes a global asset manager that deployed an investment-research summarization agent. The original architecture used a single service-account identity for all of the agent's calls. After a short review, the customer's CISO rejected this design. Her concern was specific. An analyst might use the agent to summarize a research note about a security for which that analyst held material non-public information. The read of that note would then be recorded, but the audit trail would not, in practice, tie the read to the analyst.
The diagram below traces the identity at each hop. The analyst's identity exists at the start of the request, but the read itself runs under the shared account. The record that survives is the one for the service account, so the link back to the analyst is lost at that hop.
The problem was not that a read happened or that something was logged. A log entry existed. The problem was that the entry pointed at a service account, which is not a person, when the compliance requirement for material non-public information asks for something more precise. The source states that read events must tie to the human responsible. The shared-account design could not meet that requirement, so the CISO judged it unworkable.
What an Audit Trail Must Answer
An audit trail is useful for compliance only when it answers a question about accountability. For a sensitive read, the question is which human was responsible for that read. Recording that a call occurred, or that an agent performed some work, does not answer that question.
Identity is what makes the tie to the human possible. The identity attached to each read event is what the record later reveals, so that identity must be able to name the person responsible.
Tracing a Read Event to a Person
When you evaluate an architecture, the source gives a concrete check: determine whether each sensitive read can be attributed to a human, not only whether access is authorized or an event was logged. The procedure below turns that check into steps you can apply to any read path. Start from a read event and walk backward through the identities involved until you either reach a named person or hit an identity that cannot name one.
Read the flowchart from the top. For every MNPI read, the first real question is whether the identity recorded on that event can name a person. If it names only a service account, the path stops there, no matter how well the account is protected or how many logs exist. Only when the identity leads to a person who is actually the responsible human does the event count as attributable.
Shared Account Versus Person-Named Identity
The table compares the two designs on the questions an auditor would ask about a sensitive read. The difference is not in how the read is performed. It is in what the record can say afterward.
| Question about a read | Shared service account | Identity that names a person |
|---|---|---|
| Identity recorded on the read event | A service account, which is not a person | An identity that names the person |
| Can the record say who read the note? | No, it says which account read it | Yes, it names the responsible person |
| Does the record tie the read to the human responsible? | Not in practice, as the CISO's concern showed | Yes, this is the tie the requirement asks for |
| Fit for the MNPI requirement | Fails the requirement | Meets the requirement |
Shared service account versus person-named identity for MNPI reads
Worked Check of an Agent Read Path
Checking a proposed agent architecture
A team proposes an agent that analysts use to summarize research notes. Analysts sign in to a web interface, and the interface passes their user ID to the agent. The agent then reads the MNPI research note from the data store using one service account, and the data store's logs record only that service account. Does each MNPI read trace to a person?
- 1Identify the sensitive read
The read of the MNPI research note is the sensitive event. The check applies to this read.
- 2Trace the identity at each hop
The user ID exists at the interface and is passed to the agent, so the person is present early in the path. The data store records only the service account, so the person's identity is not recorded on the read event itself.
- 3Find where the link breaks
The link to the person is lost at the data store hop, because the record that survives names the service account and not the analyst.
- 4Apply the decision
Following the flowchart, the recorded identity does not name a person, so the path stops at a non-person identity. The architecture fails the attribution check even though the user ID was passed along.
The architecture does not trace each MNPI read to a person. The fix is to make the identity recorded on the read event itself name the responsible analyst.
Mistakes Teams Make With Agent Identity
Common mistake Treating the agent as the system, so its calls should carry only the system's identity
Why it failsThe source identifies this rationale as the root of the misconception. It moves the identity question away from the user, who is the party whose access matters for compliance.
Do this insteadAsk which human is responsible for each sensitive read and make sure the recorded identity can name that person.
Common mistake Assuming that a log entry means the audit requirement is met
Why it failsA log entry can exist while still pointing at a service account. The source says the problem was not that a read was logged but that the entry did not tie to a person.
Do this insteadCheck the content of each entry, not just its existence, and confirm it can answer who was responsible.
Common mistake Checking only that access is authorized
Why it failsAuthorization answers whether a read was permitted. It does not answer who performed the read for accountability purposes.
Do this insteadCheck attribution separately: whether each sensitive read can be traced to a human.
Practice: Auditing a Team Design
A team builds an agent that analysts use to summarize notes that may contain MNPI. Each analyst's request is authorized. The agent reads the notes under a service account for the whole team, and the logs record the service account and the note ID. For each MNPI read, can you trace an unbroken path back to a named human? Explain your answer using the attribution check.
Hints
- Start from one read event and ask which identity is recorded on that event itself.
- Authorization and the presence of a log entry are both true here. Ask whether the recorded identity can name the responsible person.
- If the path stops at the service account, the answer is no, even though the requests were authorized.
Key Takeaways
- 1A shared service account can compromise the compliance posture for material non-public information because reads run under an identity that is not a person.
- 2Audit trails must tie read events to the human responsible, so the identity recorded on each event must be able to name that person.
- 3A log entry or an authorized request is not enough on its own. The question is whether the read can be attributed to a human.
- 4To evaluate an architecture, start from each sensitive read and follow the identities until you reach a named person or a non-person identity.
At a glance
- A shared service account can compromise the compliance posture for material non-public information because reads run under an identity that is not a person.
- Audit trails must tie read events to the human responsible, so the identity on each read event must be able to name that person.
- Authorization and logging are not sufficient on their own. Each sensitive read must be attributable to a human.
- To evaluate an agent architecture, trace each sensitive read back through its identities and check whether the path reaches a named person.