Sabitlenmiş Tweet
Today, we generally rely on two approaches to authentication and authorization for agents.
Agent acts on the human's behalf
The human authenticates with a service to grant access to the agent or its tools, so that the agent can act on the human's behalf. Actions against the service are seen as actions by the human's identity.
3-legged OAuth is Authentication Code Flow (ideally + PKCE as the most secure option). It enables the end user to authenticate to use the target API and grants the MCP server permission to exchange the authorization code (the MCP server needs to implement the callback from the Authorization Server) for the end user's access token and call the API using the user's access token. The user experience would be like: `codex mcp login my-mcp`.
Alternatively, services generate an access token or API key directly and the human gives the API key to the agent. Many services use this approach today for simplicity.
Agent acts using its own identity on everyone's behalf
An administrative user creates a service account unique to the agent or tools. End users use those tools via the agent, but the tools are acting with the service account's identity and authorizations. The service account's permissions are applied uniformly for all end users. This is usually fine for tools that don't require special permissions per user.
2-legged OAuth is Client Credentials Flow. The MCP server acts according to its own service account to call the target API, and the API cannot enforce access control against the end user's identity. This suffers from the same limitation as a PAT or API key, which means the MCP server is only appropriate for personal deployment, not departmental (shared by multiple users).
Both approaches are flawed
In the approach where the agent acts using the human's identity, the agent has the human's full set of permissions. This is often not what the human intends. Sometimes the human wants to apply additional restrictions on what the agent is permitted to do on the human's behalf. For example, limit the agent to use read-only tools; or require review and approval when the agents wants to use a tool that writes or executes something that may be unsafe.
Is an agent service account enough? It is not sufficient. Usually, the service account is granted a set of permissions that is applied uniformly for all end users. There is usually no communication channel to involve the end user in human-in-the-loop review and approval. This is especially true if the API is responsible for access control enforcement. The API has no visibility into who originated the request to the agent that is using the API as a tool.
I don't have a solution worked out, but I think it starts with an agent having its own identity. Therefore, the service account approach is a starting point. Then we need an authorization mechanism that is policy-driven with controls specified both administratively and individually.
We need administrative control by the organization to limit all possible actions taken by the agent. We need individual control so that the human end user can apply additional restrictions. Optional HITL policies (auto-approve, deny, ask for approval) need to be controllable by the human end user within the bounds of the administrative policy.
English
