The Wallet Dashboard

The Wallet at wallet.alterauth.com is a hosted, app-scoped dashboard where end users manage the grants and delegated credentials associated with one Alter app. Users enter through an app-specific Wallet link and authenticate with that app’s configured identity provider. Each Wallet session is bound to both the app and the signed-in identity.

For end users, it answers three questions:

• What access does this app have? The user’s OAuth connections, managed-secret grants, scopes, status, and delegated agents for the current app.
• What did the app do with it? An activity feed showing calls made on the user’s behalf, with the application-supplied reason when present.
• How is access removed? OAuth grants and managed-secret delegations have explicit revoke actions.

For developers, it eliminates the need to build any of the above in-product.

How a user signs in

The Wallet sign-in link carries the app context. The user authenticates through that app’s Auth0, Clerk, Okta, WorkOS, or custom OIDC configuration, then sees only grants and activity belonging to that app and identity. The generic sign-in page cannot infer an app; without app context, it asks the user to return through the link supplied by the application.

There is no separate Wallet password or per-app registration form. A successful OIDC exchange creates a Wallet session bound to the resolved app user.

What an end user sees

• Dashboard — connected-account, grant, and recent-activity totals; active OAuth connections; recent activity; and a pending-approval banner when action is required.
• OAuth Connections — grants grouped by provider account, with scopes, status, last-used time, policy details, and a per-grant revoke action.
• Managed Secrets — managed-secret grants and the agents authorized through each one, with All, With agents, and No agents filters and per-delegation revocation.
• Approvals — pending and historical HITL approvals, including Approve and Deny actions while the user’s gate is pending.
• Policy — account-wide policies, connection-specific policies, and disclosure-safe inherited developer controls in one view. The connection-policy list is searchable.
• Activity — the app-scoped audit activity visible to this end user, including method, provider, status, latency, and the application’s reason when present.
• Settings — the name and email resolved from the Wallet identity.

Policy visibility and authoring

The top-level Policy page is an aggregate rather than an account-only list:

• Account-wide policies apply to every account connected directly to the signed-in user and are editable in the Wallet.
• Connection policies apply to one OAuth or managed-secret grant. They remain viewable after expiry or revocation; inactive connections are read-only.
• Inherited controls show organization, application, provider, agent, and ancestor-connection (grant) policies that also affect a connection. They are read-only and disclosure-safe: the Wallet explains the effect and condition shape without exposing developer-only approver identities or internal configuration.

Selecting a policy opens the same viewer used by the developer portal. Owned rules show complete operation and parameter conditions; inherited controls show disclosure-safe summaries instead of developer-only values. Each connection’s Policy tab also shows the effective policy chain, connection lifetime, and permission ceiling.

End users can create self-scoped narrowing rules for request-value conditions, approval requirements, time windows, quotas, and content matching. Provider-operation discovery supplies operation and parameter suggestions in the shared editor. IP allowlists and restriction rules are operator-controlled and cannot be authored in the Wallet.

What the developer configures

Branding: the Wallet shell uses Alter branding. App and provider names appear where they identify a grant or action, but app logo and color settings do not rebrand the Wallet.

Reason text: the most useful field in the activity feed is reason — the human-readable explanation of why the application made each call. Pass it on every app.request():

await app.request(method, url, grant_id=g, reason="Sync calendar events on user-triggered refresh")

Reasons appear verbatim in the Wallet. Treat them as user-facing copy.

Approvers: when an approval policy is configured, the designated approver sees a redacted request summary: method, host, path, provider, grant information, policy-evaluated operation or parameter values, and the application’s reason when supplied. The Wallet does not display raw request bodies, response bodies, or credential-bearing headers.

Trust model

Three properties matter:

• The Wallet only shows what’s already true on the backend. It’s a read/revoke UI over the same audit trail and grant table the SDK uses. There’s no “Wallet-side state” that could drift.
• Revocation is immediate. The next app.request() against a revoked grant raises GrantRevokedError. If other active grants share the same provider credential, they remain usable; the Vault token is removed when no active sibling grant still needs it.
• The Wallet session is app-scoped and separate from the application’s own session. Signing out clears the Wallet session. When the configured provider supports RP-initiated logout, the sign-out flow can also continue through the provider’s end-session endpoint.

When to suppress the Wallet

For internal admin tools and operator-only apps with no end users, there is no Wallet identity to sign in. Apps with end users can link to the app-scoped Wallet even when they also provide an in-product revocation UI. Building that UI via app.list_grants / app.revoke_grant supplements the hosted Wallet rather than changing its scope.

What’s next

Connections

The grants that surface in the Wallet.

Audit logs

The activity feed’s source of truth.

Add HITL approvals

Wallet-driven approval flow.