Who Did That? Agent Identity and Approval Trails for Document Work

Name the actor behind each step

When a document packet changes hands, “the system updated it” is not a useful answer to who did what. A workflow may involve a person requesting work, an agent gathering information, another person reviewing it, and a service executing an approved action. Record those roles separately. Otherwise, an activity history can blur an automated suggestion, a human decision, and the subsequent system operation into one event.

Assign each agent a recognizable identity and an accountable human sponsor or owner within the organization’s chosen architecture. This does not make an agent a person or transfer responsibility to it. It gives administrators and reviewers a way to distinguish agent activity from other application and user activity. Microsoft’s agent-identity documentation illustrates distinct agent identifiers, authorization, and agent-specific activity records in its platform.

Separate access from approval

An agent may have permission to read a limited set of documents so it can prepare a checklist. That access does not mean it may send those documents, change their recipients, or approve their contents. Design permissions around actual tasks and resources: a preparation agent might need read access and a place to save a draft, while an execution step requires a separate authorization check.

Avoid a shared, highly privileged account that makes every operation look alike. If the workflow acts on behalf of a person, keep track of whose authority is being used and its permitted scope. OWASP recommends limiting tools and permissions, executing actions in the relevant user’s context where appropriate, and validating authorization in downstream systems rather than asking a model to decide whether an action is allowed.

Connect the trail without conflating roles

For a proposed packet send, a useful trail connects the request, the agent’s preparation step, the reviewer’s decision, and the actual execution result. Each record should identify the actor and target. A failed send is not the same as a completed send; a prepared draft is not the same as an approved one. These distinctions help an operations team answer routine questions without reconstructing an entire chat session.

Record an approval against the specific action presented to the reviewer. If the recipient or attachment changes, the old approval should not silently travel with it. Keep the audit view understandable to nontechnical owners: they should be able to identify what was proposed, what was approved, and what actually occurred. The trail supports accountability, but it cannot substitute for clear authorization rules and meaningful review.

Review identities as workflows change

An agent’s access can outlive the project that justified it unless someone owns its lifecycle. Add agent identities to ordinary reviews of who can reach documents, tools, and destinations. When a workflow is retired or its scope narrows, remove unneeded permissions and disable obsolete integrations. Document who can approve a new capability rather than letting a configuration change quietly expand the agent’s role.

Try a simple investigation exercise: select one recent test packet and ask an uninvolved colleague to identify the requesting person, the preparing agent, the approving person, and the execution outcome. If the colleague cannot do so from the records, improve the trail before scaling the workflow. Identity is useful when it makes both day-to-day ownership and exception handling clearer.

Sources and further reading

• Microsoft Entra Agent ID: Agent identities
• Microsoft Entra Agent ID: Agent service principals
• OWASP LLM06:2025 Excessive Agency