Identity in System Design

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 article examines why that shortcut can fail a compliance review, and what a stronger design looks like.

The belief to challenge is this: if every agent action is logged under one shared account, the organization has an adequate audit trail. The logs exist, they are complete in the sense that each action is recorded, and they can be searched. For many purposes that is a reasonable starting point. For reads of material non-public information, however, the question an auditor asks is not whether a read was logged. The question is whether the read can be tied to the human who was responsible for it.

The compliance requirement for material non-public information is that every read event must tie back to the human responsible for it. Notice what the requirement does and does not demand. It does not say the system must avoid reading sensitive material, and 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.

Think of the audit trail as a chain of links. Each link has to hold for the final log entry to point at a person. Starting from an analyst's request for a summary, the chain runs through the agent, the identity the agent uses, the access check against that identity, the read itself, and finally the log entry. The diagram below traces those links in order.

Once the requirement is stated this way, 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.

The log still contains an actor field, and it is filled in. The problem is what the value says. Under a shared account, the actor value names the account, which many people use, rather than the one person who asked for the read. The table of fields below shows the difference in a single log entry.

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 two designs differ in one important place. The analyst exists in both and asks 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 restores the link the requirement depends on, and it does so without expanding what the agent can 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 shipped the deployment 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.