Skip to main content
In an agent PoC, it’s tempting to reuse the credentials at hand, whether a personal access token or a Machine User’s API key. Many implementers choose this path because it’s fast to build. But credentials shared by multiple users through an agent, that is, shared credentials, are also what breaks access boundaries.

​
Reusing personal tokens

Using your own token or API key while building and testing an agent is common. As long as you run it under your own authority, nothing goes wrong. But once you open that agent to other people, its users access services with the implementer’s own permissions and can read, update, and delete resources permitted only to that person or their team. With the spread of Context Engineering, agents now connect to many services to gather more context. Sharing a token that carries an individual’s permissions with multiple users through the agent leads to the Confused Deputy Problem.

​
What it takes for a Machine User to work

The next choice after a personal token is a Machine User or a service account API key. These are widely used as machine identities that belong to no individual, and a Machine User is safe to use as long as its permissions stay within the intersection of the permissions every user of the agent already holds. If a user can exercise permissions through the agent that they don’t hold themselves, that’s the Confused Deputy Problem. Build an MCP server for an internal knowledge base on a Machine User with organization-wide read access and open it to all employees, and an employee in another department can reach documents their own account is barred from viewing through that server. So confirming at rollout that the Machine User’s permissions are a subset of every user’s isn’t enough. You have to follow transfers, departures, and permission changes, and keep auditing.

​
The actor missing from audit logs

Operations performed by a Machine User appear in the third-party service’s audit logs as that Machine User’s actions, and the context of who initiated them drops out of the logs. Use a Machine User for code changes or for viewing and editing sensitive data, and after an incident you can’t trace who did it. An agent running on a Machine User has to treat its own usage logs as audit logs, not mere access logs. Record who ran the agent, when, and with what instructions, in a form you can correlate with operations on the service side, and preserve it long-term in a tamper-proof format.

​
The trap of manual permission grants

Operating a Machine User carries one more trap. One user wants the agent to read a space only their team can view or a page only they can see, and grants the Machine User access by hand. Unintended invitations can follow, into a private space in a document tool, a restricted project in a ticketing tool, or a private channel in a chat tool. At first glance the grant matches the grantor’s own permissions. But because the Machine User’s permissions are shared with every user, resources that should be invisible to the other users become reachable through the agent. This is why continuous permission review is the countermeasure. Confirming the subset at rollout isn’t the end; inspect the Machine User regularly for permissions no one intended to add for building detection and remediation into your operations.

​
The way out of shared credentials

Running shared credentials safely means carrying three burdens for good: maintaining the permission intersection, audit logs that patch attribution, and detecting manual grants. Instead, have each user go through an OAuth flow to obtain a token guaranteed to be a subset of their existing permissions, and restrict its use to the requester through a Token Vault.

​
References