Kamil Potrec on Agent Authentication, Delegation and Gateway Controls

I’m Kamil Potrec, and I work on the product team at Keycard. In this short talk I’ll give a high-level overview of agent authentication and authorization: what is required, how the pieces might fit together, and where the practical problems begin.

A familiar diagram connects a user to an agent, then to MCP servers and other systems. What receives less attention is how the participants authenticate, authorize requests and establish which actor is responsible for an action.

A user may give the agent a personal access token or another opaque credential. A local agent may skip even that step. The agent also needs credentials of its own, such as an API key for a model provider, and often needs additional credentials to call remote MCP tools.

An agent might pass Alice’s token through, use its own static key or obtain a dynamic credential. If the MCP server sees only Alice’s identity, however, it cannot tell whether the caller is an agent, Alice’s command-line client or another tool.

MCP servers often wrap existing APIs, databases and external systems. To serve many users, a server may use a service account rather than a single user’s token. That account can become an aggregation of permissions, a familiar problem from service-to-service applications.

Agents add a reasoning loop. Consider a request to retrieve an invoice: the agent receives a pending invoice and decides, perhaps because it is being too helpful, to send it. Was that action Alice’s decision or the agent’s? A service that only sees Alice’s credential may not be able to tell.

There are other problems with credentials lying around. A user can copy a personal token onto an unmanaged machine, bypassing protections in corporate infrastructure. Such credentials can be difficult to revoke, and agents accumulate more keys as they gain more capabilities.

Service accounts have long been overprivileged buckets of permissions. Previously, organizations often accepted this risk because they relied on developers to release deterministic software securely. Agents introduce another actor that can use those permissions while making its own choices.

I compare this to a colleague using an unlocked laptop to send a message promising everyone doughnuts. We learned to lock the machine; with agents, we can accidentally leave credentials available to software that acts for us. Some of the technology needed to improve this has existed for years.

Instead of asking Alice to find a static token, a service can advertise how to obtain access. A client can request authorization and receive a dynamic credential scoped to a particular interaction and tool. OAuth is one technology that can support this pattern.

We also need agents to authenticate before they receive credentials. Workload identity federation, private keys and certificates are examples of mechanisms; the important point is to establish the agent’s identity. When an agent calls another service, it can discover the required authorization and obtain an appropriately scoped token.

Except for the reasoning loop, the agent and traditional application are both software, so similar patterns can be reused. The hard part is scale: an organization may have hundreds of APIs, different authorization servers and both purchased and internally built agents, some of which it cannot modify.

There may be multiple hops between agents. Across thousands of users and arbitrary actions, we need to express delegation and consent while preserving attribution: who authorized the action, and which agent decided to perform it?

A practical system needs identities separate from the users who launched agents, potentially down to a session. It also needs delegation rules, scoped short-lived credentials and no master key that gives an agent persistent access to everything.

Existing systems cannot all be rewritten. Federated trust must connect identities across services, and an adaptive broker may need to exchange legacy credentials just in time. Policies specify which actions require human approval and which agents can act automatically; audit records show who authorized and enabled a request.

Even one agent-to-MCP-server interaction has many steps. The server publishes authorization information, the client discovers it and obtains credentials, and the server validates signatures, issuers and tokens. Policy must then be enforced, downstream credentials may be needed, and the actions must be logged.

We have handled similar complexity with shared libraries, middleware and SDKs: implement the logic once, review it and reuse it. But an SDK only helps where it is adopted, and organizations need implementations for different languages and systems they may not be able to modify.

When a security bug is found, teams must update the SDK and locate every service that uses it. Agents add another concern: an agent may be manipulated or persistently try to bypass controls. If a credential remains inside its execution environment, client-side code alone does not hide it from the agent.

One alternative is to move downstream credentials into a secure vault or runtime authorization service outside the agent’s environment. The agent calls a gateway, which authenticates it, checks policy with the authorization service and retrieves the credential needed for a specific target such as GitHub.

The gateway injects the credential into the outgoing request. If the agent cannot reach the credential store or bypass the gateway, it does not need to hold the downstream secret itself. This creates a separate control point between agent execution and the protected service.

Even short-lived credentials remain usable until they expire. A gateway that evaluates each request can enforce revocation at that point. It can also narrow coarse legacy permissions: for example, allow an agent to read email while blocking a request to send it.

Because the gateway sits on the network path, it can improve visibility without changing every downstream service. But there are tradeoffs: another hop adds latency, and weak network controls let agents bypass it. Local tool execution is not covered simply by adding a gateway.

The gateway does not eliminate the identity problem: agents still need credentials to authenticate to it. It also becomes a high-value target because credentials pass through it. TLS interception, route and policy configuration, connectors and operating the gateway all add complexity.

At Keycard, we offer a control plane for agent identities, token issuance and federation, policy and audit, client and service SDKs, and an optional gateway. Teams can choose the components appropriate to their application or orchestration platform.

My closing advice is to treat agent authentication as necessary, use open standards and interoperability, and review security-sensitive code rather than assuming an LLM will implement it correctly. Keycard also points to Agent Baseline as a reference implementation for exploring these capabilities.