Stop Giving Your AI Agents API Keys with Kim Maida, Keycard & Mason Egger, Temporal

Building production-grade autonomous agents requires two complementary layers: fine-grained, auditable identity and access delegation (via Keycard's OAuth2 t

Identity Delegation and Durable Execution in Autonomous Agent Architectures: An Analysis of Keycard and Temporal

Abstract

Autonomous agents built on Large Language Models (LLMs) are increasingly granted direct access to production resources through static API keys, a pattern that provides neither attribution nor least-privilege enforcement. This synthesis analyzes a workshop implementation addressing two orthogonal failure modes in agentic systems: identity delegation via OAuth 2 Token Exchange, as implemented by the Keycard platform, and durable execution via the Temporal framework. The analysis finds that per-tool-call token exchange produces short-lived, narrowly scoped credentials and a fully auditable delegation chain linking agent, user, and resource, while a demonstrated worker-process failure showed that replayed event history restores an agent loop without re-invoking the LLM or re-executing completed steps. The findings indicate that identity delegation and execution durability address distinct, non-overlapping risks and that both are necessary preconditions for agents operating with reduced human supervision in production environments.

1. Introduction

The architecture of conventional service-to-service integration rests on two assumptions that do not transfer cleanly to agentic systems. The first is that a long-lived credential may safely represent the full permission scope of an integration, since the calling service is a known, static piece of code. The second is that a failed operation can be retried from the beginning without meaningful cost. An agent, defined in this context as a control loop that repeatedly invokes an LLM and dispatches the model's proposed tool calls until the model signals satisfaction, violates both assumptions.

The first assumption fails because an agent frequently acts on behalf of a specific human user, and collapsing that relationship into an undifferentiated service credential destroys attribution. A static API key cannot indicate whether an action was taken by the agent acting autonomously, by the agent acting as a specific user, or by some other process entirely. The second assumption fails because agent loops accumulate expensive, non-idempotent state: each LLM call carries real cost, and a loop that fails after accumulating ten or twenty completed tool calls cannot simply restart without re-incurring that cost and risking duplicated side effects, such as a ledger debit executed twice.

This analysis advances the thesis that production-grade agents require two independent infrastructure layers: auditable identity delegation, which ensures the agent and the human principal behind it are never conflated or granted excess permission, and durable execution, which ensures long-running agent loops survive process and infrastructure failure without losing state or exposing secrets. Section 2 establishes the relevant protocol and architectural background. Section 3 analyzes the delegation mechanism, including its empirical demonstration across an agent-only state and a human-delegated state. Section 4 presents the durability layer and its kill-and-restart validation. Sections 5 and 6 discuss broader implications and practical conclusions.

2. Background and Related Work

The deficiencies of API-key-based agent access are threefold. First, the credential is bound to neither a user identity nor an agent identity, so individual actions cannot be traced to an originating principal. Second, the agent holds unrestricted access to the entire permission set encoded in the key, independent of the narrow task at hand. Third, human-in-the-loop review cannot substitute for fine-grained access control, both because many agents are designed to operate autonomously and because human reviewers are themselves fallible.

The relevant corrective standard is OAuth 2 Token Exchange, an open extension to OAuth 2 that has existed since 2020, predating the current wave of agent deployment. Its central construct is the subject token - a credential representing the principal on whose behalf a downstream request is made, presented alongside the requesting client's own credential, allowing an authorization server to reason about two identities simultaneously rather than merging them. The reference implementation analyzed here is an Expense Desk agent interposed, via a Model Context Protocol (MCP) server, between the user and a downstream Ledger API, with execution flowing from user prompt through the LLM to a proposed tool call, dispatched by the MCP client to the MCP server, which calls the resource API and returns a result up the chain until the model is satisfied.

3. Core Analysis

3.1 Token Exchange as a Narrowing Mechanism

The delegation chain established by Keycard begins when a user authenticates against a standard authorization server - Google, Okta, or Auth0 - and then explicitly consents to delegate a subset of their permissions (scopes) to the agent. This consent step constitutes the first narrowing of access: the user's full permission set is never transferred wholesale. The resulting token identifies both the user and the granted scope, and becomes the subject token for all downstream delegation.

When the agent proposes a tool call, the OAuth client authenticates to Keycard's security token service using client credentials or workload identity, presenting the user's subject token alongside its own. Critically, the exchange request asks for access to exactly one downstream tool call, not a blanket grant. Keycard's policy engine evaluates three facts before issuing a token: the identity of the requesting agent, the identity of the user on whose behalf it acts, and the level of access that user granted at consent time. If these satisfy policy, Keycard issues an access token scoped only to that specific MCP server call. This token typically expires within minutes and is explicitly intended never to be stored.

3.2 Multi-Hop Delegation and Auditability

The narrowing does not stop at the first hop. The MCP server, upon receiving its scoped token, performs a second token exchange to obtain a separate token scoped specifically to the Ledger API, discarding each token immediately after use. The result is that every individual tool call - not every session, not every agent invocation - triggers its own freshly scoped token request. This produces a full delegation chain traceable across hops via consistent session identifiers in Keycloak's audit log, recording the actor application, the on-behalf-of identity, and the target resource for each exchange.

3.3 Empirical Demonstration: Agent-Only vs. Human-Delegated States

The workshop's live demonstration contrasted three states. In the initial state, all participants shared a single API key and MCP server, making it impossible to determine who created or approved any given expense filing. After registering an agent as both an application (able to request tokens) and a resource (able to receive tokens), and attaching a client ID/secret, the agent acquired its own identity via the client credentials grant - but absent a subject token, it could only act as itself. It could approve expenses under its configured $50 auto-approval limit, but filings recorded the agent's own action, not an action taken on the user's behalf. Only after adding human sign-in, so that the agent exchanges the user's subject token for an MCP token, did the system preserve the user's identity through the full chain without impersonation. A direct behavioral consequence followed: once identity was established, policy prevented the agent from approving or rejecting expenses it had itself filed, forcing escalation to a separate human reviewer - a control that was structurally impossible in the shared-API-key state.

4. Technical Insights

Several implementation details carry direct operational relevance. The demo configured asymmetric approval limits as identity metadata - a $50 auto-approval ceiling for the agent versus a $100 ceiling for the human user - illustrating that policy can differentiate principals within a single delegation chain rather than treating "the integration" as monolithic. Secrets management is handled via a Keycard vault that stores the LLM API key and other credentials outside the agent's local disk, with workload identity recommended over stored client secrets in production.

On the durability side, Temporal structures execution as a parent workflow function, instantiated once per execution, calling child activity functions representing individual tool calls expected to fail and be retried. This is a code-first model: workflows and activities are ordinary Python functions annotated with decorators, including configurable retry policies. Interceptors - hooks firing at defined points in execution - allow Keycard's grant_resource decorator to fetch identity and permission information from Keycard immediately before an activity executes, integrating the identity layer directly into the durability layer without requiring tokens to be persisted.

In the kill-and-restart demonstration, a worker process (PID 572) was terminated mid-settlement and restarted within approximately five seconds. Temporal replayed the full event history and resumed exactly where execution had stopped, without re-invoking the LLM or re-executing already-completed activities. Inspection of the event history JSON confirmed that while activity results (such as a debit_ledger output) are persisted, no JWT or token material appears in that history - a property achieved either through just-in-time credential injection via interceptors, as Keycard implements, or through a payload encoder/sidecar pattern that encrypts all data sent to Temporal under keys controlled entirely by the user.

5. Discussion

The two layers examined here address failure modes that are structurally independent. Identity delegation answers "who is permitted to do this, and on whose authority," while durable execution answers "how does this survive if the infrastructure underneath it disappears mid-task." A system with only the former remains fragile to process crashes and expensive LLM re-invocation; a system with only the latter remains an unaccountable black box with respect to who authorized any given action. The workshop's framing of agents as "distributed systems with an added layer of thinking" is notable in that it argues no novel failure-handling theory is required - existing distributed-systems patterns (retries, replay, scoped credentials) apply directly once agent loops are recognized as multi-hop, failure-prone call chains.

An open question not addressed in the source material concerns the performance and latency cost of per-tool-call token exchange at scale, particularly for agents issuing dozens of tool calls per task; the short token lifetimes (minutes) that enable security also imply exchange overhead on a frequent basis. Similarly, while Temporal's integrations with OpenAI, Pydantic AI, and LangChain are noted, the maturity and feature parity of an "emerging agentic harness" remains unspecified, suggesting this tooling layer is still consolidating.

6. Conclusion

The central contribution of this analysis is the demonstration that identity delegation and execution durability are complementary, not substitutable, requirements for production agents. Token exchange converts a single shared API key into a traceable, minutes-lived, per-call credential chain that enforces least privilege and enables policy decisions - such as preventing self-approval - that are impossible under static credentials. Independently, durable execution ensures that the expensive, stateful work of an agent loop survives process and regional failure without secret leakage or redundant LLM spend. For teams building autonomous agents against production APIs, the practical takeaway is to treat these as two separate build-or-buy decisions rather than conflating access control with reliability engineering.

Sources

• Stop Giving Your AI Agents API Keys - Kim Maida, Keycard & Mason Egger, Temporal - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub