Agent Auth Is a Gateway Problem, Not a Token Problem

The problem. Modern agents often borrow user credentials without attribution, making every action ambiguous. Kamil Potrec from Keycard points out that when an agent fetches an invoice and then sends it, it's unclear whether the user or the agent initiated the action. This loss of attribution is the core security gap.

Why it matters now. Before agents, software was deterministic and we accepted risk via service accounts. Agents are not deterministic; they can be 'too helpful' or manipulated. Potrec compares this to leaving a laptop unlocked — agents effectively do that continuously. This changes the threat model fundamentally.

The proposed fix. The talk advocates moving from static tokens to dynamic, scoped credentials using OAuth and workload identity. Agents should authenticate separately from users, and each interaction should get a short-lived token. This pattern exists in traditional systems but hasn't been applied to agents.

The scaling challenge. Real systems have hundreds of APIs, legacy auth, and multiple agent hops. Each interaction needs delegation semantics and policy enforcement. Potrec notes that we cannot rewrite everything; we need a federated trust layer and a broker for legacy credential exchange.

Gateways as enforcement. To keep credentials away from agents, a gateway can intercept requests, fetch the right credential, and enforce policies. This provides instant revocation and request-level attenuation (e.g., allow read but block send). The cost is added latency, a single point of failure, and the need for strong network controls.

The vendor's answer. Keycard offers a control plane that combines agent identities, policy, audit, and gateway capabilities. The talk ends with a call to adopt these patterns and use open standards. While the problem analysis is sound, the solution is presented as a product, and no independent validation is given.