Give agents a token per call, not a standing key, to limit what a mistake can reach

Kim Maida of Keycard argued on the AI Engineer show that AI agents should not hold standing API keys. A key hands an agent all its permissions, all the time. She said each action should instead get its own token, issued for that action alone.

What was said

Maida described the usual setup, where teams give agents API keys to reach resources. She named three problems. The key is not tied to a user or an agent. The agent gets unrestricted access to everything the key allows. And review by people cannot cover every step. In her words, "we can't just sort of stick human in the loop everywhere because humans make mistakes too, and many agents also run autonomously."

Her fix is token exchange, an open standard from 2020 that extends OAuth 2, a widely used permission system. The user logs in and agrees to hand over only some of their permissions. When the agent wants to use a tool, it shows its own identity and the user's token. It then asks for access to that one call. A policy checks who the agent is, who it acts for and what it requests. If everything fits, a token is issued.

Maida said: "This issued token expires within minutes, and you should never store it." She added that the tool server makes a second exchange for the downstream service. It then discards that token once the call ends. She built this live on an expense-approval agent.

Why it matters

A standing key turns an agent's error, or a hijack of the agent, into whatever the key can do. Our reading: a token for one call makes a single action the unit of damage, instead of a whole account.

Maida also stressed records. In her demo, the old setup could not show who approved an expense, because all anyone had was an API key. She said the log should name both the agent and the user it acted for. For anyone buying agent software, our reading is that this is a fair question to put to vendors. Whose identity shows up when something goes wrong?

The other side

The excerpts show a workshop demo in a sandbox, not a production system. They do not say what it costs to write and maintain the policies. They do not say how much delay the extra exchanges add. They also leave open what happens if the service that issues tokens fails.

A token that lives for minutes can still be used during those minutes. The argument is that this narrows the risk, not that it removes it. Maida also said people cannot review every step. Beyond policy, the excerpts do not say what should stand in for that review.