Each hop an AI agent takes needs its own short-lived, scoped permission

Agents should not hold shared API keys. Each step they take should carry its own short-lived pass, issued for that step alone. Kim Maida of Keycard made this case in a workshop on the AI Engineer show, alongside Mason Egger of Temporal.

What was said

Maida built an expense-approval agent live. It started with no login, and everyone using it shared one API key. That left a gap. A speaker on the show described it: "I approved it, but we also don't have any record of who approved it either because, again, all we have is an API key."

The fix was token exchange, where a program trades one credential for another. The user signs in. The agent sends that sign-in token to Keycard. Keycard swaps it for a token for the expense tool server. That server is an MCP server, which gives an agent a defined set of tools. The tool server then makes a second swap, for a token to reach the ledger API.

At each hop, Keycard checks policy. It then issues a credential scoped only to what that one tool call needs. The tool server discards the token when the call ends. A shared session number lets you trace the hops. A speaker on the show said the record should not simply name Kim. It should show that an agent acted for Kim, within Kim's own access.

Why it matters

Our reading: when an agent calls a tool server that calls an API, permission passes down a chain. That chain is where trust now sits. With one shared key, the whole chain collapses into a single secret. That secret says nothing about who used it.

For buyers, the workshop suggests questions to ask vendors. Does each hop get its own narrow token? Do the logs name both the agent and the person it acted for? For builders, it suggests treating those answers as part of the design, not as an audit extra.

The other side

This was a workshop demo. It ran in a sandbox on an expense app. It used Keycard's own product, with a shared Keycard organisation for attendees. The excerpts give no data on how many real tool servers support token exchange.

Maida mentioned gateways and wrapper tools as ways to add token exchange to third-party servers. The excerpts show only a custom app that does it. The design also puts one exchange service at the centre, deciding policy at every hop. The excerpts do not say what happens if that service fails or its policy is wrong.

A speaker also noted that human approval cannot cover everything. People make mistakes, and many agents run without supervision. The workshop offered tighter identity and scope as the answer, not proof that the problem is solved.