Settings

Workspaces are isolated tenants. Issues, agents, monitors, integrations, and members all belong to one workspace. Most teams have a single workspace; larger organizations sometimes run separate workspaces for different business units or environments.

​

Members

​

What a member has

• Profile: Linked to a Cantina identity (email, name). Your account email is read-only in Clarion and shows its verification status.
• Communication channels: Link Slack and Teams identities or verify a phone number. Clarion reads your account email from Cantina; it cannot be replaced with an alternate address.
• Preferred channel: The default channel for private agent clarifications. Selecting Email opts you into clarification emails at your verified account address.
• Email notification settings: Toggle assignment emails for incidents and tasks separately from the preferred clarification channel.

​

What you can do

• Invite new members by email.
• Update a member’s communication channels and preferred channel.
• Remove members who no longer need access.

Clarification emails contain a link back to Clarion. Sign in as the intended member to answer; replies sent to the email itself are not processed.

​

Roles & permissions

Settings → Roles renders the live matrix: every permission Clarion knows about, crossed with every role, derived from the same function the API authorizes with. It cannot drift from what is actually enforced. This page explains the shape of it.

​

The four roles

​

Permission categories

The matrix is grouped the same way the permission catalog is:

​

Why authoring is Admin-only

Creating or editing an agent, a skill, or a schedule is Admin-only, and that is a security decision rather than a convenience one. An agent definition decides what runs, with which tools, against your production systems — and it runs with permissions inherited from its creator. If a Member could author agents, the effective privilege of the Member role would be “whatever an agent can be told to do.” Keeping authorship with Admins preserves the invariant that every agent traces back to an Admin who approved what it can reach. The same logic covers the other Admin-only permissions:

• Manage tool policies and manage agent pausers — these are the controls that decide which tools require approval and which agents may run at all.
• Manage escalation routing — otherwise a non-admin could reroute another agent’s pages to a destination they control.
• Retrigger issues and run issue remediation — audited, but the audit trail is not a substitute for a gate.
• View all members’ API tokens and manage all members’ API tokens — every role gets the :own variant for self-service; only Admin sees everyone’s.

​

Responding to human input

Every role holds Respond to open human input requests, but it is only consumed when Anyone can respond to human input is enabled in Workspace settings.

• Off (default): tool approvals and clarifications require Approve triage actions — Admin and Member only.
• On: any member, including read-only ones, and any teammate in the linked Slack or Teams channel, can unblock the agent. The audit log still records who did.

​

Read-only is not “Member minus writes”

Almost, but Read-only cannot View members. Neither role has workspace-wide View bounty submissions: Members instead read, triage, and decide only findings an Admin or Bounty triager assigns to them. Read-only is the posture used for shared evaluation workspaces, where the member list would tell each prospect who else is in the room.

​

Platform permissions

A few permissions in the catalog — the benchmark-scenario surface — are held by no workspace role, not even Admin. They are carried only by a Cantina platform credential. The Roles matrix omits them, because a row of empty cells in a table about workspace roles would only mislead.

​

Workspace

Changes here are workspace-wide and take effect on the next agent run. Editing them requires the Edit workspace settings permission — see Roles & permissions.

​

Domains

Your company’s top-level domains. Detections use them to tell internal from external: an account outside these domains reporting agent telemetry, a login from a non-company identity, an email-auth change on a domain you own. Subdomains count as internal automatically — list only the top-level domains (example.com, not mail.example.com). An agent can also propose domains it discovered during investigations for you to confirm.

​

Human input and messaging

These settings decide what happens to an agent’s approval and clarification requests, and how far its Teams messages can reach. Which severities page your team is set in Severities that escalate.

​

Deny unanswered tool approvals

Decides what happens when nobody answers an agent’s request to run a gated tool. Tools set to auto-decide in Settings → Tools are unaffected: they are judged individually rather than denied outright.

​

Anyone can respond to human input

Controls who may answer an agent’s approval and clarification requests. Either way, the audit log records who unblocked the agent.

​

AI provider credentials

Available when your workspace is enabled for bring-your-own-key (BYOK). Paste an Anthropic or OpenAI API key and Clarion infers the provider from the key prefix. A workspace with its own usable key runs only on that key: no cross-subsidy, and no tenant data through Clarion’s provider account. See Models & runtime for how that interacts with tiers and failover.

​

Elsewhere in Settings

​

General

Settings → General holds the workspace-level actions you rarely need:

• Demo data — load or clear a sample dataset for evaluating Clarion.
• Health checks — run Clarion’s own integration and monitor health checks on demand.
• Delete workspace — permanent, and removes every issue, agent, and integration in it.

​

Agents

The page has four sections, each linked from the settings sidebar under Agents: Changes take effect on the next agent run. Drafts are kept when you switch between sections.

