Acting on behalf of a user is not the same as acting as yourself
The agent did things for users, and every action was logged as the agent. When a customer disputed one, nobody could say which user it had been done for.
Acting on behalf of a user is not the same as acting as yourself
A tech lead at a workflow automation company told me about a gap that surfaced during a customer dispute. Their agent took actions for users across connected systems. It worked well. The problem appeared when a customer challenged one of those actions and asked, reasonably, on whose behalf it had been taken. The team went to the logs and found that every action, for every user, had been recorded as the agent itself. The agent had done the thing, but the record could not say which user it had done it for. The agent acted as one shared identity rather than on behalf of the specific person it was serving, and that collapsed the entire chain of who authorized what.
There is a real difference between an agent acting as itself and an agent acting on behalf of a user. When it acts as itself, everything traces back to one identity, and the connection to the actual person is lost. When it acts on behalf of a user, the user’s identity flows through the action, the user’s permissions bound it, and the record shows who it was really for. The first is simpler to build. The second is what you need the moment anyone asks a question about a specific action.
Delegation without identity erases the chain
Delegated access is the pattern where a user authorizes an agent to act for them. Done properly, the agent carries a scoped, revocable grant tied to that user, and its actions are constrained by and attributed to that user. Done improperly, the agent just holds its own broad credentials and does things for everyone, and the link back to the authorizing user exists only in your head.
That missing link matters in several ways at once. Permissions blur, because the agent uses its own access rather than the user’s, so it can act beyond what the user could authorize. Attribution blurs, because the record shows the agent, not the person, so you cannot answer who an action was taken for. And revocation blurs, because there is no per-user grant to revoke, so removing one user’s authorization means untangling a shared identity.
The dispute is where all of this comes due. A customer, a regulator, or your own investigation asks who authorized a specific action, and the honest answer is that the system cannot say. The agent did it, and the agent did everything, so the record points nowhere in particular.
Make the agent act as the user it serves
The fix is to preserve the user’s identity through the agent’s actions, so delegation carries a real, traceable grant.
What that looks like:
- Use per-user delegated grants. The agent should hold a scoped authorization tied to the specific user it is serving, not one broad identity it uses for all of them.
- Bind actions to the user’s permissions. What the agent can do on a user’s behalf should be limited by what that user could do, not by the agent’s own access.
- Attribute actions to the user. The record of an action should show the user it was taken for, so a dispute has an answer.
- Make grants revocable per user. Removing one user’s authorization should be a clean operation, not a rework of a shared identity.
The teams that get this right treat the agent as a delegate that always acts in someone’s name, never as an anonymous actor that does things for the crowd. When the dispute comes, and it will, the record answers the question instead of dissolving it.
How we approach it at Density Labs
In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we look at how an agent acts for users. Whether it carries the user’s identity and permissions, or acts as one shared identity for everyone. We check that actions are attributable to the specific person they were taken for, because the day a customer disputes one, that attribution is the whole answer. Designing delegated access properly is far cheaper than reconstructing intent from logs that only ever named the agent.
An agent that acts as itself for everyone erases the link to the person it served. Make it act on behalf of the user, so every action can be traced back to who authorized it.