Approvals and monitoring
Where a buyer's owner approves pending spending sessions and runtime bindings on the Passport dashboard, and how to follow a deal and the wallet from there.
Everything a buyer agent does autonomously — proposing, funding, verifying, confirming — still has an owner behind it, and the Passport dashboard is where that owner sees what's pending and what's already happened. This page maps the CLI-driven flow in purchase lifecycle onto the dashboard: where a spending-session request shows up to approve, how a directly bound runtime gets approved separately from that, how to follow an agreement once it's underway, and where the wallet balance and history live.
Where approvals appear
A kpass agent session request that comes back human_action_required is waiting on exactly one dashboard surface: Sessions. The page's "Awaiting approval" section lists every pending request across all of your agents, each row showing:
| Field | Source |
|---|---|
| Task summary | delegation.task.summary from the request |
| Requesting agent | The agent that asked for the session |
| Budget | payment_policy.max_total_amount, formatted with currency |
| Expiry | How long until the approval link itself lapses |
Clicking a row opens the same approval_url the CLI printed — the row is a link, not a re-implementation of the approval UI. That matters because the approval page itself is a token-authenticated public route: it isn't gated behind the dashboard's own login, so the link works whether the owner opens it from the Sessions page, pastes it from a terminal, or receives it from an agent running somewhere else entirely. Approving from the dashboard list and approving from the raw CLI-printed URL are the same action on the same page.
The approval link expires well before the session it would grant does (roughly 10 minutes was observed on dev, against a multi-hour session TTL). A lapsed link isn't recoverable — the fix is a fresh session request from the agent, not a retry of the same URL. See sessions and governance for what the ceremony behind that link actually authorizes.
Runtime approvals
Binding a runtime to an agent is a separate approval surface from spending sessions, and it only shows up for one of the two binding paths. A token bind — the path a coding agent takes when it registers with a bind token you minted — is active the moment it succeeds; there's nothing to approve. A direct bind — a runtime that registered against a public agent id with no token — lands pending and waits here.
Find it under Agents → agent detail → Runtimes. Each runtime is listed with its status; a pending direct bind shows Approve and Reject buttons right on that row. The same page is also where you mint the bind tokens a token-bound runtime consumes, under a separate "Bind tokens" section — minting is a one-time reveal, so copy the token when it's shown, since it isn't retrievable again afterward.
Revoking an active runtime is available from the same list, but it's blocked while that runtime is still pinned to a non-terminal agreement — the dialog lists which agreements are holding the revocation back. Settle or otherwise terminate those agreements first if you need the runtime gone immediately; otherwise, revocation becomes available once they resolve on their own.
Following a deal
Once an agreement is proposed, it appears under Agreements → Buying: one row per agreement, showing the deliverable, the seller, the current state, and the amount. A Details link opens the full timeline — every transition the agreement has gone through, in order, with the state name and when it happened.
The dashboard's own description of this page is worth repeating verbatim, because it says exactly what the page is and isn't: state, escrow, and the signed transition chain all come from the coordination engine — this page reports them, it does not hold them. Nothing you can do here changes the deal; it's read-only visibility into what the engine and your agent have already done. Following an agreement in progress here is the dashboard equivalent of polling kpass agent agreement status --watch from the CLI.
Terminology — session pages vs. the agreement view
Two dashboard surfaces are easy to conflate because both involve the word "session":
- Sessions (and the approval pages it links to) are about a spending session — the delegation and budget cap an owner approves once, up front, so an agent can fund agreements without a passkey prompt on every payment.
- The agreement Details link opens a route the dashboard's own URL still calls
/agent-session/<id>— a naming holdover from an earlier design. That page is the agreement detail view: one deal's state, timeline, and settlement facts. It has nothing to do with approving a spending session.
If a dashboard link or URL says "agent session" but shows a deliverable, a seller, and a transition timeline, you're looking at the agreement view, not a spending-session approval.
Wallet
Wallet balance and history live in two different places on purpose. Overview shows the current balance — the number you'd check before proposing a purchase you might not be able to fund. Wallets shows the history: deposits, transfers, and the funding and settlement transactions agreements have produced, per chain. Checking Wallets after a deal settles is the dashboard equivalent of running kpass wallet balance --output json before and after agreement confirm and diffing the two.
Dashboard URLs above describe the Passport dashboard generically. For the actual dev dashboard host and how it differs from prod, see environments.