Designing for Compliance Reviews

When a team builds an internal AI agent that reads documents on behalf of employees, one of the first decisions is how the agent should authenticate to the systems it touches. A common shortcut is to give the agent a single service account that every user shares. It is simple to set up, it needs no per-person configuration, and it appears to give the organization a complete log of what the agent accessed.

This lesson examines why that shortcut can fail a compliance review, what a stronger design looks like, and why the decision is easier to get right when compliance people are involved from the start. The belief to challenge is simple: if every agent action is logged under one shared account, the organization has an adequate audit trail. For many purposes that is a reasonable starting point. For reads of material non-public information it is not enough.

The compliance requirement for material non-public information is that every read event must tie back to the human responsible for it. It is worth reading that sentence carefully, because it demands less than it might seem to. It does not say the system must avoid reading sensitive material. It does not say the agent must be forbidden from summarizing notes. It says that when a read occurs, the record must make it possible to name the responsible person. Design decisions are judged against that test, not against a general wish for more logging.

Think of a single read as a chain. At one end is the analyst who asked for a summary. In the middle is the agent, which performs the read. At the far end is the audit entry the auditor will eventually examine. For the requirement to hold, the chain must stay unbroken from the analyst all the way to that entry. The diagram below shows the chain the auditor needs. The read is performed by the agent, but the identity carried through the agent should be the analyst's own, so that the audit entry points at a person.

Read the chain from the bottom up, as an auditor would. The audit entry must name a person. If it names the agent identity, the chain holds only if that identity is the analyst's own. If it names a shared account, the chain has been cut at the identity step, and no amount of additional logging downstream repairs it. The requirement is about the link between the person and the read, and the identity carried through the agent is where that link is made or lost.

Once the requirement is stated as an attribution test, the shared account fails for a structural reason rather than a technical one. The agent is performing the read, but the agent is not the responsible party. The analyst who asked for the summary is the responsible party. If the only identity visible in the record is the shared account, the chain between the analyst and the read has been cut. Nothing about the logging is broken. The record simply has no field that points at the person.

The fix described in the source gave the agent a per-analyst identity. Each analyst's agent identity was scoped to that analyst's coverage universe, meaning the set of securities and research the analyst is responsible for. Crucially, the agent identity carried the same access controls as the analyst's own login. The agent therefore could not reach anything the analyst could not already reach, and every read it performed could be attributed to a specific person. The change restores attribution without expanding what the agent can reach.

The two designs have the same analyst, asking for the same summaries. What changes is which identity the system records when the read occurs. The per-analyst design moves attribution from an account that many people share to an identity that belongs to exactly one person. That single change is what restores the link the requirement depends on. Notice too that the access controls did not become more permissive. The agent identity inherits the analyst's controls, so the new attribution comes with no widening of reach.

The source scenario also shows a process lesson. The customer's CISO rejected the shared-account architecture in a single thirty-minute conversation. The team then spent two weeks reworking identity, and the deployment still shipped on schedule. The schedule held because the forward deployed engineer pulled the CISO into the design review in week one, instead of waiting for the validation review in week eight.

Had the objection surfaced at week eight, the same two weeks of identity work would have landed on a nearly finished system, and the rework would have threatened the delivery date. Raising the compliance concern at the design stage turned a late, expensive change into an early, cheap one. The source also reports that the two weeks of identity work paid for themselves later, when the compliance team had to evidence the audit trail for an SEC inquiry, by which point the agent had been in production for ten months.