The admin console

Private beta. A beta notice sits at the top of every public console page (sign-in, sign-up, password reset, invitation acceptance, verification). The Dashboard and the first-run /welcome page are where an invited tester lands after their organization is created.

Zynth Auth ships a web console — the same authenticated app your users sign in to — where your team manages identity, access, security, and compliance without touching the API directly. Everything in the console is also available over the API; the console is a UI on top of it.

The console origin (auth.zynthmedia.com on managed) is sign-in-only and never indexed — the public website is a separate origin that holds no session. So a link you share from inside the console always requires the recipient to sign in — and sign-in brings them back to that link afterwards. The return target is always a page on the console's own origin, never another site: a sign-in link cannot be crafted to forward a freshly signed-in user elsewhere. The same holds when a session expires mid-work — you sign in again and land where you were.

What each person sees is decided by their role

The navigation mirrors permissions: a person only sees the areas their role grants, and the server enforces every action regardless of the menu (RBAC — see Tenants & users). The tenant owner sees everything; grant others least-privilege access with roles in Access Control. So a compliance officer, a security operator, and a developer each get a focused console.

The areas

• Security

  • Command Center — a live security operations view (event feed, threat detections, agents, incidents, autonomy, the tamper-evident audit log, compliance readiness, and health) for your operators. The Agents tab is the security-operations view of your AI agents — who is acting, how much of it succeeded, what has been raised about each one, and a one-click emergency stop that records why. It needs the AI-agent read permission as well as Command Center access; the Security Operator role carries both. The Autonomy tab is the platform's own response engine: what it decided, the proposals waiting on a human, approve / deny / undo, per-class graduation status, and the emergency stop. It is empty and idle until someone raises a response level — the default is that nothing acts.
  • Security Operations — the operations hub. During the beta its Sessions and Monitoring panels are visible but marked pending: they render the shape of the surface, not live data — what you see is honest about that.
  • Assurance — what the platform did when it was deliberately provoked. Zynth runs scored drills, races and soaks against its own deployment (never against your tenant); this console shows each run's verdict with its evidence, the catalogue of scenarios and where each came from, and the Assessor's findings on the platform's own codebase. It needs the assurance read permission, which owners hold and can grant to an auditor role. A run whose exit code is 2 is degraded by design — a leg could not be scored on that deployment — never an incident. Its Scenarios page lists every scenario the programme can run and where each came from, and its Findings page shows what runs surfaced beside what the Assessor found by reading the code.

• Compliance & Audit — for auditors and compliance officers:

  • Compliance — per-framework readiness dashboards (SOC 2, ISO 27001, GDPR, HIPAA, APAC, EU AI Act, ISO/IEC 42001, OWASP Agentic): control coverage, evidence, and a downloadable evidence export, plus the audit log with a one-click chain-integrity check.
  • ISMS — ISO 27001 risk register, security policies, and information-asset register.
  • HIPAA — PHI access logging, breach notifications, and encryption verification.

• AI Governance — govern the AI acting in your organization:

  • AI Agents — register and govern AI agents: risk profile, oversight, delegated authority, an emergency kill switch, and (when enabled) the action-approvals queue — review and approve/deny supervised agents' real-time asks, one execution per approval. Each agent also shows its recent activity (events over the last 7 days, and how many succeeded or were denied) and, if it has ever been stopped, who stopped it, when and why. That record is kept after the agent is released, so it reads as history rather than as "stopped right now" — the red banner is the only statement that an agent is contained at this moment.
  • AI Governance — framework readiness and governance artifacts for agentic systems.
  • MCP registry — the MCP servers your agents may call through the tool gateway: register a server, set per-agent call caps, retire one.

• Identity & Access

  • Members — your team roster and its invitations: invite by email with a role attached, change roles, remove members (removal ends their sessions immediately). See Team members & invitations.
  • Access Control — roles, per-user assignments, and attribute-based policies (who can do what).
  • Access Requests, Separation of Duties, Certifications — the access-governance areas (enterprise plan, and enabled per deployment): request a role for a bounded window and decide those asks; declare mutually-exclusive role sets; run certification campaigns where reviewers attest or revoke standing access. Hidden when the capability is not available. See Access requests.
  • Resources — your own applications' permission vocabularies: bind a namespace to a registered OAuth resource, define namespace:action permissions, and grant them in roles — delivered to your app as token claims and a check API (see Verifying access tokens).

• Organization

  • Organization — tenant-wide settings, rendered straight from the platform's setting registry: each one arrives with its own description, input constraints and risk classification, plus a change history showing who changed what and when. Changing a security-classed setting asks for explicit confirmation and says plainly that the change is recorded and raises a detection. Today: customer self-sign-up (CIAM), turning magic-link or social sign-in off, verified-domain auto-join, and the per-class autonomous-response levels. New settings appear here automatically — the authoritative list is whatever GET /api/v1/tenants/config/schema returns, not this sentence.
  • Enterprise SSO, OAuth Clients, OAuth Resources, Plan & Usage, System & updates — federation; the apps allowed to sign in your users; the APIs and MCP servers you may have audience-bound tokens minted for (RFC 8707 — a token minted for a registered resource verifies only there, and an unregistered identifier is refused with invalid_target); subscription and metered usage; and the running version.
  • Webhooks — register endpoints, choose which events they receive, rotate the signing secret, browse and replay the delivery log (guide).

• CMS — present when your tenant has content permissions:

  • Content — the queue of agent-written posts: what is waiting for review, what is scheduled, what is live, and what was refused (with the reason). A reviewer reads the exact bytes and approves or denies; publishing, scheduling, unpublishing and rollback are human actions here. Where an agent has earned autonomy, this is also where its track record and progress toward the bar are shown. Full walkthrough: author content with your own agent.

• Account — for every signed-in user:

  • Profile — your identity and verification status.
  • Security — MFA, passkeys, password, linked social accounts, and "sign out of all devices."
  • Privacy & Data — manage your consent and export your data or file a data-subject request; admins also review the DSR queue and set retention policies here.
  • Connected Apps — the OAuth applications you have granted access to your account, and revoking any of them.
  • API Keys — programmatic credentials, their scopes, and their usage.

Every member's own security view

Beyond the operator areas above, every signed-in member has a self-service security page (Account → Security): their active sessions with per-session sign-out (effective on the session's next request), passkeys/MFA/password/linked accounts, their own recent activity from the same tamper-evident record operators see, and — unique to this platform — which AI agents hold authority they delegated, revocable in one click.

Self-hosting

The console is part of the standard deployment. When you self-host (see Self-hosting), it's served at your instance's root; the same role-based gating applies.