Docs · Products
Bengar Console
Every screen a person can reach, what it needs, and what it can and cannot do today.
Signing in
An organization is provisioned with one founding account holding ADMIN. Sign in, and you land on the projects list; pick one and every subsequent page is scoped to it.
AVAILABLE Sign in and pick a project — /projects
Where: Sign in → Projects
First: A provisioned organization and a console user.
AVAILABLE Apply for an organization account — /register
Where: Sign in → Apply for one
An application is recorded, not granted. An operator reviews and provisions it.
The navigation
Three regions. Trust — Dashboard, Agents, Permits, Policies, Approvals, Executions, Audit, Proofs, API Keys, Security. Assets — an organization's own issued assets. Network — Overview, Validators, Staking, Governance, Treasury.
A link is hidden when your roles cannot use the page — that is a courtesy, not a control: every page re-authorizes at the Gateway, and typing a hidden URL gets the Gateway's refusal rather than the page. A region with nothing you may see is not rendered at all.
Dashboard
/projects/:id — decisions in the last 24 hours, pending approvals, unknown executions, frozen agents and the active policy version. Every counter says whether it is a rolling window or a current state, because a number that could be either is a number nobody can act on.
Agents
/projects/:id/agents lists them; an agent's page shows its state and offers freeze and release. Freeze is ADMIN or APPROVER; release is ADMIN alone, because letting an agent act again deserves a narrower hand than stopping it.
READ ONLY See the agents in a project — /projects/:id/agents
Where: Agents
First: At least one registered agent.
Listing and reading are all this screen does. Registering an agent has no endpoint anywhere in the product.
Requires: ADMIN, APPROVER, AUDITOR, POLICY_AUTHOR
AVAILABLE Freeze and release an agent — /projects/:id/agents/:did
Where: Agents → an agent
First: A registered agent. Release is ADMIN only.
Requires: ADMIN, APPROVER
AVAILABLE Register a new agent — /projects/:id/agents
Where: Agents → Register an agent
First: A did:key created outside Bengar, with `bengar id create`.
Requires: ADMIN
API keys
/projects/:id/api-keys — name a key, create it, and copy the secret. It is shown once and is not stored in a recoverable form; a lost key is revoked and replaced. Revoking asks you to type the prefix, because revocation is immediate and one-way.
AVAILABLE Create, list and revoke API keys — /projects/:id/api-keys
Where: API Keys
Requires: ADMIN
Permits
/projects/:id/permits is an inventory. A permit absent from it can still be valid; registering one records it and grants nothing. Issuance is not here on purpose — there is no issuer-key custody workflow, and a button would be inventing an authority rather than exposing one.
READ ONLY See the permit registry — /projects/:id/permits
Where: Permits
An inventory. Issuing happens in the CLI and registering needs PERMIT_ISSUER.
Requires: ADMIN, PERMIT_ISSUER, AUDITOR
AVAILABLE Register an issued permit — /projects/:id/permits
Where: Permits → Verify and register
First: A verifiable permit artifact.
Requires: PERMIT_ISSUER
Policies
/projects/:id/policies shows the active version, its document hash, whether it is signed, and every version with its state. A simulator is on the page, and activation is offered to POLICY_AUTHOR.
READ ONLY Read the active policy and its versions — /projects/:id/policies
Where: Policies
Reading the active version and the history. Publishing and activating are POLICY_AUTHOR.
Requires: ADMIN, POLICY_AUTHOR, AUDITOR, APPROVER
AVAILABLE Simulate a decision against the policy — /projects/:id/policies
Where: Policies → Simulate
First: An active policy version and at least one registered agent.
Requires: ADMIN, POLICY_AUTHOR, AUDITOR
AVAILABLE Activate a policy version — /projects/:id/policies
Where: Policies → Activate
First: An inactive version to activate.
Requires: POLICY_AUTHOR
Approvals
/projects/:id/approvals is the queue, filtered by status; an approval's page shows the obligation and, for APPROVER, the ceremony.
READ ONLY See the approval queue — /projects/:id/approvals
Where: Approvals
Reading the queue and one approval. Deciding is APPROVER.
Requires: ADMIN, APPROVER, AUDITOR
AVAILABLE Approve or reject, with a passkey — /projects/:id/approvals/:id
Where: Approvals → an approval → Review and approve
First: APPROVER, an enrolled passkey, and a provisioned Custody approval key — all three now have a screen.
Requires: APPROVER
Executions
/projects/:id/executions, filterable by status. An execution needing reconciliation offers it to ADMIN, and resolving one records what was checked.
READ ONLY See executions and filter by status — /projects/:id/executions
Where: Executions
Listing and filtering. Only an execution needing reconciliation offers an action, and only to ADMIN.
Requires: ADMIN, AUDITOR, APPROVER
AVAILABLE Reconcile an UNKNOWN execution — /projects/:id/executions
Where: Executions → Reconcile
First: An execution whose outcome is UNKNOWN.
Requires: ADMIN
Audit
/projects/:id/audit has two tabs — agent activity and human activity — with decision filters and real cursor paging.
AVAILABLE Read the audit trail — /projects/:id/audit
Where: Audit
Requires: ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR
Proofs
/projects/:id/proofs takes an audit event id and verifies it.
AVAILABLE Verify an audit event against its anchor — /projects/:id/proofs
Where: Proofs
First: An anchored audit event.
Requires: ADMIN, AUDITOR
Security
/projects/:id/security shows who you are here, your roles, and what the project enforces. It is read-only.
READ ONLY Read separation-of-duties settings — /projects/:id/security
Where: Security
Changing them from a browser form deserves its own ceremony, and there is no route for one.
Requires: ADMIN, AUDITOR
ADMIN is not implicitly every role. An administrator who could approve, or author policy, would defeat separation of duties by holding the role that configures it.
Roles
| Operation | Roles that satisfy it |
|---|---|
| api-key.create / revoke | ADMIN |
| agent.freeze | ADMIN, APPROVER |
| agent.release | ADMIN |
| execution.resolve | ADMIN |
| permit.register / revoke | PERMIT_ISSUER |
| policy.publish / activate | POLICY_AUTHOR |
| approval.decide | APPROVER |
| audit.read | ADMIN, AUDITOR, APPROVER, POLICY_AUTHOR |
AVAILABLE Grant a role to a person — /projects/:id/security/members
Where: Security → Members
Requires: ADMIN
Roles are granted under Security → Members. An administrator adds a person, chooses an initial role, and grants or revokes the rest from the table. Two refusals are worth knowing: you cannot grant yourself a role you lack, and the last administrator cannot be removed.
Errors you will meet
| What you see | What it means |
|---|---|
| “The control plane did not answer this request.” | The Gateway was unreachable or refused. Nothing changed. |
| role_required | Your roles do not include this operation — often correct. |
| A 404 on another tenant's identifier | The same answer a typo gets. Confirming existence would be a cross-tenant oracle. |
| Signed out unexpectedly | The session expired, or was revoked server-side. Sign in again. |