​

System prompt

The default prompt Clarion gives every triage agent in the workspace. Clarion maintains it and you can’t edit it; the version shown next to it changes whenever Clarion updates the prompt. What you can change is added on top of it: Agent behavior and Escalation & notifications. The escalation bar is written into the prompt itself, so the text you see reflects your current setting. Skills are not part of the prompt. Each agent sees the list of skills assigned to it and opens one only when an issue calls for it, so skills shape how agents work without making every triage longer.

​

Agent behavior

Standing instructions every agent run inherits, on top of whatever its skills say. These were previously called workspace instructions and lived under Settings → Workspace. Over MCP, read and replace them with get_agent_behavior and set_agent_behavior. Use them for context that doesn’t belong to any single skill:

• Your business context, and who owns which system.
• Organization-wide terminology, escalation hierarchy, and on-call conventions.
• Environment-specific quirks (“staging fires this alert nightly; it is expected”).
• What agents must never do.

Notification channels do not belong here. Configure them under Escalation & notifications; agents read that set directly and pick a destination per run. The editor supports the same @-references as the skill editor, so instructions can point at a specific skill by name.

​

Escalation and notifications

Decides when an agent pages your team, and where it sends escalations, approval requests and questions. Destinations, routing and the on-call rotation are covered in Notifications.

​

Severities that escalate

When an agent finishes triaging an issue it considers a real problem, it escalates it: the issue moves to Escalated and the team is paged. This setting is the bar for that page. The agent escalates only when the issue’s severity is one you selected. Anything below the bar moves to Open instead, so it still waits for a human, just without a notification.

• Default: High and Critical.
• Choices: any combination of Low, Medium, High, and Critical.
• Minimum: at least one severity. The last one can’t be unchecked.

A few things are worth knowing:

• The bar applies to agents only. A member who clicks Escalate on an issue always escalates it, whatever its severity.
• Parking an issue in Open doesn’t change the verdict. Its disposition and severity stay as triage set them; only the status differs.
• Some issue kinds are stricter. Issues of kind Risk or Vulnerability stay Open on an agent’s decision regardless of this setting. The one exception is a Critical finding the agent justifies as imminent danger. See Issue kinds.
• Agents are told the bar. Your selection is written into the system prompt, so the agent works from your policy rather than the default.

​

Skills

Step-by-step playbooks agents open on demand for specific kinds of alerts, such as a phishing report or a suspicious sign-in. Each row shows the skill’s description, which is the only text an agent uses to decide whether to open it; missing descriptions and broken references are flagged. See Skills and Authoring best practices.

​

SSO

​

What SSO gives you

• Centralized authentication: Members log in through your IdP. No separate Clarion password.
• Lifecycle parity: When a member leaves your organization in your IdP, their Clarion access goes with it.
• MFA inheritance: Whatever MFA policy you enforce in your IdP applies to Clarion.

​

Setup overview

1. Add Clarion as an enterprise app in Microsoft Entra ID.
2. Assign the users or groups who should have access.
3. Provide the tenant ID and any required claim mappings to Clarion through the SSO settings page.
4. Test sign-in with a non-admin account before enforcing SSO workspace-wide.

See Microsoft Entra ID for the full step-by-step setup.

​

MCP access

​

Where it lives

In Clarion, go to Settings > MCP access. The page has two tabs:

• OAuth setup — copy-paste snippets for Claude Code and Claude Desktop, plus a generic note for other MCP clients. No secrets to manage. This is the tab the page opens on.
• API tokens — mint, list, and revoke long-lived bearer tokens. One row per token; the plaintext is shown exactly once at creation time.

The MCP endpoint itself is at https://<your-clarion-host>/api/mcp (the OAuth setup tab fills in the right URL for your environment).

---

​

Choosing a flow

If a client supports OAuth, use it. The browser flow handles re-auth automatically when access expires; long-lived tokens never rotate and stay valid until revoked or their owner is removed from the workspace.

---

​

Connecting via OAuth

​

Claude Code (CLI)

1. Open Settings > MCP access > OAuth setup and copy the claude mcp add command shown there. It already contains the right URL for your workspace.
2. Run it:
   claude mcp add --transport http clarion https://<your-clarion-host>/api/mcp
   
3. Start a session. On the first tool call Claude Code opens the Clarion OAuth grant page — pick the workspace and approve. The token is captured by Claude Code’s local callback.

​

Claude Desktop

1. Open Settings > MCP access > OAuth setup and copy the JSON snippet.
2. Paste it into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent path on Windows/Linux:
   {
     "mcpServers": {
       "clarion": {
         "type": "http",
         "url": "https://<your-clarion-host>/api/mcp"
       }
     }
   }
   
