Identity and Access in Agent Systems

When a team builds software that uses an AI agent, one design decision comes up early: which identity should the agent's calls 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. The core point is that identity is not just a setup detail. In a compliance context it is a requirement, because the record of who did what must be able to name a person.

The belief that a shared service account is sufficient for compliance rests on a reasonable-sounding rationale: the agent is the system, not the user, so the agent's calls should carry the system's identity. This treats the agent as a neutral tool that acts on its own behalf.

Keep that rationale in mind, because 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.

A useful way to see the problem is to compare two identities on the same read. In the first, the read runs under a shared service account that many people and many agent calls use. In the second, the read carries the credentials of the individual person who asked for the work. The data store is reached in both cases, and the note is returned in both cases. The difference lies only in what the record can say afterward.

Trace a single request step by step. An analyst asks the agent for a summary. The agent then reads the research note from the data store. The question to ask at each handoff is which identity travels with the request.

Step 2 is where the identity is lost. The analyst's request reaches the agent with the analyst's intent attached, but the source describes the original design in which all of the agent's calls ran under one service-account identity. By the time the data store receives the read, it sees only the service account. Nothing in that read tells the store, or a later auditor, which analyst asked for it.

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. The customer's CISO rejected this design after a short review.

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.

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 possible, because the identity attached to an event is what the record later reveals. For the log to answer who accessed material non-public information and on whose behalf, each read event needs to carry enough information to name the resource, the actor that performed the read, the human responsible, and the time.

When you evaluate an agent architecture, do not stop at asking whether access is authorized, or whether an event was logged. Check whether each sensitive read can be attributed to a human. Walk through every read path the agent uses, and for each one ask whether the record can name the person responsible.