Skip to main content

Team and access

Settings holds the workspace itself: members and roles, the permissions matrix, agent keys, and workspace-wide switches.

Inviting someone​

In Settings, Team, enter an email and pick a role. The invitee gets a link (valid for seven days) where they confirm the email, set a name and password, and land directly in your workspace. Inviting an address that already has an account attaches that account to your workspace instead of creating a twin: signed in, it is a one-click join; signed out, a "log in and join" step. Existing passwords are never touched. Pending invites can be resent or revoked; inviting is itself a permission, so only roles allowed to invite see the form.

Removing a member takes their access to this workspace and nothing else; their account and their other workspaces are untouched.

Company sign-in domain​

On Business and above, the workspace can claim its Microsoft sign-in domain: anyone signing in with a company account under that domain joins the workspace automatically as a viewer, no invites needed, and an admin raises roles from there. The domain is exclusive to one workspace, public email providers are rejected, and the claim locks to your organization's identity on the first join, so a lookalike address from a foreign directory cannot ride in. Google and Slack sign-in exist as personal login methods on every plan; the domain auto-join is the gated piece.

Roles and permissions​

Members hold one role per workspace: owner, admin, responder, viewer, or a billing-only role. What each role can see and do is the permissions matrix: one row per capability, from module visibility (which sidebar items exist for that role) to actions (acknowledge incidents, edit alert rules, write runbooks, manage hosts, apply staged changes, invite, billing). Owners and admins can click any cell to change it, and reset a role back to defaults; the owner always has everything. Changes reach open sessions immediately.

A cell that cannot be granted (the platform itself restricts it) renders as a locked cross with an explanation, so the matrix never silently lies.

Agent keys​

Settings, Agent keys manages the bootstrap credentials your servers register with:

  • Issue creates a new key; the install dialog always shows your active key.
  • Each key row counts the hosts enrolled with it and when it was last used. A key you never shared showing fresh enrollments is your leak indicator.
  • Revoke stops a key from registering anything new. Hosts already registered are untouched: the team key is used once at bootstrap and never stored on hosts, so rotation is just revoke plus issue.

Audit log​

On Business and above, Settings, Audit log is the workspace's tamper-evident history: every console mutation, sign-in and SSO event, and every API and MCP action, chained cryptographically so that any alteration of past records becomes visible (the page verifies the chain as it renders and says so). Machine events from the platform (key rotations, agent updates, APM activations) are shown alongside, marked as such. Evidence export downloads the whole chain as CSV or JSON with a server-side verification verdict included, and the export itself lands in the log. This is the audit trail a SOC 2 or client security review asks for.

Compliance​

Settings, Compliance (open on every plan) collects what a security reviewer needs:

  • the trust pack: signed PDFs covering the threat model, data flow, security review history, reproducible builds, incident response, change management, risk and data-classification policies, plus the per-release SBOM. The pack is rebuilt and signed automatically with every agent release, and it is public: anyone can fetch it from the Wakora website, no console needed.
  • the subprocessor register with jurisdictions and DPA status.
  • the compliance posture, stated honestly (what is in place versus in progress).
  • a cover letter generator: a "prepared for" letter for handing the pack to a specific client, with file hashes and a verification recipe; each issue is recorded.

Fleet rollout​

Settings, Fleet turns agent updates into staged rollouts. Define rings (a canary list, optional waves; everything else is the fleet), and a release walks them in order: a ring is promoted automatically once it fully runs the release and has soaked clean (no host drops, no crash loops) for the configured hours, or you promote and hold by hand. Rollback re-pins a ring to where it was in one click. A workspace-wide version pin freezes everyone who has no pin of their own; manual per-host pins are never touched by the rollout machinery.

The same tab collects fleet-wide operations: every pending "action required" across hosts folded into one paste, hosts lagging behind the release with the reason named, and agent health at a glance.

Definitions​

Settings, Definitions is the transparency page: every signed definition, what it matches, how many of your hosts run it, and a click-through preview of the exact command behind every probe. Details and the marketplace: Definitions and marketplace.

Workspace switches​

Workspace-wide controls live here too: the log collection kill switch (stops log shipping on every host at once) and the workspace's plan and region facts. Per-host versions of the same switches live on each host's Manage card.