Who Is Making This Request? Agent Auth 101 - Kamil Potrec, Keycard

A familiar agent architecture connects a user, a model and tools. The less familiar part is the trail of credentials that makes those connections possible. Kamil Potrec, a member of Keycard’s product team, begins there: before asking what an agent can accomplish, ask which identity each service sees when it receives a request.

The credentials serve different purposes:

• User-to-agent access: A personal access token, or PAT, identifies the user accessing the agent. A locally running agent may skip this authentication step.
• Model access: The agent needs its own API key to call the model provider and run its reasoning loop.
• Tool access: A remote Model Context Protocol (MCP) server may receive the user’s forwarded PAT, an agent’s static key or a dynamically obtained OAuth credential.

These are separate connections. Authenticating one of them does not establish who is acting across the rest of the chain.

If the MCP server receives Alice’s token, it usually sees Alice. It cannot distinguish an agent from Alice’s command-line client or another tool using that credential. The server may then wrap an internal API, a database or an external system. To serve multiple users, these wrappers often use service accounts that collect the backend permissions they need. The result is a chain with user identity at one connection and a broad service identity at another, without a distinct identity for the agent making decisions.

What changes when the model reads a tool result? In Potrec’s hypothetical invoicing example, Alice asks the agent to inspect a recent invoice. The service returns an invoice marked pending, with text saying it should be sent to the user. That result goes back into the reasoning loop. A malicious or simply over-helpful agent decides to send the invoice. An inspection has become an action, yet the receiving service still sees the credential used on the request. The example exposes the missing distinction: Alice asked to look; the agent decided to send. A user token alone does not preserve that difference.

The attribution problem comes with an exposure problem. Alice can copy a reusable access token onto a personal machine, moving it outside the corporate environment that previously protected it. In the arrangements Potrec describes, revoking these scattered credentials is difficult. As an agent gains more capabilities, it receives more keys; as an MCP server serves more backends and users, its service account accumulates more permissions. Neither collection necessarily reflects the narrow task currently underway.

Traditional service-to-service software already had these weaknesses. Teams accepted some of the risk because developers controlled the application’s released behavior. An agent adds another actor that can choose its next action after reading new data. Giving that actor access to a credential lets it use the credential’s authority, even when its interpretation of the task has drifted.

Potrec’s analogy is the unlocked work laptop: a colleague opens Slack and posts, “I’m buying donuts for everybody today.” The session makes the message look like yours, although somebody else chose to send it. The usual response is to lock the laptop. Handing an agent your reusable credentials recreates the same mismatch between the account named on an action and the actor that chose it.

The proposed replacement starts by removing the manual token hunt. An agent service advertises how clients can obtain authorization. A client discovers those requirements and requests access from an external authorization system, rather than asking Alice to find a token and paste it into configuration. OAuth supplies a way to obtain dynamic credentials scoped to the interaction and the tool using them, with a limited lifetime.

The agent must also authenticate before receiving credentials. Potrec names workload identity federation, private-key authentication and certificates as possible mechanisms. The choice depends on the system; the essential requirement is that software prove its identity instead of acquiring authority merely because somebody placed a secret in its environment. This separates identifying the agent from deciding what access to issue it.

The same pattern can repeat at the next service connection: determine the required authorization, obtain an appropriate token and then make the request. That replaces a service account’s growing collection of persistent permissions with access obtained when it is needed. The model’s reasoning loop changes which requests the agent chooses; it does not require inventing a different authentication foundation for every connection. Outside that loop, the agent and the legacy application are both software clients.

One client and one authorization server make this sound straightforward. An enterprise may have hundreds of APIs with different authentication systems, agents it builds and agents it buys, and software it cannot modify. Requests can also pass through multiple agents or hubs. Delegation must survive those hops, while thousands of users need a meaningful way to authorize what agents do for them. Solving token acquisition for one service leaves most of that coordination untouched.

The first requirements describe the actor and its authority:

• Separate agent identities: Issue an identity per agent, potentially per session, distinct from the person who launched it.
• Explicit delegation: Express which users may use an agent and which agents may act on a user’s behalf. Delegation must remain understandable when agents call other agents.
• Scoped, short-lived credentials: Issue access for the work being done rather than handing the agent a master key that unlocks everything.

Together, these let a system distinguish the agent making a request from the user whose authority it is exercising.

Existing systems require two complementary bridges. Identity federation establishes trust across systems so they can accept identities rather than each maintaining an isolated account universe. Legacy credential brokering handles services that will not support OAuth: an adapter obtains or exchanges their existing credentials just in time. Federation does not magically modernize every backend, and a broker does not eliminate the need to identify the caller.

Policy determines which actions may run automatically and which need human approval. Audit records who authorized a request and which actors made it possible. These controls address the invoice problem at different points: policy can constrain an action before execution, while audit preserves the authorization trail afterward. That trail establishes actors and grants; it should not be confused with proof that the user intended every decision the model made.

Even one agent-to-MCP interaction contains several security operations. The server first publishes its access requirements; the client discovers them. The agent then obtains credentials and authenticates to the remote server. Discovery answers how to request access. Possessing a credential is only the next step, not the end of the server’s responsibility.

