Kim Maida and Mason Egger: Secure Agent Access and Durable Execution

Kim Maida of Keycard and Mason Egger of Temporal introduce a workshop on building agents that can access resources securely and continue working through failures. Maida begins with identity and authorization; Egger later demonstrates durable execution.

Maida says a common pattern is to give an agent an API key. That credential may not identify the user or the agent, and the agent inherits all permissions attached to the key. Adding a human approval step everywhere is not a complete answer: humans make mistakes and many agents need to run autonomously.

Keycard's approach uses OAuth token exchange. First, an authorization server verifies the user, who consents to delegate a subset of their permissions. The resulting token identifies the user and the level of access granted. That initial consent narrows what the agent can do on the user's behalf.

The workshop uses an Expense Desk application containing a LangChain agent. Its MCP client sends proposed tool calls to an expense MCP server, which connects to a ledger API and database. The runtime sends a prompt to the model, dispatches its proposed calls, returns results to the model, and repeats until the agent answers.

The user's token becomes the subject token: it identifies the person for whom the agent acts. The Expense Desk app is an OAuth client capable of requesting an exchange, while the MCP server can request a further exchange for the ledger API. Equivalent clients could be a gateway or a wrapper around a coding agent.

When the agent proposes a tool call, the application authenticates to Keycard's security token service using client credentials or a workload identity. It presents the subject token and asks for access to the MCP server for the particular call. The request combines the agent's identity, the user's identity and the access the user delegated.

The service evaluates the request against policy: who is requesting access, for whom, to which resource and for what purpose. If the chain and requested access satisfy policy, it issues a short-lived token for the MCP server. Maida says the token normally expires in minutes and should not be stored.

The MCP server validates the token, authorizes the tool call and requests a second exchange for the ledger API. Keycard applies policy again and issues a token scoped to the downstream resource and call. The server uses that credential to invoke the API and discards it after the call; the result travels back up the agent loop.

The speakers use a shared workshop environment to demonstrate an expense-approval agent. Initially there is no login and users access a shared MCP server with API keys. The expense desk lets participants submit and approve expenses, but its activity log cannot reliably attribute those actions to a person or a distinct agent.

Maida submits a $75 snack expense and approves another expense. The activity records show access through an API key rather than a meaningful identity for the submitter or approver. A text statement that someone performed an action would not by itself establish who actually authorized it.

The next step is to give the agent an identity. In Keycard, applications are registrations that can request tokens, and resources are recipients of tokens; the same component may be registered as both. Maida registers the Expense Desk agent application and separately registers the agent as a resource that can receive the sign-in token.

Maida associates the resource with the application so the application can exchange sign-in tokens addressed to it. She then declares the agent's dependencies: the agent resource, the preconfigured expense MCP server, an LLM API credential held in Keycard's vault, and a user-info endpoint.

The demonstration gives the agent a client ID and secret and places them in the local sandbox configuration. Maida explicitly distinguishes this workshop shortcut from production: a workload identity or a mechanism that injects credentials dynamically can avoid keeping a secret on disk.

With the registrations in place, the application code must actually request exchanged tokens. Maida opens a workshop checkpoint whose MCP tool set uses the Keycard SDK to request a token for each tool call, with access narrowed to the call being made.

The minting function handles the case where there is no signed-in user: the agent authenticates with a client-credentials grant and acts as itself. After switching to the new checkpoint and restarting services, Maida asks the application which identity is in use and what approval limit it has.

The demo identifies the Expense Desk agent and reports its $50 approval limit. Maida asks it to file a $75 expense, mentioning that it is on her behalf. Because no human has signed in, the activity record attributes the filing to the agent; the words in the prompt do not prove a user's identity.

In the audit log, Maida finds the credential issued to the agent for the MCP resource using client credentials. She then examines the second exchange: the MCP server requests access to the ledger API on the agent's behalf. The delegation chain records both the requesting application and the downstream resource.

An agent can act as itself or act on a human's behalf without impersonating that human. Maida adds user sign-in so that an action can be attributed to a specific agent acting for a specific user with that user's delegated permissions.

After signing in, the application recognizes Maida's human identity and reports her $100 approval limit. Historical records created with API keys remain attributed to those keys; adding identity does not retroactively reconstruct who acted. The agent can still act under its own identity when appropriate.

Maida submits a $30 office-supplies expense. The activity shows that the human filed it and the agent approved it under its own authority, because the amount falls below the demo's $50 threshold. The record distinguishes the two actors and includes the reason for approval.

A $75 expense exceeds the agent's autonomous approval limit, so it stays pending for human review. When Maida asks to approve her own expense, the demo refuses and requires another reviewer. The distinction is possible because the application knows the identities involved; it then records a rejection of someone else's expense under her identity.

The Keycard audit view shows the first hop: the agent application requests an MCP credential while acting for the signed-in user. On the second hop, the MCP server requests a ledger credential on that user's behalf. Maida explains that the same session identifier can be used to follow the sequence across both exchanges.

Egger takes over to address a different part of the architecture: how to keep agents running reliably through failures. He describes Temporal as a durable execution framework that maintains execution state and can reconstruct it after failure, with retries and other failure-handling mechanisms for distributed calls.

An agent loop repeatedly calls models and external tools, so it faces ordinary distributed-systems problems as well as model-specific ones. In Egger's example, the parent agent process is a Temporal workflow and individual tool or service calls are activities. An activity can fail and be retried according to the workflow's policy.

The settlement workflow invokes activities such as debiting the ledger and marking an expense settled, with a timer to simulate a wait. The code uses a Keycard-provided interceptor around an activity: it obtains the identity and permission needed when that activity executes, allowing identities and scopes to be separated for workers.

Temporal uses a worker-service model. The service tracks workflow execution and state, while workers execute the actual code. Egger starts a worker and invokes a settlement; the worker logs the activity and token issuance while the Temporal interface shows the running workflow.

He kills the worker in the middle of the settlement. The running process disappears, but the execution history records the completed debit and its result. After a timeout, he restarts the worker. Temporal reconstructs the workflow from its history and continues from that point, without repeating the completed activities or LLM calls in this demonstration.

Durability matters because agent loops can involve many external calls and expensive model tokens. Without persisted execution state and recovery logic, a failure late in a long run can waste completed work. Egger says recovery can be transparent to a user if the interruption is short enough, though a longer outage can still be visible.

The credentials used by this example are not placed in the Temporal event history. Egger inspects the recorded activity results and explains that Keycard's interceptor supplies credentials just in time rather than persisting them in the workflow history. This is a design property of the integration, not a guarantee that arbitrary application data is never recorded.

For other sensitive payloads, Egger describes Temporal's payload encoding and encryption option: an application can arrange encryption and control its own keys before data reaches the service. He closes by positioning the components together: identity and scoped authorization control access, while durable execution helps the agent continue after failures.