3. Restart Claude Desktop. The first tool call triggers the same browser grant flow as the CLI.

​

Other MCP clients

Point any MCP client that speaks the Streamable HTTP transport at https://<your-clarion-host>/api/mcp. The first unauthenticated request returns a WWW-Authenticate challenge that points at /.well-known/oauth-protected-resource; any spec-compliant client follows the metadata to discover the authorization server and complete the OAuth flow without extra config.

---

​

Connecting via a long-lived API token

Use this when the client can’t drive an interactive browser sign-in.

1. In Settings > MCP access > API tokens, click New token.
2. Give it a label that lets you recognize it later (e.g. CI nightly drift check, Cron worker).
3. Click Create token. The dialog swaps to a one-time reveal — copy the plaintext now. Once you close the dialog the secret is gone for good.
4. Paste the token into your MCP client config as a Bearer credential:
   {
     "mcpServers": {
       "clarion": {
         "type": "http",
         "url": "https://<your-clarion-host>/api/mcp",
         "headers": { "Authorization": "Bearer <PASTE_TOKEN_HERE>" }
       }
     }
   }
   

​

Revoking a token

In the API tokens tab, click the revoke icon on the row, confirm, and the token stops authenticating immediately. Any client still using it gets a 401 on its next request. Revocation is one-way; revoked rows stay in the list with a “Revoked” badge so you can audit who created them and when.

---

​

Available tools

After connecting, the client sees the following workspace-scoped tools under the clarion server (so each one appears as mcp__clarion__<tool>). Every tool is scoped to the token’s workspace: reads filter by workspace, cross-workspace lookups return an error rather than another tenant’s data, and mutations are attributed to the operator who minted the token.

​

Read & triage

Issues

• list_issues — paginated list, filterable by status / severity / search. status: ["escalated"] narrows to the confirmed problems.
• get_issue — full issue detail by display number, including its parent issue and related child issues
• complete_remediation_item — toggle a checklist item on an issue’s remediation list
• retrigger_issue — re-run triage agents for an issue (e.g. after deploying a fix)
• update_issue — edit an issue’s title, description, or verdict; marking one a duplicate stays in the Clarion UI (requires issues:write)
• set_issue_severity — change an issue’s severity (requires issues:write)
• set_issue_status — move an issue to a new status, including closing it with a verdict; sub-issues follow only when asked (requires issues:write)

Tasks

• list_tasks — paginated list, filter by status / priority / search / issue_number
• get_task — single task by id
• set_task_status — complete or reopen a task (requires tasks:write)

Monitors & integrations

• list_monitors, get_monitor — the workspace’s ingestion sources, with sanitized per-type config (webhook secrets stripped)
• create_monitor — add a monitor of a credential-free type: dns, rss_feed, or status_page (requires monitors:manage). The domain or URL is fetched server-side before the monitor is saved. Every other type mints a webhook secret or takes an API key, so it stays in the Clarion UI.
• update_monitor — rename or enable/disable any monitor type; edit config only for the credential-free types (dns, rss_feed, status_page), which re-validates the feed/status page (requires monitors:manage). A config edit for a secret-bearing type stays in the Clarion UI.
• delete_monitor — permanently delete a monitor and its signal rules, tearing down any webhook registrations it created; any type can be deleted (requires monitors:manage)
• list_integrations, get_integration_health — integration sync health (consecutive failures, pause state, auth errors); credentials are never returned

Signals

• list_signals, get_signal — the raw ingested events that feed issues, before any alert filter fires
• summarize_signals — one source’s signal counts per monitor and event type over the last 1–90 days, each marked with that monitor’s signal rules whose steps match it. An event type with no covering rule is a detection gap.

Signal rules

• list_signal_rules, get_signal_rule — the detections that turn signals into issues, per monitor or workspace-wide (the matching sequence is returned by get_signal_rule)
• create_signal_rule — add a detection on a monitor: a match sequence plus the severity, kind, and title/description of the issue it fires (requires signal_rules:manage). The alert source is set server-side.
• update_signal_rule — partial-fields edit of a rule; editing a template-managed rule’s content forks it from the template, while toggling active state or moving monitor does not (requires signal_rules:manage)
• delete_signal_rule — permanently delete a signal rule (requires signal_rules:manage)

Bounties

