Skip to main content

What ephemeral sessions are

An ephemeral session is a temporary agent identity that expires on its own. You create one, hand the token to an AI agent, and the token stops working when the TTL runs out or the agent exhausts its action budget, whichever comes first. The pattern is designed for computer-use agents (Claude computer use, GPT browsing, operator loops) that need just enough access to complete one task without holding persistent credentials across invocations. Key differences from a regular agent:

Setup

No extra configuration is needed, ephemeral sessions are part of the kavachos core package and share the same database as the rest of KavachOS.

Creating a session for a computer-use agent

Call createSession right before you hand control to the agent. The token is shown exactly once.
The returned token starts with kveph_ to distinguish it from long-lived agent tokens (kv_).

Validating a session

Each time the agent makes a request, validate the token before granting access.
expiresIn is in seconds. remainingActions is null when no action cap was set.

Tracking actions

Call consumeAction once per agent action to decrement the budget counter.
When actionsRemaining hits zero, the session transitions to exhausted and the underlying agent is automatically revoked.

Action limits

maxActions is a hard cap on how many times consumeAction can succeed. It is independent of the TTL, a session can expire by time with actions remaining, or exhaust its action budget before the TTL lapses. Set a tight budget for tasks with a well-known scope and leave it as null for tasks where the step count is unpredictable.

Revoking early

If the agent completes the task before the TTL expires, revoke the session manually.
Revocation is idempotent, calling it on an already-revoked session returns success.

Listing active sessions

Useful for dashboards or for building kill-switch UI.
The returned objects have token set to "", the token is never readable after the initial createSession response.

Cleanup strategies

Two approaches to cleaning up expired sessions:

Scheduled background job

Run cleanupExpired() on a cron schedule, every minute for busy systems, every 5 minutes for lighter loads.

On-demand at validate time

validateSession already detects and transitions expired sessions. For low-traffic systems, this is enough, no background job needed.

Audit grouping

When auditGrouping: true (the default), all actions within a session share the same auditGroupId. This makes it trivial to reconstruct the full activity trace for a single task.

Session status lifecycle

Once a session leaves active, it cannot be reactivated. Create a new session for a new task.

Error codes

Last modified on April 18, 2026