Language model–powered agents are starting to do real work: send emails, update systems, move data, trigger workflows. To be useful, they often need to act on behalf of a human: “send this as me”, “update my records”, “create a ticket from my account”, “book something using my company profile”.

This is relatively simple when the user is present and logged in. The real challenge is situations, apps and systems where the user is not logged in themselves, or not actively involved. The agent still needs the ability and the right to do things for the user, even when the user is away.

So the core question is: how do you give an agent the ability and the right to act on behalf of a human, without handing over your entire digital identity?

Today, the practical answer is often to share secrets. That might mean sharing an API key, sharing a password, or issuing long-lived refresh tokens that never really expire. These are used so the agent can log in to systems “as” the user, or as a shared technical user, and perform actions in their place.

These approaches are convenient and easy to implement, but they come with a lot of risk. One leaked API key or password can give access to everything that identity can reach. Long-lived refresh tokens become permanent backdoors into systems. Secrets spread into config files, logs and chat messages. It becomes hard to know who actually did something: was it the human, the agent, or someone misusing the same credentials?

There is also an operational problem: it is difficult to rotate these shared secrets without breaking many things at once, and access is rarely fine-grained. If you share a password or a broad API key, the agent basically gets “all or nothing” access. That does not match how we would like to think about trust, responsibility and control.

This shows that we need better ways to handle identity, access and delegation for agents. Instead of asking “how do I share my password with the agent?”, we should ask “how do I delegate a specific, limited set of actions to this agent, on my behalf, in a safe way?”.

A better approach would treat the agent as having its own identity, separate from the human. Access should be limited to what the agent actually needs to do: which systems, which resources, and which operations. Delegation should be explicit: the human grants the agent permission to act on their behalf, with clear limits and an expiry time. It should be easy to revoke this delegation later. And there should be good audit logs that show which agent did what, on behalf of which user.

Some of the building blocks already exist in identity and access systems: scoped tokens instead of long-lived refresh tokens, service identities for non-human actors, policy engines that can express what an agent is allowed to do. The missing piece is often using these tools to model agents and delegation properly, instead of falling back to shared secrets.

If we want agents to safely act on behalf of humans, especially in serious systems, we need to move away from sharing API keys, passwords and long-lived refresh tokens. We need better ways to handle identity, access and delegation that reflect what is really happening: a human asking an agent to act for them, under clear and limited conditions.