• bounty_list_programs, bounty_get_program — list or inspect workspace Bounty programs by public slug; internal ids, creator data, and Agent configuration are omitted
• bounty_list_findings, bounty_get_finding — page and filter Bounty-specific finding projections by program slug and public reference; the detail response derives currently available actions from lifecycle policy
• bounty_get_agent_triage — read the latest redacted Bounty Agent run in bounded 200-entry transcript pages
• bounty_list_finding_comments, bounty_list_finding_comment_replies — page visible finding discussion and reply history
• bounty_start_manual_triage, bounty_submit_triager_assessment — BountyTriager-only takeover and assessment-handoff actions
• bounty_mark_finding_spam, bounty_mark_finding_duplicate, bounty_request_finding_information — controlled, version-checked, idempotent triage mutations
• bounty_decide_finding — accept or reject a finding in triager/client review, or return a client-review finding to the triager, using its current status and version; Admin-only through bounty_submissions:decide

BountyTriager uses the same workspace credential and endpoint as other workspace roles, but sees only the Bounties tools allowed by its current permissions. Clarion resolves the token owner’s current membership and role on every request; removing the owner from the workspace invalidates the credential on its next use. Agent runs

• get_agent_job — the execution record of a single non-Bounty agent run (status, error, model, token usage, timing, and what it ran for: a triage investigation, an assistant chat, or a scheduled run); use bounty_get_agent_triage for Bounty runs
• get_agent_job_transcript — the poll-friendly, step-by-step transcript of an agent run (assistant turns, tool calls, tool results), oldest first

Assistant chats

• list_chats — the workspace’s assistant chats
• get_chat_transcript — a chat’s messages and tool activity
• start_chat — open a new assistant chat with a first user message (optionally booting a specific agent persona); returns an agent-run id to poll
• send_chat_message — post a follow-up message into an existing chat

Schedules

• list_schedules, get_schedule — discover what’s running in the workspace
• list_schedule_runs, get_schedule_run — poll-friendly run snapshots
• run_schedule_once — fire a schedule out-of-band without changing its cron cadence
• cancel_schedule_run — cancel a pending or running execution
• create_schedule, update_schedule, set_schedule_enabled, delete_schedule — full CRUD on recurring tasks

​

Configure the workspace

Agents

• list_agents, get_agent — the workspace’s triage agents and their linked skills/monitors
• create_agent, update_agent — manage an agent’s name, active state, linked skills, and linked monitors. Create the credential-free monitor types with create_monitor first; the ones involving webhook secrets and registration stay in the Clarion UI.

Skills

• list_skills, get_skill — reusable workspace skills, instructions returned as markdown
• create_skill, update_skill — author or edit a skill from markdown; tools are extracted from the inline <tool> pills, and edits snapshot a new version
• evaluate_skill — check a saved skill (skillId) or an unsaved draft against the authoring best practices; returns meetsRecommendations, plus recommendations when it does not

Templates

• list_skill_templates, get_skill_template — browse the curated skill-template catalog
• create_skill_from_template — instantiate a skill template into a managed workspace skill (auto-updates when the template changes; idempotent — returns the existing copy if already instantiated)
• list_agent_templates, get_agent_template — browse the published agent-template catalog
• create_agent_from_template — scaffold an agent plus its managed skills from a template, created inactive so you can review before it runs

Workspace

• list_workspace_tools — the action tools currently available to agents in this workspace. Only tools whose backing integration (and any required credentials or pauser config) is actually connected are returned — unconfigured ones are omitted — so this reflects what a skill can reference today. Includes the workspace’s custom MCP servers, custom API/CLI toolsets, and Microsoft Sentinel tools.
• get_agent_behavior, set_agent_behavior — read or replace the workspace’s agent behavior (markdown), the standing instructions added on top of the read-only system prompt for every agent

​

Asset catalog & curated knowledge (Brain)

The Brain surface exposes the workspace’s discovered infrastructure and the operator-curated architecture knowledge layered on top of it. Assets & systems (read)

• list_assets, get_asset — the resources (compute, datastores, repos, services, DNS records, cloud accounts, …) discovered across connected integrations
• list_systems — the auto-correlated, cross-provider groupings of those assets

Annotations (write)

• annotate_asset — record durable, attributed notes/attributes on a resource
• record_inferred_asset — persist a triage-inferred narrative asset (attacker IP, involved user, vulnerable package, …) into the catalog

Curated knowledge (read)

• search_knowledge — text-search knowledge names, page bodies, and references
• list_knowledge_elements, get_knowledge_element — the hand-curated architecture nodes (systems, services, platforms, …) and their linked assets and references
• list_knowledge_references — curated external references filtered by semantic tag (access_control, runbook, architecture, …)

Curated knowledge (write)

• propose_knowledge_element, update_knowledge_element, remove_knowledge_element — create/enrich, edit, or delete a curated knowledge node
• link_knowledge_asset, unlink_knowledge_asset — connect or disconnect a catalog asset and a knowledge node
• add_knowledge_fact, update_knowledge_fact, delete_knowledge_fact — weave, supersede, or retract an atomic claim in a knowledge node’s recap