Kamil Potrec of Keycard explains authentication and authorization for agents in this 19-minute AI Engineer talk.

A user’s token hides the actual actor

  • An agent asked to inspect an invoice might decide to send it, using the same credential for both actions.
  • A downstream system sees the user’s identity, obscuring whether the user or agent initiated the action.
  • Shared service accounts accumulate permissions across users and expand the consequences of a compromised tool server.

Give agents identities and bounded authority

  • Issue each agent, potentially each session, an identity separate from the person who launched it.
  • Record delegation: which user authorized which agent to act, and which further handoffs are permitted.
  • Use OAuth, the standard for delegated access, to obtain short-lived credentials scoped to the interaction.
  • Federate identities across existing systems and broker legacy credentials where services lack modern authentication.
  • Enforce approval policies and audit who authorized each request.

Keep secrets outside the agent’s environment

  • SDKs, reusable client libraries, simplify implementation but need adoption, updates and coverage across languages.
  • A credential accessible inside the execution environment can still be copied or reused by the agent.
  • A gateway can authenticate the agent, check policy and inject a downstream credential while forwarding an approved request.
  • Inspecting requests can enforce narrower rules, such as allowing email reads while blocking sends.

A gateway needs a boundary around it

  • Force traffic through the gateway with network controls; direct connections can otherwise bypass its checks.
  • Account for added latency, availability, routing, TLS compatibility and the concentration of sensitive credentials.
  • Local tool execution still needs separate controls, and the agent still needs a trustworthy identity.
  • Revocation at the gateway depends on every relevant request passing through it and receiving a fresh policy check.
  • Keycard’s control plane combines these components; the talk presents an architecture rather than a tested security guarantee.

“Things will go wrong. … We need audit.” — Kamil Potrec, 9:40–9:44