Access Control for Agents

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 shortcut is not wrong in every setting. The problem appears when the material being read is material non-public information, often called MNPI. For that category, a log that exists and is complete can still fail the requirement that the organization actually has to meet.

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. Two properties are being separated here. Completeness means every action has an entry. Attribution means every entry can be connected to a person. A shared account can deliver the first and still fail the second.

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, not against whether the system is busy or whether its logs are full.

The source describes a chain that an auditor needs to be unbroken. The read is performed by the agent, but the identity carried through the agent should be the analyst's own, so that the final audit entry points at a person. Read the diagram from left to right, one message at a time, and notice which link carries the identity.

Every link in that chain must exist. If the audit entry names the agent but the agent identity cannot be tied to a person, the chain has a gap, and the read cannot be attributed to the analyst who requested it. The requirement is met only when the path from entry to person is complete.

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 diagram shows where the chain breaks. The analyst appears only at the start of the flow, as the person who asked, and nothing in the audit entry leads back to that person. Under a shared account, the identity field in the final entry names the account, and because many people use that account, the entry cannot single out which one was responsible for a given read. The log is complete, but it is not attributable.

The analyst exists in both designs 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, and that single change is what restores the link the requirement depends on.

The source fix works because the agent identity is not a broader identity. It is scoped to the analyst's coverage universe, meaning the set of securities and research the analyst is responsible for, and it carries the same access controls as the analyst's own login. This restores attribution 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, the agent had been in production for ten months, and the attributable audit trail was already in place.