Dashboard guide

The Axtary dashboard is the hosted control plane for people: review exact-payload approval requests, inspect synced evidence, understand policy and connector state, and manage workspace access. The CLI, proxy, SDK, hooks, and MCP wrapper remain the local enforcement plane. They hold provider credentials and execute covered actions; the dashboard is not a hosted replacement for that runtime.

You can use Axtary local-only. Enable the hosted plane when your workflow needs a signed-in human approval, shared evidence, or tenant administration.

Access and roles

An admin invites a member by email. The invite is single-use and expires after seven days; the invitee sets their own password. Sign-in, forgot-password, and reset links are served by Axtary, and reset responses do not reveal whether an email exists.

Workspace roles are deliberately narrow:

• Viewer: read access to the workspace surfaces granted to viewers.
• Reviewer: can inspect and decide approval requests, but cannot administer members or deployment settings.
• Admin: can review actions and manage tenant members and settings.

The account card in the sidebar opens Your account, where any signed-in user can confirm their email, change their password, and revoke other sessions. Administration-only navigation is hidden for non-admins; server authorization still protects the routes and APIs independently of the menu.

Page map

Get started

The setup rail explains the two-plane flow and tracks the workspace's first policy, decision, approval, evidence, and connector proof. It is an onboarding aid, not a substitute for provider readiness or a live smoke test.

Overview

The overview summarizes decision activity, policy revision, connector evidence, pending approvals, and ledger state. Use it to orient; open the underlying page before treating a summary as operational proof.

Approvals

Review the exact normalized action, payload or diff, reason, and payload hash. Approve or deny only after confirming the content and target. An approval is bound to that hash: changing the message, diff, query, path, or tool arguments causes the local runtime to fail closed rather than reuse the decision.

Hosted approvals require both sides:

1. An admin mints a scoped runtime approval token without exposing it to the agent.
2. The local CLI starts a workflow with --hosted-approval, submits the step-up request, and waits.
3. A signed-in reviewer opens Approvals, checks the exact payload, and decides.
4. The runtime verifies the returned approval artifact against the attempted payload before execution.

Do not share runtime tokens in chat, screenshots, source, or browser recordings.

Ledger

The hosted ledger contains records explicitly synced from a local runtime. Search by decision and evidence fields, inspect the ActionPass and chain state, and use the spine explorer to understand related records. Absence from the dashboard does not prove absence locally; confirm the runtime's sync range and result.

The independent source of proof remains the exported evidence. Use axtary attest-ledger and axtary verify-export, and see Verify the ledger.

Policies

Inspect the active deterministic policy revision, simulate representative fixtures, and see why an action allows, denies, or steps up. A simulation does not execute a provider call. Keep policy tests in source control and run axtary policy test in CI so the reviewed policy and deployed configuration do not silently drift.

Connectors

Connector cards distinguish implementation, configuration/readiness, live smoke evidence, and stale or missing proof. Provider credentials stay in the local runtime. Use the dashboard for safe metadata and recorded evidence; use axtary doctor connectors and an intentional sandbox axtary smoke for the actual provider check.

“Disabled” or “needs setup” does not mean the connector is a mock. It means the implemented adapter is not enabled or has not met its required configuration and proof gate in this workspace.

Members

Admins invite users, choose viewer/reviewer/admin roles, change roles, remove members, resend or revoke pending invites, and inspect workspace sessions. Reviewers and viewers do not receive this tenant-administration surface.

Settings

Admins see deployment variable presence by name—not secret values—and ledger sync health. Axtary's own operator deployment can additionally expose internal waitlist and one-time reviewer-feedback tools when explicitly enabled; those operator tools are not a customer-tenant feature.

Your account

Every role can inspect the signed-in email, role, tenant, current/other sessions, change the password, and revoke sessions. Changing the password revokes other sign-in sessions; locally bridged access can remain valid only until its short expiry.

Local versus hosted truth

The dashboard does not claim that Axtary prevents prompt injection. It makes covered actions fail closed under deterministic policy, bounds the authority available at the configured boundary, and preserves attributable evidence.

Next: run the Quickstart, use the full CLI reference, or follow Evaluate Axtary.