What does the server have to check before allowing the request? It must verify the credential’s signature, establish that the issuer is trusted and validate the token. It then applies current policy. If fulfilling the tool call requires another external system, the MCP server may need to obtain another credential for that connection. Every one of these actions must enter the audit log; audit spans the process rather than existing only as a final success message.

This sequence makes the implementation burden visible: client discovery and credential acquisition differ from server verification and enforcement, and a downstream connection can introduce another credential exchange. Potrec asks whether an LLM can perform all of this perfectly every time. His answer is to put the machinery into reusable, reviewed libraries, middleware and SDKs rather than relying on the reasoning loop to reconstruct security procedures for each request.

Shared code solves part of the problem, but distributing it creates familiar operational work:

• Adoption coverage: Every relevant application must use the library; gaps leave inconsistent controls.
• Language coverage: The organization needs implementations for its different languages, including older systems.
• Unmodifiable agents: A purchased agent may not allow the changes an SDK integration requires.
• Patch distribution: Fixing a library bug is insufficient until teams identify its consumers and update them.

Writing the SDK is easier than ensuring every request uses the corrected version.

Agents add a more fundamental limitation. An SDK may cache and manage credentials correctly, yet the secrets still live inside the agent’s execution environment. An over-eager or manipulated agent that discovers a usable credential may try to use it outside the intended client-side path. Improving the library does not, by itself, move that credential out of reach.

This is the distinction behind Potrec’s rejection of SDKs as a complete solution. They remain useful for discovery, token handling and service authentication. They do not provide credential isolation merely by being SDKs. If keeping downstream secrets away from the agent is a requirement, enforcement needs to move outside its execution environment.

The gateway design moves downstream credentials into a separate runtime authorization and vaulting service. The agent requests access to a target such as GitHub through the gateway. The gateway authenticates the caller, consults the authorization system, checks policy and retrieves the appropriate credential. It injects that credential into the outgoing request and forwards the request to GitHub.

Where does the secret travel? The topology below separates the agent’s request path from the credential exchange. The downstream credential moves from the authorization service to the gateway and then accompanies the forwarded request; it is not handed to the agent. That protection assumes the gateway and authorization service remain uncompromised. The gateway still has to authenticate the agent, so this design hides the downstream credential rather than making all authentication credentials disappear.

Being on the request path adds controls beyond secret storage:

• Revocation at the next check: A short-lived token remains usable until it expires unless something stops it sooner. If all relevant communication passes through a gateway that checks every request, the gateway can deny subsequent requests immediately after access is revoked.
• Narrower actions than the backend token permits: A legacy service may offer only coarse permissions such as admin, read or write. The gateway can inspect the requested operation and allow reading email while blocking sending, even when the underlying credential is broader.
• Request visibility: The gateway can observe the traffic passing through it without requiring changes to the downstream service.

These benefits come from mediating requests, not merely keeping a token in a vault.

The extra hop adds latency. More importantly, the control works only if agents must use it. Without strong network controls, an agent may bypass the gateway; local tool execution may never cross it at all. Request-level restrictions therefore depend on the paths the gateway can actually mediate. Installing a proxy does not automatically contain everything an agent can do.

A gateway also leaves the identity problem to be solved. Agents still need credentials that identify them to it. Meanwhile, concentrating downstream credentials at one component makes that component an attractive attack target. Intercepting traffic brings technical complexity, including TLS handling and compatibility with the systems being connected.

Someone must configure routes, policies and connectors, decide whether agent A may talk to agent B, and operate the infrastructure. The tradeoff is concrete: a gateway moves credential use and enforcement outside the agent, but introduces a network service whose security, availability and configuration become part of the system’s responsibilities.

Keycard’s proposed answer is a shared control plane for agent identities, token issuance, identity federation, policy and audit. Potrec describes client SDKs for discovery and credential injection, service SDKs for authentication, and an optional gateway for teams that need external request controls. The pieces can be selected for a chat application or a larger orchestration platform rather than requiring every application to adopt one architecture.

That combination also clarifies why the earlier SDK criticism matters: SDK integration and gateway enforcement solve different parts of the problem. Reusable code can handle protocol mechanics; a gateway can keep downstream credentials outside the agent’s environment. Neither removes the need for separate agent identity, explicit delegation or policy. Choosing an integration point is a decision about where controls run, not a substitute for deciding what authority the agent should have.

The closing advice is deliberately blunt: agent authentication is no longer optional, use open standards so systems can work together, and “don’t YOLO it.” Generated security code still needs security review. The point of taking these operations out of the reasoning loop is lost if their implementation is accepted without checking whether it actually enforces the intended controls.

Potrec closes by pointing to Agent Baseline and its software-factory work. The linked project provides a practical vocabulary for a security review: discover agents and dependencies, constrain their reach, authorize actions, observe activity, validate outcomes and respond when something goes wrong. Its Secure Software Factory reference architecture applies that baseline to agents that ship code. Although the talk calls the software-factory work a reference implementation, the supplied project description identifies it as a reference architecture; treat it as design guidance rather than evidence of a complete runnable security stack.