# 1Password Source: https://docs.clarion.cantina.xyz/integrations/1password Connect 1Password to Clarion to monitor audit events, sign-in attempts, and item usage events from your 1Password Business account. This guide walks you through connecting your 1Password Business account to Clarion via the 1Password Events Reporting API. Once connected, Clarion polls 1Password every minute for audit events, sign-in attempts, and item usage events, and uses them to detect suspicious activity and open issues. **Estimated time:** 5 minutes. You will need **1Password Business** with permission to set up Events Reporting integrations. ## Prerequisites * A **1Password Business** account with access to **Integrations → Directory** * A **Clarion workspace** with the 1Password integration page open * A secure place to store the bearer token generated in 1Password *** ## Step 1 — Create a bearer token in 1Password 1. Sign in to your [1Password account](https://start.1password.com/). 2. Go to **Integrations** → **Directory**. 3. Under **Events Reporting**, click **Other** and set up a new integration. 4. Select the event types to report: * Audit events * Sign-in attempts * Item usage events 5. Copy the generated **bearer token**. Copy the bearer token immediately — it will only be shown once. Store it securely. *** ## Step 2 — Enter the bearer token in Clarion 1. In Clarion, open **Integrations** → **1Password**. 2. Paste the **Bearer Token** from 1Password. 3. Click **Connect**. Clarion validates the token and begins polling the Events Reporting API for new events every minute. *** ## What happens next Once connected, Clarion will: * Poll 1Password every minute for audit events, sign-in attempts, and item usage events * Open issues from suspicious activity based on your configured alert filters * Use 1Password event data to enrich investigations and triage You can manage which events open issues from the **Alert Filters** section on the 1Password integration page. *** ## Update or rotate the bearer token To replace the bearer token (for example, after rotating it in 1Password): 1. Generate a new bearer token in 1Password under **Integrations → Directory → Events Reporting**. 2. In Clarion, open **Integrations** → **1Password**. 3. Paste the new token into **Update Bearer Token** and click **Update Token**. *** ## Troubleshooting ### The connection fails or events stop arriving * Confirm the bearer token was generated for the correct 1Password account and has not been revoked * Verify the integration in 1Password still includes audit events, sign-in attempts, and item usage events * Use **Sync now** on the 1Password integration page in Clarion to trigger an immediate poll # Apex Source: https://docs.clarion.cantina.xyz/integrations/apex Connect Apex to Clarion to ingest security findings from your repositories and code scanning workflows. This guide walks you through connecting Apex to Clarion. Once connected, Apex sends security findings into Clarion, where the Apex agent can triage them and drive incident response. **Estimated time:** 2-5 minutes. You will need access to your **Apex dashboard** with permission to manage company settings, and a **Clarion workspace**. ## Prerequisites * Access to your **Apex dashboard** with permission to manage **Company Settings** * A **Clarion workspace** with the Apex integration available *** ## Step 1 — Enable the Apex integration in Clarion 1. In Clarion, navigate to **Integrations**. 2. Find the **Apex** card and click **Connect** to enable the integration. *** ## Step 2 — Open Company Settings in Apex 1. Open your **Apex dashboard**. 2. Go to **Company Settings**. *** ## Step 3 — Connect Clarion from Apex 1. In Company Settings, click **Connect Clarion**. 2. Review the workspace shown in the connection screen and confirm it's the correct Clarion workspace before connecting. *** ## Step 4 — Add the Apex agent in Clarion Once the connection is established: 1. In Clarion, go to **Agents**. 2. Click **Create Agent**. 3. Add the **Apex agent** so findings from Apex are picked up and triaged automatically. Without the Apex agent enabled, findings will arrive in Clarion but won't be triaged. Don't skip this step. # AWS Source: https://docs.clarion.cantina.xyz/integrations/aws Connect your AWS account to Clarion for CloudTrail events, CloudWatch alarms, GuardDuty findings, and IAM agent tools. Clarion connects to AWS to ingest CloudTrail events, CloudWatch alarms, and GuardDuty findings, and to run agent tools (CloudTrail lookup, Route 53, CloudWatch queries) against your account. There are a few different ways to get your AWS telemetry into Clarion. Pick the path that matches how your AWS logging is already set up — you can combine more than one. ## Choose a setup path The complete setup. Forward CloudTrail management events and GuardDuty findings to Clarion in real time through EventBridge and SNS, wire up CloudWatch alarms, and create the IAM role for agent tools. Already logging CloudTrail to S3 (or using a tool like Red Canary)? Have Clarion read each new log file from the bucket via an S3 event notification. Ideal for organization-wide, centralized logging. ## How AWS data reaches Clarion Every path delivers events to Clarion through an **SNS topic** that publishes to a Clarion **webhook URL** over HTTPS. They differ in how events get *into* that topic: | Path | How events are produced | Best for | | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | [EventBridge & SNS](/integrations/aws/eventbridge) | An EventBridge rule matches CloudTrail / GuardDuty events and targets an SNS topic; CloudWatch alarms and other sources publish to SNS directly | Real-time CloudTrail management events, GuardDuty findings, and CloudWatch alarms | | [CloudTrail via S3](/integrations/aws/cloudtrail-s3) | S3 event notifications fire when CloudTrail writes a new log file to the bucket | Existing or consolidated CloudTrail-to-S3 logging, org-wide trails | Clarion only accepts SNS messages from topic ARNs you have saved on the matching monitor. Whichever path you choose, copy the exact SNS topic ARN into Clarion before confirming the subscription. CloudTrail via S3 sends Clarion a pointer to a log file, not the CloudTrail event body. Clarion must be able to assume an AWS role that can read that S3 object. See [CloudTrail via existing S3 bucket](/integrations/aws/cloudtrail-s3) for the required IAM setup. ## Agent tools Running Clarion's AWS agent tools (CloudTrail lookup, Route 53, CloudWatch queries, Athena) requires an IAM role that Clarion can assume. That role is covered in the [AWS via EventBridge](/integrations/aws/eventbridge#step-4-iam-role-for-agent-tools) guide and in the [CloudTrail via S3](/integrations/aws/cloudtrail-s3) guide — set it up once per connected account. # CloudTrail via existing S3 bucket Source: https://docs.clarion.cantina.xyz/integrations/aws/cloudtrail-s3 Ingest CloudTrail events into Clarion from an existing S3 bucket using S3 event notifications and SNS — ideal for centralized, organization-wide logging. CloudTrail writes its events as log files to an S3 bucket. If you have already set up CloudTrail, you most likely turned on delivery to an S3 bucket — or you use an existing solution such as Red Canary that consolidates CloudTrail logs there. Either way, every CloudTrail event ends up stored in S3. To bring those events into Clarion, you configure the bucket to publish an **SNS notification whenever a new log file is added**, and Clarion subscribes to that topic. Each new file is fetched and turned into signals. ``` CloudTrail ↓ S3 bucket (new log file added) ↓ S3 event notification ↓ SNS topic ↓ Clarion webhook ``` This is one of two ways to connect AWS. For real-time CloudTrail management events, GuardDuty findings, or CloudWatch alarms delivered over SNS, see [AWS via EventBridge and SNS](/integrations/aws/eventbridge). This setup sends Clarion an S3 object pointer, not the CloudTrail event body. Clarion must assume the customer-side IAM role configured in your AWS integration and read the referenced log file from S3. If the role is missing or cannot read the bucket, Clarion drops the pointer and those CloudTrail events are not ingested. If the SNS subscription is confirmed but CloudTrail events are not appearing in Clarion, check the IAM role first. Clarion may be receiving the S3 notification but failing to fetch the referenced log object because the role does not have S3 read access. *** ## Before you start **Pick the right account.** * **Organization-level integration** — if your CloudTrail logging is centralized from all accounts into one bucket, use the **log-archive account** (or management account) that owns the CloudTrail bucket. One bucket, one SNS topic, and one Clarion subscription cover the whole organization. * **Single account** — select the account that owns the trail and bucket. You already have an existing S3 bucket for this flow. You can confirm exactly which bucket your trail writes to from the trail's **log location** in CloudTrail (covered in [Step 5](#step-5-notify-clarion-when-new-log-files-arrive)). For organization-level trails, the role Clarion assumes must be able to read the bucket owned by the log-archive account. A role in only the member account that produced the CloudTrail event cannot read the centralized log object. *** ## Step 1 — Connect AWS and configure the IAM role 1. In Clarion, open the **AWS** integration page and click **Connect** at the bottom of the page. 2. Set up the IAM role first. For reading CloudTrail logs from S3, select these permission sets: * **Athena S3 log queries** * **S3 SSE-KMS log decryption**, only if your bucket uses SSE-KMS The **Athena S3 log queries** permission set is the one that gives Clarion S3 read access for the log objects. The **CloudTrail events** permission set only grants CloudTrail API calls and is not enough for S3-backed ingestion. 3. The generated policy JSON appears on the right. You have two options to apply it — the **AWS Console** or the **AWS CLI** — and the instructions for both are shown there. 4. Once you have run the AWS CLI commands (or finished the setup in the AWS Console), set the **default region** and the **IAM Role ARN** you created. 5. Click **Configure IAM**. The generated policy uses `Resource: "*"` on every statement for convenience. Before production, deselect any permission sets you don't use and replace `"*"` with specific ARNs for your resources, such as S3 log buckets and KMS keys. Expand each permission set in the picker for per-set scope-down guidance. If your CloudTrail bucket uses **SSE-KMS** encryption, the **S3 SSE-KMS log decryption** permission is what lets Clarion read the encrypted log files. If the bucket's KMS key does not delegate to IAM, you also need to allow the Clarion role on the key policy — see [AWS via EventBridge → SSE-KMS](/integrations/aws/eventbridge#step-1b-cloudtrail-via-consolidated-s3-logging). 6. You can ignore the popup that offers to create an agent for now — we'll [create the agent in Step 6](#step-6-create-an-agent). First we need to set up SNS so Clarion is notified when new files are added to the S3 bucket. *** ## Step 2 — Create an SNS topic 1. Open the Amazon **SNS** console and click **Create topic**. 2. Select the **Standard** type, give the topic a name (e.g. `clarion-cloudtrail-notifications`), and create it. 3. On the created topic, click **Create subscription**. 4. Copy the **Topic ARN** shown in the details — you'll paste it into Clarion next. S3 event notifications deliver only to an SNS topic in the **same region** as the bucket. Create the topic in the region of your CloudTrail bucket. *** ## Step 3 — Create the CloudTrail monitor in Clarion 1. Navigate back to Clarion and, on the AWS integration page, click **Add monitor**. 2. Select **AWS CloudTrail**. 3. Paste the SNS topic ARN into Clarion. Click **Add recommended filters** to apply Clarion's detection rules, then hit **Continue**. 4. Copy the **webhook URL**. You can ignore the rest of the instructions in the modal — simply close it by clicking **Done**. *** ## Step 4 — Subscribe Clarion to the SNS topic Back on the SNS topic's **Create subscription** screen, point the subscription at the Clarion webhook: 1. Set the protocol to **HTTPS**. 2. Paste the Clarion webhook URL as the **Endpoint**. 3. Create the subscription. Clarion auto-confirms it. *** ## Step 5 — Notify Clarion when new log files arrive Now configure the S3 bucket to publish to the SNS topic whenever CloudTrail writes a new log file. 1. Open **CloudTrail** and select your existing trail. 2. Under the trail details, find the **Trail log location** — this is the S3 bucket your CloudTrail logs are stored in. 3. Click the **Trail log location** link to open the bucket. 4. Using the breadcrumb navigation at the top, navigate up to the bucket itself (out of the log-location folder). 5. Open the **Properties** tab. 6. Scroll down to **Event notifications** and click **Create event notification**. 7. Add an event name and select **All object create events**. 8. Scroll down to **Destination**, select **SNS topic** as the destination, and use the dropdown to select the SNS topic you created in Step 2. Then hit **Save changes**. Clarion is now subscribed and S3 will notify it on every new CloudTrail log file. Next, create an agent so those events get triaged. *** ## Step 6 — Create an agent 1. Back in Clarion, select **Agents** on the left and click **Create agent**. 2. Select the **Cloud Security (AWS)** agent template and click **Continue**. 3. Next to **Monitors**, click **Add** and select **AWS CloudTrail**. 4. You'll see the monitor you created earlier — select it, and it's assigned to your agent. The agent's status automatically changes to **Watching** — you're all set. Done! Clarion now ingests CloudTrail events from your existing S3 bucket and your Cloud Security (AWS) agent triages them. # AWS via EventBridge and SNS Source: https://docs.clarion.cantina.xyz/integrations/aws/eventbridge Connect your AWS account to Clarion for CloudTrail events, CloudWatch alarms, GuardDuty findings, and IAM agent tools. This guide walks you through connecting your AWS account to Clarion. By the end, Clarion will receive CloudTrail events, CloudWatch alarms, and GuardDuty findings — and have IAM permissions to run agent tools (CloudTrail lookup, Route 53, CloudWatch queries). *** ## Prerequisites * An AWS account with admin or IAM-capable permissions. * Access to the Clarion dashboard. *** ## Step 0 — Generate a Webhook URL in Clarion Before configuring AWS subscriptions, open your Clarion workspace and generate a webhook URL. You will use this URL as the HTTPS subscription endpoint for your SNS topics in the steps below. Keep this URL handy — you'll need it for CloudTrail, CloudWatch, and GuardDuty setup. Clarion also requires the exact SNS topic ARN for each topic that publishes to the webhook. SNS messages are accepted only from topic ARNs saved in Clarion. Existing AWS monitors with no saved SNS topic ARN must be updated before Clarion can confirm subscriptions or receive notifications. *** ## Step 1 — CloudTrail via EventBridge Send CloudTrail management events (API calls and console sign-ins) to Clarion through an SNS topic and an EventBridge rule. This path sends the CloudTrail event body through EventBridge and SNS. Clarion does not need S3 bucket access for this delivery mode. ### 1.1 Create an SNS topic 1. Open the Amazon SNS console and go to **Topics**. 2. Create a new **Standard** topic (e.g. `clarion-cloudtrail`). 3. Copy the topic ARN, paste it into Clarion's SNS topic ARN field for the CloudTrail monitor, and save the monitor. Currently encryption of the topic is not supported, but Amazon SNS provides in-transit encryption by default. ### 1.2 Subscribe Clarion to the topic 1. On the topic you just registered in Clarion, click **Create subscription**. 2. Set the protocol to **HTTPS** and paste the webhook URL from Clarion. 3. SNS will send a confirmation request — Clarion auto-confirms it. ### 1.3 Create an EventBridge rule 1. Open the Amazon EventBridge console and create a new rule. 2. Use the following event pattern to forward all CloudTrail events to Clarion: ```json theme={null} { "detail-type": [ "AWS API Call via CloudTrail", "AWS Console Sign In via CloudTrail", "AWS Console Signin via CloudTrail", "AWS Service Event via CloudTrail" ] } ``` EventBridge detail-type matching is **case-sensitive**. The pattern above includes both known casing variants of the console sign-in detail-type (`Sign In` and `Signin`) to ensure events are captured regardless of the variant your account emits. Do **not** add a `source` filter — the `source` field varies by originating AWS service (e.g. `aws.iam`, `aws.ec2`, `aws.signin`) and filtering on it would silently drop events. These detail-types cover the following CloudTrail event categories: | Detail type | What it captures | Examples | | ------------------------------------ | ---------------------------------------- | ---------------------------------------------------------------------- | | `AWS API Call via CloudTrail` | All management and data API calls | `DeleteUser`, `PutBucketPolicy`, `RunInstances` | | `AWS Console Sign In via CloudTrail` | Console login and logout events | `ConsoleLogin` (success, failure, MFA) | | `AWS Service Event via CloudTrail` | Non-API events triggered by AWS services | Log file delivery, automated key rotation, service-linked role actions | Clarion has signal rules that depend on console sign-in events (login failures, MFA checks, root account logins, multi-IP detection), so including the console sign-in detail-types is important for full coverage. A fourth detail-type, `AWS Insight via CloudTrail`, exists for [CloudTrail Insights](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-insights-events-with-cloudtrail.html) anomaly detection events. Add it to the pattern if you have Insights enabled on your trail. 3. Set the target of the rule to the SNS topic you created (`clarion-cloudtrail`). *** ## Step 1B — CloudTrail via Consolidated S3 Logging An [AWS Organizations trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) writes CloudTrail events from every member account and region into a single S3 bucket — typically a dedicated log-archive account. Clarion subscribes to that bucket's S3 event notifications, fetches each new log file, and creates one signal per CloudTrail record. One SNS topic and one Clarion subscription cover the whole organization. For this consolidated S3 path, Clarion must be able to read each CloudTrail log object from S3. See [CloudTrail via existing S3 bucket](/integrations/aws/cloudtrail-s3) for the required IAM setup. ### 1B.1 Place the Clarion IAM role in the log-archive account Configure the Clarion IAM role from Step 4 **in the account that owns the consolidated CloudTrail bucket** — usually the AWS Organizations log-archive account. The role needs S3 read access to the CloudTrail log objects. ### 1B.2 Create an SNS topic for S3 notifications 1. In the log-archive account, open the SNS console and create a **Standard** topic in the same region as the consolidated log bucket (e.g. `clarion-cloudtrail-s3`). 2. Copy the topic ARN, add it to Clarion's **SNS topic ARN** list on the CloudTrail monitor, and save. S3 event notifications deliver only to SNS topics in the same region as the bucket. ### 1B.3 Subscribe Clarion to the topic 1. On the topic, click **Create subscription**. 2. Set the protocol to **HTTPS** and paste the webhook URL from Step 0. 3. Clarion auto-confirms the subscription. ### 1B.4 Configure S3 event notifications on the bucket 1. In the log-archive account, open the consolidated CloudTrail bucket in the S3 console. 2. Go to **Properties → Event notifications → Create event notification**. 3. Restrict the trigger to the CloudTrail prefix (e.g. `AWSLogs/`) and suffix `.json.gz`. 4. Event types: **All object create events** (`s3:ObjectCreated:*`). 5. Destination: **SNS topic**, then select the topic from 1B.2. ### 1B.5 (SSE-KMS only) Allow the Clarion role to use the bucket's KMS key If the consolidated log bucket uses SSE-KMS, the CMK's key policy must allow the Clarion IAM role from Step 4 to call `kms:Decrypt`. Keys created through the CloudTrail setup wizard delegate to IAM by default, in which case Clarion's role policy is sufficient and no key-policy change is needed. Otherwise, add the following statement to the CMK's key policy, replacing ``: ```json theme={null} { "Sid": "AllowClarionDecrypt", "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "kms:Decrypt", "Resource": "*" } ``` *** ## Step 2 — CloudWatch Alarms Send CloudWatch alarm state changes to Clarion by publishing to an SNS topic subscribed to your webhook URL. 1. Create a new SNS **Standard** topic for CloudWatch alarms (e.g. `clarion-cloudwatch`), or reuse a topic you have already registered in Clarion. 2. Copy the topic ARN, paste it into Clarion's SNS topic ARN field for the CloudWatch monitor, and save the monitor. 3. Add an **HTTPS** subscription using the webhook URL from Clarion. Wait for Clarion to auto-confirm. 4. In the CloudWatch console, open the alarm(s) you want Clarion to monitor. 5. Edit the alarm's notification actions and set it to publish to the SNS topic you created. You can point multiple alarms at the same SNS topic — no need to create one per alarm. *** ## Step 3 — GuardDuty Findings Route GuardDuty findings to Clarion through EventBridge and SNS. ### 3.1 Create an event bus 1. Open the Amazon EventBridge console. 2. You can use the **default** event bus, or create a new custom event bus if you want to isolate GuardDuty events (e.g. `clarion-guardduty-bus`). ### 3.2 Create an EventBridge rule for GuardDuty 1. Within the event bus, create a new rule. 2. Set the event source to GuardDuty findings. 3. Make sure you're using the following event pattern: ```json theme={null} { "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"] } ``` 4. Set the target to the SNS topic you created for Clarion. If you create a dedicated `clarion-guardduty` topic, copy that topic ARN into Clarion's SNS topic ARN field for the GuardDuty monitor and save before creating the HTTPS subscription. 5. Give the rule a descriptive name (e.g. `clarion-guardduty-findings`), review, and save. Make sure GuardDuty is enabled in your AWS account. If it's not yet active, enable it in the GuardDuty console first. *** ## Step 4 — IAM Role for Agent Tools Clarion needs an IAM role to run agent tools (CloudTrail lookup, Route 53, CloudWatch queries). You can set this up via the AWS Console or the AWS CLI. The generated policy uses `Resource: "*"` on every statement for convenience. Before production, deselect any permission sets you don't use and replace `"*"` with specific ARNs for your resources, such as SNS topics, S3 log buckets, Route 53 zones, and CloudWatch log groups. Expand each permission set in Clarion's permission picker for per-set scope-down guidance. *** ### Option A — AWS Console #### 1. Check for an existing role Go to **IAM console** > **Roles** and search for `ClarionIntegrationRole`. If it exists, skip to step 3 to update the trust policy. #### 2. Create the policy and role 1. Go to **IAM console** > **Policies** and create a new policy with the JSON below. 2. Then go to **IAM console** > **Roles** and create a new role. 3. Select **Custom trust policy** and paste the trust policy JSON below. 4. Attach the policy you just created. #### 3. Verify or update the trust policy 1. Open the role's **Trust relationships** tab. 2. Verify (or update) the trust policy to match: Trust Policy ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::762233769489:role/ClarionBridgeRole-20260319110823845000000001" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "" } } } ] } ``` #### 4. Copy the Role ARN Verify the permission policy is attached, then copy the **Role ARN** and paste it into Clarion. *** ### Option B — AWS CLI IAM Permission Policy ```json theme={null} { "Version": "2012-10-17", "Statement": [ { "Sid": "ClarionRoute53", "Effect": "Allow", "Action": [ "route53:ListHostedZones", "route53:GetHostedZone", "route53:ListResourceRecordSets", "route53:ChangeResourceRecordSets" ], "Resource": "*" }, { "Sid": "ClarionCloudWatch", "Effect": "Allow", "Action": [ "cloudwatch:ListMetrics", "cloudwatch:DescribeAlarms", "cloudwatch:GetMetricData" ], "Resource": "*" }, { "Sid": "ClarionCloudTrail", "Effect": "Allow", "Action": [ "cloudtrail:LookupEvents", "cloudtrail:DescribeTrails", "cloudtrail:GetTrailStatus" ], "Resource": "*" }, { "Sid": "ClarionSNS", "Effect": "Allow", "Action": [ "sns:CreateTopic", "sns:DeleteTopic", "sns:Subscribe", "sns:Unsubscribe", "sns:SetTopicAttributes", "sns:ListTopics", "sns:GetTopicAttributes", "sns:ListSubscriptionsByTopic" ], "Resource": "*" }, { "Sid": "ClarionEventBridge", "Effect": "Allow", "Action": [ "events:PutRule", "events:DeleteRule", "events:PutTargets", "events:RemoveTargets", "events:ListRules", "events:DescribeRule" ], "Resource": "*" } ] } ``` Run these commands in your terminal. Replace the Principal ARN and External ID with the values shown in your Clarion integration wizard. #### 1. Check if the role already exists ```bash theme={null} aws iam get-role \ --role-name ClarionIntegrationRole \ --query 'Role.Arn' --output text 2>/dev/null ``` If this prints an ARN, the role already exists — skip to step 4 to update its trust policy. Otherwise, continue with step 2. #### 2. Create the IAM policy ```bash theme={null} aws iam create-policy \ --policy-name ClarionIntegrationPolicy \ --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Sid": "ClarionRoute53", "Effect": "Allow", "Action": [ "route53:ListHostedZones", "route53:GetHostedZone", "route53:ListResourceRecordSets", "route53:ChangeResourceRecordSets" ], "Resource": "*" }, { "Sid": "ClarionCloudWatch", "Effect": "Allow", "Action": [ "cloudwatch:ListMetrics", "cloudwatch:DescribeAlarms", "cloudwatch:GetMetricData" ], "Resource": "*" }, { "Sid": "ClarionCloudTrail", "Effect": "Allow", "Action": [ "cloudtrail:LookupEvents", "cloudtrail:DescribeTrails", "cloudtrail:GetTrailStatus" ], "Resource": "*" }, { "Sid": "ClarionSNS", "Effect": "Allow", "Action": [ "sns:CreateTopic", "sns:DeleteTopic", "sns:Subscribe", "sns:Unsubscribe", "sns:SetTopicAttributes", "sns:ListTopics", "sns:GetTopicAttributes", "sns:ListSubscriptionsByTopic" ], "Resource": "*" }, { "Sid": "ClarionEventBridge", "Effect": "Allow", "Action": [ "events:PutRule", "events:DeleteRule", "events:PutTargets", "events:RemoveTargets", "events:ListRules", "events:DescribeRule" ], "Resource": "*" } ] }' ``` #### 3. Create the IAM role with trust policy ```bash theme={null} aws iam create-role \ --role-name ClarionIntegrationRole \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "" } } } ] }' ``` #### 4. Update the trust policy (existing role only) Run this instead of step 3 if the role already existed: ```bash theme={null} aws iam update-assume-role-policy \ --role-name ClarionIntegrationRole \ --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "" } } } ] }' ``` #### 5. Attach the policy to the role ```bash theme={null} aws iam attach-role-policy \ --role-name ClarionIntegrationRole \ --policy-arn "arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/ClarionIntegrationPolicy" ``` After running these commands, copy the Role ARN from step 1 (existing role) or step 3 (new role) and paste it into Clarion. *** ## Step 4B — Connecting Multiple AWS Accounts Agent MCP tools (`aws_describe`, `aws_logs_insights`, `aws_athena`, `aws_cloudtrail`, `inspect_alb_auth`) can target any account you connect to the workspace. Repeat Step 4 once per account: create a `ClarionIntegrationRole` in each account, give it the same trust policy and IAM policy, and add the role ARN to Clarion's AWS integration as a new connected account. When invoking an AWS MCP, the agent passes an `accountId` parameter to select which account the call should hit. Omitting the parameter falls back to the primary account. ### 4B.1 Pick a primary Exactly one connected account is marked **primary**. The primary's role is used whenever an MCP call omits `accountId`. Pick the account you query most often — typically the AWS Organizations log-archive account if you also use the consolidated-S3 ingest from [Step 1B](#step-1b-cloudtrail-via-consolidated-s3-logging). ### 4B.2 External ID By default every connected account uses the same workspace external ID, so you paste the same value into every role's trust policy. If you want stricter isolation between accounts (a separate external ID per account so a leak in one does not compromise the others), generate a per-account external ID in the Clarion UI's account-list panel and use that in the corresponding role's trust policy. ### 4B.3 IAM policy Every connected account's role uses the same IAM policy JSON from Step 4. Permission selection (the `iamPermissionGroupIds` list) is workspace-wide for now — every connected account is expected to honor the same set of granted permissions. Agents discover connected accounts through the MCP tool schema: passing an unknown `accountId` returns a structured error listing the known accounts so the agent can self-correct and retry. The agent does not have to enumerate accounts ahead of time — it can start with the account ID from a CloudTrail event's `recipientAccountId` and Clarion will route accordingly. *** ## Step 5 — Activate Monitors in Clarion 1. Go back to Clarion and add the **CloudTrail** monitor. 2. Enable all the rules, then confirm. 3. Review the listed event types and click to enable all relevant ones. 4. If you set up GuardDuty or CloudWatch, add the **GuardDuty** and **CloudWatch** monitors as well. These monitors receive GuardDuty findings and CloudWatch alarms directly, so you don't have to configure additional rules. You're done! Clarion is now receiving CloudTrail events, CloudWatch alarms, and GuardDuty findings from your AWS account. # Better Stack Source: https://docs.clarion.cantina.xyz/integrations/betterstack Uptime monitoring, incident alerts, and telemetry queries — connect Better Stack so agents can investigate and act on outages. Better Stack brings uptime incidents into Clarion and gives agents a wide tool surface over both **Uptime** (incidents, monitors, heartbeats, on-call, status pages) and **Telemetry** (log and metric queries, dashboards). **Estimated time:** 3 minutes. You will need a Better Stack **API token**. ## Prerequisites * A **Better Stack** account with Uptime and/or Telemetry * An API token with access to the resources you want Clarion to read ## Connect 1. In Better Stack, create an **API token**. 2. In Clarion, open **Integrations** and find **Better Stack**. 3. Paste the **API Token** and click **Connect**. ## What Clarion ingests Uptime incidents and alerts feed the [Infrastructure & Ops](/learn/agents/our-agents) agent's outage runbook. ## What agents can do Better Stack has one of the broadest tool surfaces in Clarion. The highlights: **Incidents** — list and read incidents, read the incident timeline and comments, add a comment, acknowledge, resolve, create, and escalate an incident; read escalation options, policies, and severities. **Monitoring** — list and read monitors, heartbeats, and their availability and response-time history. **On-call** — read the current on-call, on-call events, and rotations. **Status pages** — list and read status pages and their resources, and publish a status-page report and updates. **Telemetry** — run log and metric queries, build explore and metric queries, read sources and their fields, inspect errors and update their state, list releases and applications, and create or edit dashboards and charts. Several of these write to Better Stack — resolving an incident, publishing a status-page update, creating a dashboard. They are gated by your workspace's tool policy and ask for approval unless explicitly allowed. ## Disconnect Click **Disconnect** on the integration page. The stored token is deleted and the tools disappear from agent skills. # Cantina Bug Bounty Source: https://docs.clarion.cantina.xyz/integrations/cantina-bbp Route Cantina bug bounty submissions into Clarion for automatic triage, spam filtering, and remediation PRs. If you run a bug bounty program on [Cantina](https://cantina.xyz), this integration delivers submissions into Clarion as issues so an agent can triage them before a human spends time on them. **Estimated time:** 2 minutes. You will need a Cantina bug bounty program. ## Connect 1. In Clarion, open **Integrations** and find **Cantina BBP**. 2. Click **Connect**. Submissions from your programs start flowing in as issues. ## What the agent does The [Cantina Bug Bounty](/learn/agents/our-agents) agent triages each submission: * **Closes spam** and low-quality reports without escalating. * **Notifies** your team on submissions that look real, with an assessment of impact. * **Opens a remediation pull request** where the fix is tractable, using the [GitHub](/integrations/github) integration. Connect GitHub as well. Without it the agent can assess a finding but not act on it. ## Disconnect Click **Disconnect** on the integration page. New submissions stop reaching Clarion; existing issues are unaffected. # Claude Code Source: https://docs.clarion.cantina.xyz/integrations/claude-code Ingest OpenTelemetry from your developers' Claude Code installs to govern MCP servers, spot external accounts, and catch credential-shaped tool use. Claude Code emits OpenTelemetry. Point it at Clarion and you get a security view of how your engineering org actually uses AI coding agents: which MCP servers they connect, whose accounts are outside your company, and which sessions read a credential and then reached the network. **Estimated time:** 10 minutes. You will need admin access to your organization's Claude managed settings. ## Prerequisites * Claude Code deployed across your developer fleet * Ability to push **managed settings** to those installs * Your company's domains set in [Workspace settings](/learn/settings/workspace) — the external-account rule reads every account as external until they are ## Step 1 — Create the monitor in Clarion 1. In Clarion, open **Integrations** and find **Claude Code**. 2. Click **Connect** and create a monitor. Clarion generates: * An **ingest endpoint URL** carrying the monitor id. * A **bearer secret**, shown exactly once. Copy the secret when it is shown. Clarion does not display it again. The secret travels in an OTLP header, never in the URL. ## Step 2 — Push managed settings Clarion generates the JSON block to paste into your Claude managed settings: ```json theme={null} { "env": { "CLAUDE_CODE_ENABLE_TELEMETRY": "1", "OTEL_LOGS_EXPORTER": "otlp", "OTEL_METRICS_EXPORTER": "otlp", "OTEL_TRACES_EXPORTER": "otlp", "OTEL_EXPORTER_OTLP_PROTOCOL": "http/json", "OTEL_EXPORTER_OTLP_ENDPOINT": "https:///api/webhooks/claude-code/", "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer ", "OTEL_LOG_TOOL_DETAILS": "1", "OTEL_METRICS_INCLUDE_ENTRYPOINT": "true" } } ``` Copy it from the integration page rather than from here — it comes pre-filled with your endpoint and secret. Findings are only as complete as your telemetry. If OTEL logging is partial across the fleet, so is the picture Clarion builds. `OTEL_LOG_TOOL_DETAILS` is what makes tool-level governance possible; without it, MCP server use is invisible. ## What Clarion builds from it **MCP server governance.** Every MCP server your developers connect is inventoried with who uses it and how often. Servers sit in an undecided bucket until somebody rules on them — and the [Claude Code Governance](/learn/agents/our-agents) agent sweeps that bucket daily and puts the whole batch in front of a human as **one** decision rather than a trickle of prompts. Use of a server somebody already denied raises an issue immediately. **Identity.** Telemetry reported from an account outside your company's domains is surfaced and triaged. This is how a personal account doing company work, or a contractor still connected after offboarding, shows up. **Credential-shaped tool use.** Sessions that read a credential-shaped path and then reached the network are flagged for triage — the pattern behind an agent exfiltrating a key, whether deliberately or by accident. ## Related agent The [Claude Code Governance](/learn/agents/our-agents) agent ships four skills: MCP server governance triage, MCP inventory review sweep, external account triage, and credential-harvesting triage. ## Disconnect Click **Disconnect** on the integration page, then remove the OTEL environment variables from your managed settings. Telemetry sent after disconnection is rejected. # Cloudflare Source: https://docs.clarion.cantina.xyz/integrations/cloudflare Connect Cloudflare to Clarion for Cloudflare Notifications webhooks, Logpush detection monitors, and optional API-powered DNS and analytics agent tools. This guide walks you through connecting Cloudflare to Clarion and configuring Cloudflare Notifications monitors. By the end, Clarion will receive Cloudflare notification policies through one or more Cloudflare Notifications monitors, and optionally have an API token available for DNS tools and WAF/DDoS firewall-event investigation during incident response. For Cloudflare Logpush detection windows, use the dedicated [Cloudflare Logpush](/integrations/cloudflare-logpush) guide. **Estimated time:** 5-10 minutes. You will need a **Clarion workspace** and access to the **Cloudflare dashboard** for the account or zones you want to monitor. ## Prerequisites * A **Clarion workspace** * Access to **Cloudflare** * Permissions to create **webhook destinations** and **notification policies** in Cloudflare *** ## Step 1 — Connect Cloudflare in Clarion 1. In Clarion, go to **Settings > Integrations** 2. Find **Cloudflare** 3. Click **Connect** This creates the Cloudflare integration in Clarion. Use the integration to save an optional API token for Clarion agent tools, and use Cloudflare Notifications monitors to generate webhook URLs and secrets for notification delivery. *** ## Step 2 — Optional: Save a Cloudflare API token If you want Clarion agents to use Cloudflare DNS, zone-management, and WAF/DDoS Analytics tools during investigations, save an API token on the Cloudflare integration. 1. In the Cloudflare integration page in Clarion, open the **API Token** section 2. In Cloudflare, go to **Manage Account > Account API Tokens** 3. Create an **account-owned API token** 4. Grant **Zone:Read**, **DNS:Read**, **DNS:Edit**, **Account Settings:Read**, and **Zone Analytics:Read** 5. Paste the token into Clarion 6. Wait for Clarion to verify it, then click **Save** The token should include these permissions: * **Zone:Read** * **DNS:Read** * **DNS:Edit** * **Account Settings:Read** * **Zone Analytics:Read** This token is optional for Cloudflare Notifications delivery. You only need it if you want Clarion agents to use Cloudflare API tools. Cloudflare Notifications can trigger WAF/DDoS triage without Cloudflare Logpush. With **Zone Analytics:Read**, Clarion agents can query Cloudflare GraphQL Analytics for sampled firewall events, compare a current wave against a prior window, and report source IPs/ASNs, paths, user agents, countries, rules, action mix, and any allowed traffic. Use [Cloudflare Logpush](/integrations/cloudflare-logpush) only when you want Clarion to ingest and detect from Logpush events directly. Use an account-owned token instead of a user token for shared integrations. Account-owned tokens are more durable because they are not tied to one person's profile. *** ## Step 3 — Add one or more Cloudflare Notifications monitors 1. In Clarion, add a **Cloudflare Notifications** monitor from the Integrations page or the agent monitor setup flow 2. Give the monitor a clear name for the Cloudflare notification policy or policy group it will receive 3. Save the monitor When each monitor is created, Clarion generates: * A **Webhook URL** * A **Webhook secret** Copy both values from the monitor configuration screen. You can create multiple Cloudflare Notifications monitors when you want different Cloudflare notification policies to use different webhook destinations, secrets, or Clarion agents. If you replace the webhook secret in Clarion later, update the same secret in Cloudflare before sending new notifications. *** ## Step 4 — Create Cloudflare webhook destinations In Cloudflare: 1. Go to **Notifications > Destinations > Webhooks** 2. Click **Create** 3. Give the destination a name you will recognize later 4. Paste the **Webhook URL** from Clarion into the destination URL field 5. Paste the **Webhook secret** from Clarion into the secret field 6. Click **Save and Test** Create one Cloudflare webhook destination for each Clarion monitor you want to route separately. Each destination is what the selected notification policies will send to. *** ## Step 5 — Create notification policies in Cloudflare After the webhook destination exists: 1. Go to **Notifications > Add** 2. Select the notification type you want to send to Clarion 3. Fill in the required fields for that notification 4. When Cloudflare shows a delivery or destination section, choose the webhook destination for the Clarion monitor that should receive that policy 5. Save the notification policy Common notification policies to forward to Clarion include: * **DDoS** * **Origin errors** * **Health checks** * **WAF events** * **SSL or certificate events** You can attach multiple Cloudflare notification policies to the same Clarion webhook destination, or split policies across multiple Clarion monitors by using different webhook destinations. If a Cloudflare notification form only shows **Notification email** fields and does not show a webhook destination selector, Cloudflare is not offering webhook delivery for that notification in your current account. If your Cloudflare account only has **Free** zones, this is expected. Cloudflare Notifications webhooks are not available on a free-only account, so you will only be able to use email delivery. Cloudflare's docs say webhook availability depends on account eligibility and the highest zone plan in the account. If the account has at least one eligible paid zone, Cloudflare may expose webhook destinations for supported notification types. *** ## What happens next Once configured, Clarion will: * Receive Cloudflare Notifications webhooks at the monitor webhook URL * Open issues from supported Cloudflare notification events * Triage those issues with Clarion agents * Query Cloudflare Analytics for WAF/DDoS firewall-event evidence when an API token with **Zone Analytics:Read** is saved If notifications stop arriving after rotating the secret, verify that the secret stored in the Clarion monitor matches the one configured on the Cloudflare webhook destination. # Cloudflare Logpush Source: https://docs.clarion.cantina.xyz/integrations/cloudflare-logpush Send Cloudflare firewall_events Logpush batches to Clarion for L7 DDoS-like detection windows. This guide walks you through configuring a Cloudflare Logpush monitor in Clarion. Clarion receives Cloudflare zone `firewall_events` rows, builds compact detection windows, and opens issues on L7 DDoS-like security-event flood patterns. Cloudflare Logpush is available on Enterprise plans. Clarion does not backfill historical Logpush data; detections start from the time Cloudflare begins sending rows to the monitor. ## Prerequisites * A **Clarion workspace** * A connected **Cloudflare** integration in Clarion * Access to a Cloudflare Enterprise zone * Permission to create zone Logpush jobs * The hostname or hostnames you want Clarion to evaluate ## Step 1 — Add a Cloudflare Logpush monitor 1. In Clarion, go to **Settings > Integrations > Cloudflare** 2. Open the **Monitors** tab 3. Click **Add monitor** 4. Choose **Cloudflare Logpush** 5. Enter a zone name and, optionally, the Cloudflare zone ID 6. Choose the host scope: * **Exact host** for one hostname * **Selected hosts** for multiple hostnames 7. Enter plain hostnames only, such as `app.example.com` or `api.example.com` 8. Choose a sensitivity level 9. Save the monitor Clarion generates a **Webhook URL** and **Webhook secret**. Copy both values before configuring Cloudflare. If you rotate the secret in Clarion, update the Cloudflare Logpush destination header before sending more data. Clarion matches Logpush rows against `ClientRequestHost`. Do not include schemes, paths, ports, or wildcards in the host list. ## Step 2 — Create the Logpush job in Cloudflare In the Cloudflare dashboard, open the same zone you configured in Clarion, then go to **Analytics & Logs > Logpush** and create a Logpush job. Use these settings: | Cloudflare setting | Value | | --------------------------- | ------------------------------ | | Dataset | `firewall_events` | | Destination type | HTTP destination | | Destination URL | The Clarion **Webhook URL** | | Destination parameter name | `header_cf-webhook-auth` | | Destination parameter value | The Clarion **Webhook secret** | | Output type | `ndjson` | | Timestamp format | `rfc3339` | Cloudflare sends destination parameters that start with `header_` as HTTP headers. The `header_cf-webhook-auth` parameter makes Cloudflare send the Clarion secret in a `cf-webhook-auth` header. If you configure Logpush through the Cloudflare API or Terraform, put the header parameter in `destination_conf` and URL-encode the secret: ```text theme={null} ?header_cf-webhook-auth= ``` Do not put the webhook secret in the monitor name, host scope, or any other descriptive field. Store it only as the Cloudflare HTTP destination header value. ## Step 3 — Include the required Logpush fields Configure the Logpush job to include these `firewall_events` fields: ```text theme={null} Datetime RayID Action ClientRequestHost ClientRequestPath ClientCountry ClientASN OriginResponseStatus EdgeResponseStatus ClientIP RuleID Source Description MatchIndex ``` Clarion uses these fields to deduplicate rows, scope detections to the configured hostnames, aggregate hot paths and source traits, and classify Cloudflare mitigation actions. Clarion does not store raw Logpush rows. It summarizes rows for detection and hashes client IP values before retaining compact aggregates. ## Step 4 — Save and validate the Logpush job Cloudflare validates HTTP destinations with a gzipped JSON test upload (`{"content":"tests"}`). Clarion accepts that validation upload and returns success when the monitor secret matches. After validation succeeds, enable the Logpush job. New detections can be created once Cloudflare begins delivering current `firewall_events` rows to the monitor. ## Step 5 — Understand direct delivery limits Cloudflare can send batches smaller than 5 MB, but its `max_upload_bytes` setting cannot be configured below 5 MB. If a zone produces an unusually large Logpush batch, delivery may be rejected and retried by Cloudflare. Keep the host scope focused on the hostnames you want Clarion to monitor. ## What Clarion detects Clarion monitors for DDoS-like L7 security-event flood patterns visible in Cloudflare `firewall_events`. This detector does not claim to detect allowed-only traffic floods or total origin traffic volume. It relies on Cloudflare security events such as blocked, challenged, managed challenge, and rate-limited traffic. The initial detection pack is **Zone Security** with the **L7 DDoS** detector. Sensitivity controls the event-volume thresholds Clarion uses before opening high or critical detections. ## Operational notes * Multiple Cloudflare Notifications monitors and multiple Cloudflare Logpush monitors can coexist. * Use separate Logpush monitors when different host groups should route to different Clarion agents. * Cloudflare limits Logpush to four jobs per dataset per zone. * Rows should be delivered promptly; significantly delayed rows may not be evaluated. * If Cloudflare retries the same batch, Clarion deduplicates rows and replayed request bodies. ## Troubleshooting If Cloudflare validation fails: * Confirm the destination URL exactly matches the Clarion **Webhook URL** * Confirm the destination parameter is named `header_cf-webhook-auth` * Confirm the destination parameter value matches the Clarion **Webhook secret** * If you replaced the secret in Clarion, update the Cloudflare destination before testing again If Logpush delivers successfully but Clarion does not open detections: * Confirm `ClientRequestHost` exactly matches the monitor host scope * Confirm the Logpush job is sending the `firewall_events` dataset * Confirm the required fields are included in the job output * Check whether traffic is below the selected sensitivity threshold * Remember that allowed-only origin floods are outside this detector's scope References: [Cloudflare Logpush](https://developers.cloudflare.com/logs/logpush/), [Cloudflare HTTP destinations](https://developers.cloudflare.com/logs/logpush/logpush-job/enable-destinations/http/), [Cloudflare firewall\_events fields](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/zone/firewall_events/). # Confluence Source: https://docs.clarion.cantina.xyz/integrations/confluence Connect Confluence Cloud to Clarion with an Atlassian service account so agents can read and search documentation for context during triage. This guide shows how to connect Confluence Cloud to Clarion using an Atlassian service account and OAuth 2.0 client credentials. **Estimated time:** 10-15 minutes. You need access to: * A **Clarion workspace** * **Atlassian Administration** for your Confluence site * A service account that can view and search content in the Confluence spaces you want Clarion to use ## Prerequisites Before connecting Confluence in Clarion, make sure you have: * Your Confluence site URL, for example `https://example.atlassian.net` * A Confluence service account with access to the relevant spaces * An OAuth 2.0 credential created for that service account * These credential scopes (granular — Clarion uses the Confluence REST API v2): * `read:page:confluence` * `read:space:confluence` * `search:confluence` Clarion uses the service account’s client credentials to request short-lived Confluence access tokens automatically. You do not need to reconnect the integration just because an access token expires. *** ## Step 1 - Create a Confluence service account 1. In **Atlassian Administration**, open **Directory** and create a **service account**. 2. Grant the service account access to **Confluence**. 3. Make sure the service account has access to the spaces Clarion will read. The service account should be able to: * Search content * View page content * List spaces *** ## Step 2 - Create OAuth 2.0 credentials for the service account 1. Open the service account in **Atlassian Administration**. 2. Go to **Credentials**. 3. Create an **OAuth 2.0** credential. 4. Grant only these scopes: * `read:page:confluence` * `read:space:confluence` * `search:confluence` 5. Copy the **Client ID** and **Client secret**. Keep the client secret somewhere safe. You will paste it into Clarion during setup. *** ## Step 3 - Connect Confluence in Clarion 1. In Clarion, go to **Integrations**. 2. Open **Confluence**. 3. Enter: * **Site URL** * **Client ID** * **Client Secret** * **Default Space Key** (optional) 4. Click **Connect Confluence**. *** ## Step 4 - Verify and maintain the connection After connecting: 1. Review the saved Confluence site and client ID. 2. Set or update **Default Space Key** if you want Clarion to scope searches to a space automatically. 3. Click **Save** after any changes. 4. Click **Verify Connection** to confirm Clarion can access Confluence successfully. 5. Use **Disconnect** if you want to remove Confluence access from the workspace. Agents can still pass a space in CQL per tool call. If omitted, Clarion uses the configured default space key when scoping a search. *** ## How Confluence tools use this integration When Confluence tools are enabled, Clarion can: * Search pages with CQL * Read a page by id * List spaces Clarion manages Confluence access tokens automatically from the stored client credentials. *** ## Troubleshooting ### "Failed to resolve Confluence cloud ID" Check that **Site URL** is exactly your Confluence Cloud URL, for example: * `https://example.atlassian.net` Do not include a path such as `/wiki`, `/spaces`, or `/display`. ### "Confluence credential is missing required scopes" Recreate or update the OAuth 2.0 credential so it includes: * `read:confluence-content.all` * `read:confluence-space.summary` * `search:confluence` ### Verify Connection fails even though the credential is valid Make sure the service account itself has Confluence product access and space-level permissions in the spaces Clarion needs to read. # CrowdStrike Falcon Source: https://docs.clarion.cantina.xyz/integrations/crowdstrike Connect CrowdStrike Falcon to Clarion to poll detections and cases from your Falcon tenant and surface them as signals and issues. This guide walks you through connecting a CrowdStrike Falcon tenant to Clarion via the Falcon OAuth2 API. Once connected, Clarion polls Falcon every minute for new detections and cases, uses them to drive issues and agent triage, and discovers your Falcon host roster into the Brain as device assets. **Estimated time:** 5 minutes. You will need a **CrowdStrike Falcon** account with permission to create API clients. ## Prerequisites * A **CrowdStrike Falcon** tenant and access to **Support and resources → API clients and keys** * A **Clarion workspace** where you can add a monitor * A secure place to store the **Client ID** and **Client Secret** generated in Falcon *** ## Step 1 — Pick your Falcon cloud region In Clarion, open **Integrations** → **CrowdStrike**, then **Add Monitor**. On the configuration screen, choose the cloud region that matches your Falcon Console URL: | Region | Console URL | | -------- | ------------------------------------------- | | US-1 | `https://falcon.crowdstrike.com` | | US-2 | `https://falcon.us-2.crowdstrike.com` | | EU-1 | `https://falcon.eu-1.crowdstrike.com` | | US-GOV-1 | `https://falcon.laggar.gcw.crowdstrike.com` | | US-GOV-2 | `https://falcon.us-gov-2.crowdstrike.com` | The "Sign in to your Falcon Console" link in the form updates to point at the region you select. *** ## Step 2 — Create an API client in Falcon 1. Sign in to the **Falcon Console** for your region. 2. Go to **Support and resources** → **API clients and keys**. 3. Click **Create API client** and grant the scopes listed in the Clarion setup instructions. ### Scopes Grant **Read** access to the following scopes so Clarion can poll detections, cases, and supporting context: Alerts, App Logs, Apps, Cases, Correlation Rules, Custom IOA rules, Detections, Device Content, Device control policies, Hosts, Firewall management, IOC Management, IOCs (Indicators of Compromise), Prevention policies, Quarantined Files, Real time response (admin), Real time response app, Real time response audit, Real time response, Response policies, Event streams. **Hosts (Read)** is what powers device discovery into the Brain — keep it granted even if you trim the list above. If you want Clarion to interact with Cases, Real-Time Response, and similar surfaces and make remediation or containment actions, also grant **Write** access to the relevant scopes. Most write actions require human approval in Clarion before the agent executes them. 4. Copy the generated **Client ID** and **Client Secret**. Copy the Client Secret immediately — Falcon only shows it once. Store it securely. *** ## Step 3 — Enter the credentials in Clarion 1. Back in the Clarion monitor form, paste the **Client ID** and **Client Secret**. 2. Click **Save**. Clarion validates the credentials and begins polling Falcon every minute for new detections and cases. *** ## What happens next Once connected, Clarion will: * Poll Falcon every minute for new **detections** (surfaced as signals) and **cases** (surfaced as issues) * Run your configured signal rules against incoming detections to promote matching events into issues * Hand issues to any connected triage agents * Discover your Falcon **host roster** into the Brain as **device** assets (OS, platform, serial, last-seen). When a workstation's last login matches a synced identity (Okta / Google Workspace), the device is linked to its owner, so an issue involving that user surfaces their endpoints. Devices refresh on each asset sync (manual **Sync** or the scheduled auto-update). You can manage the monitor — pause polling, rotate credentials, or view sync status — from the **Monitors** section on the CrowdStrike integration page. ## Agent tools Once connected, your triage agents can use CrowdStrike tools to investigate and respond to alerts directly in Falcon: * **Endpoint Detection & Response** — Investigate Falcon alerts, inspect hosts, contain compromised endpoints, manage IOCs, and run Real-Time Response sessions. Attach these tools to a skill in the skill editor. Destructive actions (host containment, IOC creation, Real-Time Response commands) require human approval by default and can be reviewed before the agent executes them. *** ## Monitoring multiple Falcon tenants CrowdStrike is configured **per monitor**: each Falcon tenant (each Client ID / Client Secret pair) is its own monitor in Clarion, with its own cursors and sync health. To monitor a second tenant, click **Add Monitor** again on the integration page and enter that tenant's credentials. *** ## Sync historical cases The monitor only polls forward from the moment it's connected. To pull in cases and detections from before that point: 1. Open the monitor from the **Monitors** section on the **Integrations → CrowdStrike** page. 2. Click **Sync historical cases**. 3. Confirm the action. Clarion rewinds the monitor's cursors to **7 days ago** and replays everything Falcon has created since. Items already imported are deduplicated by Falcon id, so this is safe to re-run. *** ## Update or rotate credentials To replace a Client Secret (for example, after rotating it in Falcon): 1. Generate a new Client Secret in Falcon under **Support and resources → API clients and keys**. 2. In Clarion, open the monitor. 3. Paste the new secret into **Update Client Secret** and click **Save**. Leave the field blank to keep the existing secret when you only want to change the cloud region or Client ID. *** ## Troubleshooting ### The connection fails or events stop arriving * Confirm the cloud region matches your Falcon Console URL exactly (e.g. a US-2 tenant paired with a US-1 selection will not authenticate). * Verify the API client in Falcon has the scopes listed in the Clarion setup instructions and has not been revoked. * Use **Sync now** on the monitor to trigger an immediate poll and surface the underlying Falcon error in the toast. # Custom MCP Source: https://docs.clarion.cantina.xyz/integrations/custom-mcp Connect any MCP-compatible HTTP server to extend Clarion agents with your own tools. This guide walks you through connecting a custom MCP server to Clarion. Once connected, every tool your server exposes becomes available to Clarion agents during triage and response. **Estimated time:** 2 minutes. You will need a **Clarion workspace** with permission to manage integrations and an MCP-compatible HTTP server that Clarion can reach over the public internet. ## Prerequisites * A **Clarion workspace** with permission to manage integrations * An **MCP server** that speaks the [Streamable HTTP transport](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) and is reachable from Clarion * (Optional) an **API key** if your server requires authentication — Clarion sends it as `Authorization: Bearer ` on every request *** ## Step 1 — Add an MCP server 1. In Clarion, go to **Settings > Integrations** 2. Scroll to the **Custom MCPs** section and click **Add MCP Server** 3. Fill in the form: * **Name** — a short label for this server (e.g. `My Security Scanner`). Clarion slugifies the name and registers the server as `custom-` so it can never shadow a built-in MCP server * **Server URL** — the HTTP endpoint of your MCP server (e.g. `https://mcp.example.com`) * **API key** *(optional)* — sent as `Authorization: Bearer ` on every request to your server 4. Click **Connect** Clarion validates the connection before saving — if the server is unreachable or doesn't speak MCP, the form surfaces the error and nothing is stored. You can add multiple custom MCP servers to a single workspace. Each one shows up as its own card on the Integrations page. *** ## Step 2 — Verify the tools Once connected, the server card shows the number of tools Clarion discovered. Open the card's **View tools** menu to see each tool's name and description as advertised by your server. If you don't see the tools you expect, double-check that your server returns them from the MCP `tools/list` method and that the names contain no underscores in the server segment. *** ## What Clarion can do After connecting, agents can: * **Invoke any tool** your MCP server exposes — Clarion forwards the call through a proxy that authenticates the agent and attaches your API key on every request * **See tool descriptions** straight from your server, so updating the description on your side is enough to update what the agent sees Clarion does not modify or cache your tool schemas — every agent run pulls the live list from your server. *** ## Security model * Your **server URL** and **API key** are stored encrypted and only decrypted server-side when a Clarion agent needs to call your server. The API key is never bundled into agent sandbox code or exposed to agent prompts. * Requests from Clarion agents are proxied through Clarion's backend — your server only ever sees traffic from Clarion's IPs, never from the agent sandbox directly. * Clarion validates the upstream URL before each call to prevent SSRF against internal addresses. * Treat the tools your MCP server exposes as **attacker-controlled input** to Clarion agents. Tool descriptions and outputs can contain instructions — Clarion already redacts secrets in transcripts, but only connect servers you trust. *** ## Remove an MCP server To remove a server: 1. Open **Settings > Integrations** in Clarion 2. Find the server card under **Custom MCPs** 3. Click the menu (**⋯**) and choose **Remove** 4. Confirm the dialog Removing a server deletes its stored URL and API key from Clarion immediately and revokes agent access to its tools. Anything your server already did on Clarion's behalf stays in place — only the connection is removed. # Custom toolset (API) Source: https://docs.clarion.cantina.xyz/integrations/custom-toolset Turn any REST API into agent tools by pointing Clarion at its documentation. When a system has no Clarion integration and no MCP server, a **custom toolset** closes the gap. Give Clarion the API's base URL and its documentation, and it infers the tools — which you then review before any agent sees them. This is different from a [custom MCP server](/integrations/custom-mcp). Use custom MCP when the vendor already ships an MCP server. Use a custom toolset when they don't. ## Create one 1. In Clarion, open **Integrations → Custom toolsets** and click **Add**. 2. Give it a **name** — this becomes the tool namespace agents see. 3. Enter the API's **base URL**. 4. Configure **authentication**: | Auth | Sends | | ---------- | ------------------------------- | | **None** | Nothing — for public APIs | | **Bearer** | `Authorization: Bearer ` | | **Header** | A custom header name and value | | **Basic** | Username and password | | **Query** | A key as a query parameter | 5. Provide **documentation** — paste text, link a URL, or upload a file. 6. Click **Scan**. Clarion reads the docs and proposes a list of tools. Credentials are encrypted at rest and attached to the request outside the sandbox, so an agent never sees the key it is authenticating with. ## Review before enabling The inferred tool list is a **proposal**, not a live surface. Every tool is disabled until you enable it, and only enabled tools are exposed to agents. Review each one's name, description, and parameters before turning it on — the description is what an agent reasons about when deciding to call it. Enable the narrowest set that does the job, and be deliberate about anything that writes. A tool an agent can call is a tool an agent can be talked into calling. Responses pass through secret redaction before they reach a transcript or the UI. ## Rescans Clarion hashes the normalized documentation. Rescanning after an unchanged doc is a no-op; when the docs change, you get a fresh proposal to review rather than silent drift in what your agents can do. ## Use in skills Once enabled, a custom toolset's tools appear in the skill editor's tool picker like any other integration's, and can be embedded in skill content. ## Delete Delete the toolset from **Integrations → Custom toolsets**. Stored credentials are removed, and skills referencing its tools surface them as missing. # Datadog Source: https://docs.clarion.cantina.xyz/integrations/datadog Connect Datadog so agents can query your logs, APM, events, and service catalog — and manage Datadog cases — during triage. This guide walks you through connecting Datadog to Clarion. Once connected, AI agents can pull observability context from Datadog while they triage — searching logs, APM spans, events, and the service catalog — and manage [Datadog cases](https://docs.datadoghq.com/service_management/case_management/) to track their findings alongside your team. **Estimated time:** 5-10 minutes. You will need permission to create **API** and **Application keys** in your Datadog organization, plus access to the Clarion workspace where you want to connect Datadog. ## What you'll configure | What | Purpose | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Datadog site** | The region your organization runs in (e.g. US1, EU1). Clarion uses it to reach the correct Datadog API and dashboard. | | **API key** | Identifies your Datadog organization on every request. | | **Application key** | Authorizes the specific actions agents can take. The scopes you grant it determine which tools work — see [Step 3](#step-3-create-an-application-key). | Clarion talks to Datadog through Datadog's official [Bits AI MCP server](https://docs.datadoghq.com/bits_ai/mcp_server/). Your keys are stored encrypted and injected server-side when an agent calls a Datadog tool — they are never exposed to the agent's sandbox or written into transcripts. ## Prerequisites * A **Datadog** account on a [supported site](#step-1-choose-your-datadog-site) * Permission to create **API keys** and **Application keys** (Organization Settings) * Datadog's **MCP server (Bits AI)** available for your organization — see [Datadog's setup docs](https://docs.datadoghq.com/bits_ai/mcp_server/setup/) * A **Clarion workspace** with the Datadog integration page open *** ## Step 1 — Choose your Datadog site Clarion supports the regions where Datadog publishes its MCP server: | Site | Value | | ---- | ------------------- | | US1 | `datadoghq.com` | | US3 | `us3.datadoghq.com` | | US5 | `us5.datadoghq.com` | | EU1 | `datadoghq.eu` | | AP1 | `ap1.datadoghq.com` | | AP2 | `ap2.datadoghq.com` | Check the URL you use to reach Datadog to confirm your site. US1-FED and US2-FED (GovCloud) are not supported. *** ## Step 2 — Create an API key 1. In Datadog, go to **Organization Settings → API Keys**. 2. Click **New Key**, give it a name (e.g. `Clarion`), and create it. 3. Copy the key value. *** ## Step 3 — Create an Application key The Application key's **scopes** decide which tools agents can use. Create it with the full set below so every Datadog tool works; grant a subset if you only want certain capabilities. 1. In Datadog, go to **Organization Settings → Application Keys**. 2. Click **New Key**, name it (e.g. `Clarion`), and add these scopes: | Scope | Unlocks | | ---------------------------------------- | ------------------------------------------------- | | `mcp_read` | Base scope required for **all** Datadog tools | | `logs_read_data`, `logs_read_index_data` | Log Search | | `apm_read` | APM Span Search | | `apm_service_catalog_read` | Service Catalog & Service Dependencies | | `teams_read` | Service Dependencies and services owned by a team | | `events_read`, `timeseries_query` | Event Search | | `cases_read` | Case search and read (cases and projects) | | `cases_write` | Create / update cases, add comments, link Jira | | `user_access_read` | User Search (resolving case assignees) | 3. Copy the key value. If an Application key is missing a scope, the matching tools fail at call time rather than at setup. If a tool returns a permissions error during triage, re-check the key's scopes here. *** ## Step 4 — Connect Datadog in Clarion 1. In Clarion, open **Integrations** and find **Datadog**. 2. Select your **Datadog site** from Step 1. 3. Paste your **API Key** (Step 2) and **Application Key** (Step 3). 4. Click **Save**. To rotate keys later, return to this page and enter new values. To remove the integration entirely, see [Disconnect](#disconnect). *** ## What agents can do Once connected, agents on this workspace can use the Datadog tools below. Add the ones you want to a skill the agent runs (for example, an enrichment skill that gathers observability context, or a triage skill that opens a case for confirmed issues). ### Observability (read-only) | Tool | What it does | | ------------------------ | -------------------------------------------------------------- | | **Log Search** | Search logs by service and time range | | **APM Span Search** | Search APM spans — request URLs, headers, and body tags | | **Event Search** | Search deployments, monitor alerts, and infrastructure changes | | **Service Catalog** | List services with their runtime and topology | | **Service Dependencies** | Map upstream and downstream service dependencies | ### Case Management | Tool | Type | What it does | | ----------------------------------- | ----- | ------------------------------------------------------- | | **Case Search** | Read | Find cases by status, priority, project, or assignee | | **Case Details** | Read | Full case, including timeline and custom attributes | | **Case Projects / Project Details** | Read | List and inspect the projects cases live in | | **User Search** | Read | Resolve a Datadog user to assign a case to | | **Create Case** | Write | Open a case to track an investigation | | **Update Case** | Write | Change status, priority, assignee, or other fields | | **Add Case Comment** | Write | Post a markdown comment to a case's timeline | | **Link Jira to Case** | Write | Link a Jira issue to a case for cross-platform tracking | The case **write** tools (Create, Update, Add Comment, Link Jira) require approval by default — the agent pauses and waits for a human before it changes anything in your Datadog workspace. You can adjust this per tool or per action under **Workspace → Tools**. **Link Jira to Case** also requires a Jira integration configured on the Datadog side. *** ## Disconnect To remove the integration: 1. In Clarion, open **Integrations → Datadog**. 2. Click **Disconnect**. This deletes the stored API and Application keys. Agents on this workspace will no longer see the Datadog tools, and any saved skills that reference them will surface the integration as missing until you reconnect. *** ## Troubleshooting ### A Datadog tool returns a permissions error The Application key is missing the scope that tool needs. Re-create the key in **Organization Settings → Application Keys** with the full scope set from [Step 3](#step-3-create-an-application-key), then re-save it in Clarion. ### Case tools don't work The case tools need `cases_read` and `cases_write` (and `user_access_read` for assignee lookup). Confirm those scopes are on the Application key, and that the case tools are added to the skill the agent is running. ### "Unknown Datadog site" or no data returned The selected site doesn't match your organization's region. Check the URL you use to reach Datadog and pick the matching site in [Step 1](#step-1-choose-your-datadog-site). US1-FED and US2-FED are not supported. ### Tools don't appear at all Confirm Datadog's MCP server (Bits AI) is available for your organization — see [Datadog's setup docs](https://docs.datadoghq.com/bits_ai/mcp_server/setup/) — and that the integration shows as connected in Clarion. Forwarding Datadog **monitor alerts** into Clarion as issues is coming soon. Today the Datadog integration powers the agent tools described above. # DNS Monitor Source: https://docs.clarion.cantina.xyz/integrations/dns Built-in DNS monitoring — watch your zones for record, subdomain, and email-authentication changes with no external service. The DNS Monitor is built into Clarion. There is no vendor to connect and no credential to store: you name the domains to watch, and Clarion resolves them on a schedule, comparing each result against the last. **Estimated time:** 2 minutes. You need only the domains you want monitored. ## Connect 1. In Clarion, open **Integrations** and find **DNS Monitor**. 2. Click **Connect** — the integration activates immediately. 3. Add a monitor per domain you want watched. ## What it detects Each check compares the current answer against the previous one and raises an issue on a meaningful difference: * **Record changes** — A, AAAA, CNAME, MX, NS, and TXT records that changed unexpectedly * **Email-authentication changes** — SPF, DKIM, and DMARC records, the ones that gate whether someone can spoof your domain * **New subdomains** — names that appeared since the last scan * **Nameserver and registrar changes** — the signature of a domain hijack * **Certificate and TLS posture** on the resolved hosts These feed the [DNS & Domain Security](/learn/agents/our-agents) agent, which carries seven skills covering record change, subdomain change, email-auth change, new subdomain discovery, registrar compromise, DNS tunneling, and DDoS amplification. ## What agents can do The DNS tools are available to every agent, whether or not the monitor is watching a given name: | Tool | What it returns | | ------------------------------------------ | ----------------------------------------------------------- | | `dns_lookup` | Resolve a name across record types | | `dns_dig` | A raw `dig`-style query for a specific record type | | `dns_compare` | Compare a name's answers across resolvers | | `whois_lookup` | Registrar and registration data for a domain | | `spf_check` / `dkim_check` / `dmarc_check` | Email-authentication posture for a domain | | `tls_check` | Certificate chain, expiry, and TLS configuration for a host | ## Acting on findings The DNS Monitor detects; it does not change records. To let an agent *fix* a DNS problem, connect [Cloudflare](/integrations/cloudflare) — that integration carries the record write and zone rollback tools, and the [Dangling Subdomain Agent](/learn/agents/our-agents) uses it for its daily sweep. ## Disconnect Click **Disconnect** on the integration page. Monitors under it stop running. # Envoy Source: https://docs.clarion.cantina.xyz/integrations/envoy Workplace context — office locations, employees, and who is signed in on site — for physical-world corroboration during triage. Envoy is a workplace platform. Connecting it gives agents a read-only view of your office locations, employee directory, and visitor and employee sign-in entries. **Estimated time:** 3 minutes. You will need admin access to your Envoy account. ## Prerequisites * An **Envoy** account with admin access * A Client API key ## Step 1 — Create a Client API Key in Envoy 1. In Envoy, go to **Settings → Integrations → API keys**. 2. Create a **Client API Key**. 3. Copy the key. ## Step 2 — Connect in Clarion 1. In Clarion, open **Integrations** and find **Envoy**. 2. Paste the key and click **Connect**. The key is stored encrypted and never enters the agent sandbox. ## What agents can do | Tool | What it returns | | --------------------------------- | ------------------------------------------- | | `get_company` | Your Envoy company record | | `list_locations` | Office locations | | `list_employees` / `get_employee` | Employee directory lookups | | `list_entries` / `get_entry` | Sign-in entries — who was on site, and when | ## Why a security agent wants this Envoy answers a question the rest of the stack cannot: **was this person physically there?** An impossible-travel alert reads very differently when the badge record puts the employee in the London office at the time of the London login. A suspicious out-of-hours access from a corporate network is more interesting when nobody was in the building. Envoy turns those from assumptions into evidence. ## Disconnect Click **Disconnect** on the integration page. The stored key is deleted. # Falco Source: https://docs.clarion.cantina.xyz/integrations/falco Runtime security on your hosts over SSH — ingest Falco alerts and let agents inspect and kill suspicious sessions. Falco is runtime threat detection for Linux hosts and containers. Clarion connects to a host over SSH to receive Falco's alerts and to act on suspicious sessions. **Estimated time:** 10 minutes. You will need SSH access to the host running Falco and the ability to create a dedicated key. ## Prerequisites * A host running **Falco**, reachable over SSH from Clarion * A dedicated SSH user for Clarion, with only the access it needs * An SSH private key for that user (a passphrase is supported) Give Clarion its own SSH user rather than reusing an operator account. This integration can terminate sessions on the host, so the account's blast radius is the integration's blast radius. ## Connect 1. In Clarion, open **Integrations** and find **Falco**. 2. Enter the **Host** — an IP address or hostname, e.g. `192.168.1.100` or `host.example.com`. 3. Enter the **SSH Username**. 4. Paste the **SSH Private Key**, and its **passphrase** if it has one. 5. Click **Connect**. Credentials are stored encrypted and never enter the agent sandbox. ## What Clarion ingests Falco runtime alerts — unexpected process execution, suspicious file access, container escapes, privilege escalation, and outbound connections that break policy. These feed the [Infrastructure & Ops](/learn/agents/our-agents) agent, alongside Grafana and Better Stack. ## What agents can do | Tool | What it does | | --------------- | -------------------------------- | | `list_sessions` | List active sessions on the host | | `kill_sessions` | Terminate one or more sessions | `kill_sessions` disconnects a live user. It is a containment action and is gated behind approval by default. ## Disconnect Click **Disconnect** on the integration page. The stored SSH credentials are deleted. # Google Cloud Source: https://docs.clarion.cantina.xyz/integrations/gcp Connect Google Cloud monitors and runtime credentials for agent triage. Google Cloud support is split into monitor types. Use **GCP Cloud Logging** for audit log streams, **GCP Cloud Monitoring** for alert policy incidents, and **GCP Security Command Center** for SCC findings. ## Runtime credentials Configure runtime credentials on the Google Cloud integration page before agents use GCP tools. These credentials let Clarion read audit logs, inspect IAM state, fetch SCC findings, and query Cloud Monitoring policy and metric context during triage. The runtime credential project can be different from the projects or SCC scopes you monitor. Clarion supports two runtime auth modes: * **Keyless via Workload Identity Federation**: recommended whenever Clarion's central GCP bridge is configured. Guided setup provisions this by default and stores only non-secret metadata. * **JSON service account key**: fallback for local development or environments where WIF is not available. Clarion stores the private key encrypted. Switching to WIF clears Clarion's stored private key. It does not delete any existing service account keys in Google Cloud; delete remote keys after validating WIF if your organization no longer needs them. ## Monitor options * **GCP Cloud Logging**: one monitor per GCP project. Use this for Admin Activity audit logs, IAM changes, service account key creation, compute launches, logging changes, storage, KMS, secrets, GKE, serverless, SQL, and network/perimeter changes. * **GCP Cloud Monitoring**: one monitor per GCP project. Use this for incidents from selected Cloud Monitoring alert policies. * **GCP Security Command Center**: one monitor per SCC organization, folder, or project scope and location. Use this for active SCC findings, including Event Threat Detection findings. ## Recommended setup 1. Go to **Integrations > Google Cloud**. 2. Click **Connect** and complete Google Cloud setup in the dialog. 3. Open the **Monitors** section. 4. Add a **GCP Cloud Logging**, **GCP Cloud Monitoring**, or **GCP Security Command Center** monitor. 5. Use guided setup when available. It provisions keyless runtime auth on Vercel and grants the monitor-specific IAM roles. If you are developing locally, use JSON service account key mode. See the monitor-specific guides for the exact setup fields: * [GCP Cloud Logging](/integrations/gcp-cloud-logging) * [GCP Cloud Monitoring](/integrations/gcp-cloud-monitoring) * [GCP Security Command Center](/integrations/gcp-security-command-center) # GCP Cloud Logging Source: https://docs.clarion.cantina.xyz/integrations/gcp-cloud-logging Send Google Cloud audit logs to Clarion with one monitor per GCP project. GCP Cloud Logging monitors ingest Google Cloud audit logs through Pub/Sub push delivery. Each monitor is scoped to one GCP project, so webhook delivery, OIDC verification, and signal rules stay bound to that project. ## Setup options Use **guided setup** when possible. Clarion will create or update the Pub/Sub topic, log sink, push subscription, OIDC signer, and IAM grants for the selected project. Use **manual setup** when you need to provision GCP resources yourself. Clarion will show the monitor webhook URL and ask you to save the Pub/Sub subscription resource plus the OIDC service account metadata. ## Runtime credentials Before agent tools can investigate issues from GCP, configure runtime credentials on the GCP integration page. These credentials authenticate Clarion's outbound GCP API calls. The runtime credential project is separate from the monitored project. Add a GCP Cloud Logging monitor for each project you want to ingest, then grant the runtime service account the required roles in that target project. Guided setup uses **Keyless via Workload Identity Federation** by default when Clarion's central GCP bridge is configured. This creates or reuses the `clarion-agent` service account and grants Clarion's central bridge service account permission to impersonate it, storing only non-secret metadata (no private key). Use **JSON service account key** mode only for local development or fallback. ## Guided setup 1. Go to **Integrations > GCP**. 2. Connect runtime credentials if they are not already configured. Guided setup will prefer keyless WIF on Vercel. 3. Add a **GCP Cloud Logging** monitor. 4. Choose **Run guided setup**. 5. Select the GCP project to monitor. 6. Approve the setup steps and save the monitor. Clarion seeds a curated managed Admin Activity signal-rule set for the monitor, including IAM, logging, storage, KMS, Secret Manager, GKE, Cloud Run, Cloud Functions, Cloud SQL, and network/perimeter detections. The catch-all template remains available for explicit testing or heavily pre-filtered sinks, but it is not enabled by default. ## Manual setup 1. Create or open a **GCP Cloud Logging** monitor in Clarion. 2. Copy the monitor webhook URL. 3. In Google Cloud, route Cloud Logging entries to a Pub/Sub topic with a log sink. 4. Grant the log sink writer identity `roles/pubsub.publisher` on the topic. 5. Create a Pub/Sub push subscription that targets the monitor webhook URL. 6. Enable OIDC authentication on the push subscription. 7. Save these values on the monitor: * GCP project ID * Pub/Sub subscription resource * OIDC service account email * OIDC client ID, if configured The OIDC token audience must match the webhook URL shown by Clarion. ## Multiple projects Create one active GCP Cloud Logging monitor per workspace/project pair. Reuse the same runtime credentials, then run guided setup or apply manual IAM grants for each target project. # GCP Cloud Monitoring Source: https://docs.clarion.cantina.xyz/integrations/gcp-cloud-monitoring Send Google Cloud Monitoring incidents to Clarion from selected alert policies. GCP Cloud Monitoring monitors ingest Monitoring incident notifications through Pub/Sub push delivery. Each monitor is scoped to one monitored GCP project. Guided setup attaches Clarion only to the alert policies you select. ## What Clarion ingests Clarion creates one issue per Cloud Monitoring `incident_id` and updates that issue as Google sends lifecycle events. * `open` opens or reopens a Clarion issue. * Re-notifications update issue data without resetting the user's workflow status. * `closed` closes the existing Clarion issue and sets the resolution time from the incident when available. Some Google alert policy types may not send close notifications. In those cases, close the Clarion issue manually after investigation. Clarion currently accepts Google Cloud Monitoring notification schema version `1.2`; test newer Google schema versions before broadening ingestion. When Google publishes a new notification schema version, compare it against Google's schema documentation, add parser tests for open and closed incidents, then update Clarion's accepted versions before enabling production ingestion. ## Severity mapping Cloud Monitoring severity maps to Clarion severity as follows: * `CRITICAL` → Critical * `ERROR` → High * `WARNING` → Low * Missing or unknown severity → the monitor's fallback severity Use allowed severities on the monitor to filter which incidents open or reopen issues. Once an issue is open, later Google updates refresh the stored severity even if that severity is outside the allowlist. Close notifications can still resolve an existing issue. Because Google `WARNING` maps to Clarion Low, keep Low selected if you want those incidents to open issues. Cloud Monitoring re-notifications do not start another Clarion triage run; they refresh the existing issue data to avoid duplicate investigations. ## Guided setup 1. Go to **Integrations > Google Cloud**. 2. Choose **Guided Setup**. 3. Select **Cloud Monitoring monitor**. 4. Select the monitored project. 5. Select at least one alert policy. 6. Run setup. Clarion creates or reuses: * Pub/Sub topic for Monitoring incidents * Pub/Sub push service account * Pub/Sub push subscription with OIDC authentication * Cloud Monitoring Pub/Sub notification channel * Runtime service account identity for read-only triage Guided setup also grants the Cloud Monitoring notification service agent `roles/pubsub.publisher` on the topic and patches the selected alert policies so they include the Clarion notification channel. Multiple Cloud Monitoring monitors in the same delivery project can share the same Pub/Sub topic. Each monitor has its own push subscription, so non-matching monitors may reject fan-out deliveries with `403` while the matching monitor accepts the incident. When Clarion runs on Vercel, guided setup provisions the runtime identity with keyless Workload Identity Federation. JSON service account keys remain available as a fallback for local development or environments where WIF cannot be used. ## Manual setup Use manual setup when your Google Cloud resources are managed outside Clarion. 1. Create or open a **GCP Cloud Monitoring** monitor in Clarion. 2. Copy the monitor webhook URL. 3. In Google Cloud, create a Pub/Sub topic. 4. Create a Pub/Sub push subscription that targets the Clarion webhook URL. 5. Enable OIDC authentication on the push subscription. 6. Create a Cloud Monitoring Pub/Sub notification channel for the topic. 7. Attach that notification channel to the alert policies you want Clarion to receive. 8. Save these values on the monitor: * monitored project ID * optional delivery project ID * Pub/Sub subscription resource name * OIDC service account email * OIDC client ID, if configured * Cloud Monitoring notification channel resource name * fallback severity and allowed severities The OIDC token audience must match the webhook URL shown by Clarion. ## Permissions The Google account used for guided setup needs permission to: * list and patch Cloud Monitoring alert policies in the monitored project * create Monitoring notification channels * create Pub/Sub topics and push subscriptions in the delivery project * create service accounts and, on Vercel, workload identity pools/providers for Clarion runtime credentials * grant Pub/Sub publisher access to the Monitoring notification service agent For agent triage, Clarion's runtime service account needs `roles/monitoring.viewer`, `roles/logging.viewer`, and `roles/iam.securityReviewer` on the monitored project. Guided setup grants these roles. The Cloud Monitoring tools are read-only and scoped to the issue's configured monitor project. # GCP Security Command Center Source: https://docs.clarion.cantina.xyz/integrations/gcp-security-command-center Send active Google Security Command Center findings to Clarion. GCP Security Command Center monitors ingest active SCC findings through Pub/Sub push delivery. Each monitor is scoped to one SCC organization, folder, or project and one SCC location. ## What Clarion ingests Clarion opens an issue for each active, unmuted SCC finding with medium, high, or critical severity. Event Threat Detection findings are included when they arrive through Security Command Center. ## Setup options Use **guided setup** when possible. Clarion creates the Pub/Sub topic, push subscription, OIDC signer, SCC notification config, SCC-to-Pub/Sub publish grant, and read-only role grants for triage. Use **manual setup** when your Google Cloud resources are managed outside Clarion. Manual setup still needs GCP runtime credentials in Clarion if agents should triage SCC findings with GCP tools. Guided setup provisions the shared runtime identity with keyless Workload Identity Federation whenever Clarion's central GCP bridge is configured. JSON service account keys remain available as a fallback for local development or environments where WIF cannot be used. ## Manual setup 1. Create or open a **GCP Security Command Center** monitor in Clarion. 2. Select the SCC scope type: organization, folder, or project. 3. Enter the SCC scope ID and location. 4. Enter the Pub/Sub delivery project ID. 5. Copy the monitor webhook URL. 6. In Google Cloud, create a Pub/Sub topic for SCC findings. 7. Create a Pub/Sub push subscription that targets the Clarion webhook URL. 8. Enable OIDC authentication on the push subscription. 9. Create an SCC notification config that sends active findings to the Pub/Sub topic. 10. Grant the SCC notification config service account `roles/pubsub.publisher` on the Pub/Sub topic. 11. Save these values on the monitor: * Pub/Sub subscription resource * OIDC service account email * OIDC client ID, if configured * SCC notification config resource name The OIDC token audience must match the webhook URL shown by Clarion. ## Permissions The runtime service account needs read-only access to SCC findings for the selected scope. Guided setup grants the SCC findings viewer role. For manual setup, grant equivalent read-only SCC finding access at the organization, folder, or project you monitor. For agent triage on SCC findings, the runtime service account also needs read-only access in the Pub/Sub delivery project for audit log and IAM lookups. Guided setup creates or reuses this runtime identity, prefers keyless WIF on Vercel, and grants `roles/logging.viewer` and `roles/iam.securityReviewer` on that project. For manual setup, first connect GCP runtime credentials in Clarion, then grant those same read-only roles. The Google account used for guided setup needs permission to create Pub/Sub resources in the delivery project and manage SCC notification configs at the selected SCC scope. # Generic Webhook Source: https://docs.clarion.cantina.xyz/integrations/generic-webhook Send events from any service to Clarion via HTTP webhook for AI-powered triage and response. This guide walks you through setting up a Clarion Generic Webhook monitor — a flexible endpoint that accepts JSON events from any service that can make an HTTP POST request. Use it to bring custom alerts, deploy events, CI failures, or any JSON payload into Clarion. **Estimated time:** 5 minutes. You will need a **Clarion workspace** and the ability to configure outbound webhooks in the source service. ## Prerequisites * A **Clarion workspace** * A service that can send HTTP `POST` requests with a JSON body (CI systems, bespoke scripts, SaaS tools with webhook outputs, Slack-style senders, etc.) *** ## Step 1 — Create a Generic Webhook monitor 1. In Clarion, go to **Settings > Integrations** 2. Find **Webhook** and click **Add Monitor** 3. Give the monitor a **name** — it is prefixed onto issue titles, so different monitors are easy to tell apart 4. Pick an **authentication method** (see the next section) 5. Pick a **default severity** for issues opened by the monitor 6. Click **Create** Clarion generates a **webhook URL** and, depending on the auth method, a **signing secret** or **bearer token**. Copy them right away. Copy any generated secret immediately — it is only displayed once. You can rotate it later from the monitor's Configure page, but you cannot view the current value. *** ## Step 2 — Choose an authentication method | Mode | How requests are authenticated | When to use | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | **HMAC-SHA256 signature** | Sender signs the raw request body with the shared secret and sends the hex digest in `X-Webhook-Signature` (also accepts `X-Hub-Signature-256` with the `sha256=` prefix) | Production senders that can compute HMAC | | **Bearer token** | Sender includes `Authorization: Bearer ` | Services with a simple token field in their webhook config | | **No authentication** | Any request is accepted | Trusted internal networks only | "No authentication" accepts any POST. Only use it for traffic that is already restricted by a private network or VPN. The authentication method is fixed at creation. To switch, create a new monitor. ### Signature format Some senders cannot put their signature in our header. With HMAC auth selected, the **Signature format** dropdown adds that sender's header to what the monitor accepts: | Format | Also accepts | | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **X-Webhook-Signature** (default) | nothing extra | | **X-Payload-Digest** | `X-Payload-Digest`, with the algorithm named in `X-Payload-Digest-Alg`. Set the sender to SHA256 or SHA512 — the deprecated SHA1 option is refused | | **Custom header** | the header you name, with the algorithm (SHA256/SHA512) and encoding (hex/base64) you pick | Custom covers senders that sign the raw request body. A sender that signs a timestamp together with the body — Stripe and Slack do — will not verify against any of these; tell us and we will add it as a named format. Unlike the authentication method, this can be changed at any time — it does not affect your secret. *** ## Step 3 — Send events from your service Point the source service at the webhook URL Clarion gave you. Use `POST` with a JSON **object** body, up to 100 KB. ### Minimal example ```bash theme={null} curl -X POST "https:///api/webhooks/generic-webhook/" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer " \ -d '{"type": "deploy.failed", "message": "Production deploy failed", "severity": "high"}' ``` ### What goes in the payload Any valid JSON object is accepted. Clarion looks at the payload's `type`, `event`, `eventType`, or `event_type` field (in that order) to derive an **event type** — used for matching filters and included in the issue title. If none of those fields is present, the event is treated as `generic`. Fields used by the default issue template: | Field | How it's used | | --------------------------------------------- | -------------------------------------------------- | | `type` / `event` / `eventType` / `event_type` | Event type — filter matching and issue title | | `message` | Included as the body of the issue description | | `severity` | Shown under "Reported severity" in the description | | `source` | Shown under "Source" in the description | All other fields are attached to the issue for reference — no field is dropped. ### Optional headers | Header | Purpose | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------- | | `X-Webhook-Signature` or `X-Hub-Signature-256` | HMAC-SHA256 hex digest of the body (required when the monitor uses HMAC auth) | | `X-Payload-Digest` | Only accepted when the monitor's signature format is set to **X-Payload-Digest** | | `Authorization: Bearer ` | Required when the monitor uses Bearer auth | | `X-Idempotency-Key` or `X-Request-Id` | If present, retries of the same value are treated as duplicates and will not create a second issue | *** ## The default "All webhook events" filter When you create the monitor, Clarion adds an **All webhook events** filter that opens an issue for every incoming event with the default severity you chose. From the monitor's Configure page you can: * **Change the default severity** — it applies to the default filter immediately * **Disable** the default filter if you only want issues for specific events * **Add more filters** that match by event type, payload fields, or conditions (e.g. only alert when `severity = critical`) Each issue's title includes the monitor name and the time the event arrived; the description surfaces common payload fields (`message`, `severity`, `source`) alongside the event type. *** ## Using as a Slack replacement Many services offer a "Slack incoming webhook URL" field for sending notifications. Because the Generic Webhook accepts arbitrary JSON, you can drop the Clarion webhook URL into those fields instead — your notifications become Clarion issues that get triaged by AI agents. To set this up: 1. Create a Generic Webhook monitor with **No authentication** (most Slack-style senders don't sign requests) or **Bearer token** if the source service lets you add an `Authorization` header 2. Copy the webhook URL from the monitor 3. In the source service, paste the Clarion webhook URL wherever it asks for a Slack webhook URL 4. Send a test notification — it will appear as an issue in Clarion Slack-compatible senders usually put the notification body in a `text` field, which isn't one of the event-type fields Clarion looks at — so those events are treated as `generic` and the default **All webhook events** filter still catches them. For nicer issue titles, edit the default filter's title template to reference the fields your sender actually uses (for example `{{text}}` for Slack-style payloads). *** ## What happens next Once configured, Clarion will automatically: * Accept JSON events at the monitor's webhook URL * Apply the default **All webhook events** filter (and any custom filters you add) to open issues * Triage incoming issues using AI agents and surface actionable insights # GitHub Source: https://docs.clarion.cantina.xyz/integrations/github Connect GitHub so Clarion ingests repository security events, discovers your repos into the Brain, and lets agents open remediation pull requests. GitHub is the integration behind Clarion's code and supply-chain coverage. Once connected, Clarion ingests repository security events, discovers your repositories into the [Brain](/learn/agents/brain), and gives agents the ability to investigate code and open remediation pull requests. **Estimated time:** 5 minutes. You will need permission to install a GitHub App on your organization. ## Prerequisites * A **GitHub organization** where you can install applications * A **Clarion workspace** with the GitHub integration page open ## Connect 1. In Clarion, open **Integrations** and find **GitHub** under Essentials. 2. Click **Connect** and complete the GitHub App installation. 3. Choose whether to grant access to **all repositories** or a selected subset. 4. Return to Clarion — the integration shows as connected once the installation callback lands. ### Commit identity Under the integration's settings you can set the **name** and **email** Clarion uses when an agent authors a commit. Pick something that reads clearly in your history, e.g. `Clarion Agent `. GitHub Enterprise Server is supported by setting a custom **Endpoint URL** on the integration. ## What Clarion ingests Repository security events feed the **Code & Supply Chain** and **Dependabot Alerts** agents: * Secret-scanning and code-scanning alerts * Dependabot vulnerability alerts * Branch-protection and ruleset changes * Repository visibility changes * Force pushes to default branches * Organization owner additions * Tag and release activity ## Repository discovery into the Brain Clarion discovers your repositories as assets, along with the governance metadata that makes them judgeable: rulesets, workflows, open alert counts, org custom properties, and CODEOWNERS. Repositories correlate with cloud resources and observability services that reference them, so an alert on a service resolves to the repository that builds it. Software bills of materials are captured per repository, which is what lets the Dependabot agent reason about reachability rather than just CVE presence. ## What agents can do * Read repository contents, history, and pull requests during an investigation. * Assess the blast radius of a code finding across the organization. * Open a **remediation pull request**, push commits to it, and iterate until CI is green. * Comment on and label issues and pull requests. Write actions are gated by your workspace's tool policy. An agent asks for approval before pushing or opening a PR unless you have explicitly allowed it. ## Related agents Repository integrity, CI/CD, and org governance. Auto-fix PRs driven to green CI. ## Disconnect Open **Integrations → GitHub** and click **Disconnect**, then uninstall the Clarion app from your GitHub organization. Agents lose the GitHub tools, and skills referencing them surface the integration as missing until you reconnect. # Google Calendar Source: https://docs.clarion.cantina.xyz/integrations/google-calendar Sync the on-call rotation to a Google Calendar so anyone on the team can see who is on call at a glance. This guide shows how to connect Google Calendar to Clarion. Once connected, Clarion automatically writes on-call shifts to a calendar you choose and keeps them updated as the rotation changes. **Estimated time:** 2 minutes. You need access to: * A **Clarion workspace** with permission to manage integrations * A **Google account** with permission to authorize third-party apps for the calendar you want to use ## Prerequisites * A Google account with access to the calendar you want Clarion to write to. Any Google account works — personal Gmail, Google Workspace, or a shared account. * An on-call rotation defined in Clarion under **Settings → Notifications**. If the rotation is empty, the connection is still allowed but no events appear until you add slots. *** ## Step 1 - Connect Google Calendar 1. In Clarion, open **Integrations** and find **Google Calendar**. 2. Click **Connect Google Calendar**. You'll be redirected to Google to authorize Clarion. 3. Review the requested permissions in Google, then click **Continue**. Google redirects you back to Clarion with the connection established. Clarion now needs one more choice: which calendar to write to. *** ## Step 2 - Choose a target calendar On the Google Calendar integration page, pick where Clarion should write the on-call shifts: * **Create a new Clarion On-Call calendar** *(recommended)*: Clarion creates a dedicated calendar in the connected Google account named **Clarion On-Call**. Best for teams who want a clean, isolated view of the rotation. * **Use an existing calendar**: Pick any calendar you have write access to. Best when you already have a shared team calendar. Click **Save target calendar**. Clarion runs an initial sync and writes the next 12 weeks of on-call shifts. Each shift is an all-day event titled with the on-call member's name. The on-call member is added as an **attendee** on their shift, so the event also appears on their personal calendar automatically. Google emails each new attendee once when Clarion first schedules them — subsequent edits (rotation reorders, description tweaks) stay quiet. *** ## What Clarion syncs Every event Clarion writes: * Is an **all-day** event covering the full length of the shift (7 days for weekly rotations, 14 days for biweekly). * Has the on-call member(s) as attendees, so shifts also appear on their personal calendars. * Sets a **24-hour popup reminder** on the shared Clarion calendar. Each attendee's personal copy uses their own Google Calendar default reminders — you can override per-event or globally in Google Calendar settings. * Includes a link back to the Clarion **Settings → Notifications** page for context. When the rotation changes — new member added, slots reordered, cadence changed — Clarion patches the affected events on the next sync (immediately after you save the rotation, plus a daily background pass). *** ## Manually resync On the Google Calendar integration page, click **Sync now** to reconcile the calendar immediately. Useful when: * You just updated the rotation and don't want to wait for the automatic sync. * Someone deleted a Clarion event manually — resync restores it. * The last-sync line shows an error. *** ## Reconnecting after Google revokes access If Google revokes Clarion's access (for example, when the person who connected removes Clarion from their Google account), the integration surfaces a **Reconnect Google Calendar** button on the settings page. Clicking through the OAuth flow again restores the sync — the target calendar setting is remembered, so no manual re-picking is needed. *** ## Disconnect To stop syncing: 1. Open the **Google Calendar** integration in Clarion. 2. Click **Disconnect**. 3. Confirm the dialog. Behavior depends on the target calendar: * If Clarion **created** the calendar for you, that calendar is deleted from Google along with its events. * If you pointed Clarion at an **existing** calendar, only the events Clarion added are removed. Everything else on the calendar is left untouched. # Google Workspace Source: https://docs.clarion.cantina.xyz/integrations/google-workspace Connect Google Workspace Alert Center to Clarion for real-time security alert ingestion and AI-powered triage. This guide walks you through connecting Google Workspace Alert Center to Clarion. Once configured, Clarion receives workspace security alerts (suspicious logins, data exfiltration, device compromises, etc.) in real time and can triage and respond using AI agents. ## Setup Options There are two ways to set up the integration: 1. **Automated Setup** — Navigate to the Integrations section and use the automated setup flow. This requires an existing GCP project and admin permissions. 2. **Manual Setup** — Follow the step-by-step instructions below to configure the integration manually. The manual setup has three parts: 1. **GCP Project & Service Account** (shared prerequisite) 2. **Alert Center > Pub/Sub > Clarion webhook** (inbound alerts) 3. **Admin SDK agent tools** (optional — user lookup, suspend, revoke tokens, etc.) No environment variables or code changes are needed — everything is configured per-workspace via the Clarion UI. **Estimated time:** 20-30 minutes. You will need **GCP Project Admin** access and **Google Workspace Super Admin** access. *** ## Part 1: GCP Project & Service Account ### Step 1: Create a Google Cloud Project (or use existing) 1. Go to [Google Cloud Console](https://console.cloud.google.com) 2. Click the project selector dropdown at the top > **New Project** 3. Enter a project name, select your organization > **Create** 4. Note your **Project ID** (e.g. `clarion-workspace`) ### Step 2: Enable Required APIs In **APIs & Services > Library**, search for and enable each of these: * **Google Workspace Alert Center API** (`alertcenter.googleapis.com`) * **Cloud Pub/Sub API** (`pubsub.googleapis.com`) * **Gmail API** (`gmail.googleapis.com`) — required for email investigation agent tools ### Step 3: Create a Service Account 1. Go to **IAM & Admin > Service Accounts** > **Create Service Account** 2. Name: e.g. `clarion-pubsub-push` 3. Click **Create and Continue** > **Done** (no roles needed) 4. Click the new service account > **Keys** tab > **Add Key** > **Create new key** > **JSON** 5. Save the downloaded JSON file — you'll need it for the Alert Center configuration script (Part 2) and optionally for Clarion Admin SDK credentials (Part 3) 6. Note the service account email (e.g. `clarion-pubsub-push@your-project.iam.gserviceaccount.com`) **Org policy note:** If your organization enforces `iam.disableServiceAccountKeyCreation`, you'll need to temporarily disable it: 1. Go to **IAM & Admin > Organization Policies** 2. Search for `iam.disableServiceAccountKeyCreation` 3. Click it > select **Override parent's policy** > set to **Not enforced** > **Set policy** 4. Create the key 5. **Re-enable the policy** by switching back to **Inherit parent's policy** *** ## Part 2: Inbound Alerts (Alert Center via Pub/Sub) ### Step 1: Create a Pub/Sub Topic 1. Go to **Pub/Sub > Topics > Create Topic** 2. Name it (e.g. `clarion-alerts`, full name: `projects/YOUR_PROJECT/topics/clarion-alerts`) 3. Click **Create** 4. On the topic page, go to the **Permissions** tab > **Grant Access** 5. Add principal: `alerts-api-push-notifications@system.gserviceaccount.com` 6. Role: **Pub/Sub Publisher** 7. Click **Save** This is a Google-managed service account that the Alert Center uses internally to publish alerts into Pub/Sub. Without this permission, alert delivery to the topic will be rejected. ### Step 2: Enable Domain-Wide Delegation The Alert Center API is a Google Workspace API (not a standard GCP API), so configuring it requires domain-wide delegation. This same delegation is reused by Part 3 (Admin SDK tools) if you set that up later. 1. Go to **IAM & Admin > Service Accounts** and click the service account from Part 1 2. Expand **Advanced settings** 3. Under **Domain-wide Delegation**, click **Edit** and enable **Google Workspace Domain-wide Delegation** 4. Note the **Client ID** (numeric, e.g. `107729743480716689292`) ### Step 3: Grant the Alert Center Scope in Google Workspace Admin Console 1. Go to [Google Workspace Admin Console](https://admin.google.com) as a **Super Admin** 2. Navigate to **Security > Access and data control > API controls** 3. Click **Manage Domain Wide Delegation** 4. Click **Add new** 5. Enter: * **Client ID**: the numeric client ID from Step 2 * **OAuth Scopes**: `https://www.googleapis.com/auth/apps.alerts` 6. Click **Authorize** **Both sides are required.** Enabling delegation on the service account (Cloud Console) says "I want to use delegation." Authorizing the client ID with scopes (Admin Console) says "I allow this service account to use these scopes." Both must be configured or delegation calls will fail with `unauthorized_client`. **Propagation delay:** Changes can take up to 24 hours to propagate, though they typically take effect within a few minutes. If you get `unauthorized_client` errors immediately after setup, wait 2-3 minutes and retry. ### Step 4: Configure Alert Center to Publish to Pub/Sub There is no UI for this step — it requires the Alert Center API. Save the following as `alert_setup.py` and run it in Google Cloud Shell or locally: ```python theme={null} import json, urllib.request, urllib.error from google.oauth2 import service_account from google.auth.transport.requests import Request creds = service_account.Credentials.from_service_account_file( '/path/to/your-service-account-key.json', scopes=['https://www.googleapis.com/auth/apps.alerts'], subject='admin@yourdomain.com' # Must be a Super Admin ) creds.refresh(Request()) req = urllib.request.Request( 'https://alertcenter.googleapis.com/v1beta1/settings', method='PATCH', headers={ 'Authorization': 'Bearer ' + creds.token, 'Content-Type': 'application/json' }, data=json.dumps({ "notifications": [{ "cloudPubsubTopic": { "topicName": "projects/YOUR_PROJECT_ID/topics/clarion-alerts", "payloadFormat": "JSON" } }] }).encode() ) try: resp = urllib.request.urlopen(req) print(resp.status, resp.read().decode()) except urllib.error.HTTPError as e: print(f"Error {e.code}: {e.read().decode()}") ``` Replace: * `/path/to/your-service-account-key.json` with the path to your service account JSON key * `admin@yourdomain.com` with your Super Admin email * `YOUR_PROJECT_ID` with your Google Cloud project ID A successful response looks like: ```json theme={null} {"notifications":[{"cloudPubsubTopic":{"topicName":"projects/YOUR_PROJECT/topics/clarion-alerts","payloadFormat":"JSON"}}]} ``` **Why not `gcloud` CLI?** The `gcloud auth print-access-token` command stamps tokens with the `cloud-platform` scope, which covers most Google Cloud APIs. But the Alert Center API is a **Google Workspace API** that requires the `apps.alerts` scope — and gcloud has no flag to request it. The Python script uses the same service account key but explicitly requests the correct scope. ### Step 5: Connect Clarion 1. Open Clarion > Integrations > Google Workspace 2. Select which alert severities to ingest 3. Click **Connect** — this creates the integration 4. Copy the generated **Webhook URL** and **OIDC Audience** — you'll need them for the next step ### Step 6: Create a Pub/Sub Push Subscription 1. Go to **Pub/Sub > Subscriptions > Create Subscription** 2. Configure: * **Subscription ID**: e.g. `clarion-alerts-push` * **Topic**: select the topic from Step 1 * **Delivery type**: **Push** * **Endpoint URL**: paste the webhook URL from Clarion * **Enable authentication**: toggle on * **Service account**: select the service account from Part 1 * **Audience**: enter the OIDC Audience from Clarion. If you did not customize the audience, this is the same as the webhook URL. * **Message retention**: 7 days (default) * **Acknowledgement deadline**: 30 seconds 3. Click **Create** 4. Copy the subscription's full resource name, for example `projects/YOUR_PROJECT_ID/subscriptions/clarion-alerts-push` 5. Return to Clarion and save: * **Pub/Sub OIDC signer service account**: the service account email from Part 1 * **Pub/Sub subscription resource**: the full subscription resource name from this step * **OIDC signer client ID**: optional, but recommended if you have the numeric client ID Clarion rejects Google Workspace Pub/Sub deliveries until the OIDC signer service account and full subscription resource are saved. If Clarion shows **Action required: reconnect Pub/Sub delivery**, enter the existing subscription details from Google Cloud or rerun guided setup to refresh the Pub/Sub delivery configuration. If you get a permission error on the service account, grant your user the `iam.serviceAccounts.actAs` permission on that service account. ### Step 7: Verify * Check **Admin Console > Security > Alert Center** for existing alerts * Verify issues appear in Clarion — Pub/Sub will retry delivery if the webhook returns a non-2xx status * Most security alerts (suspicious login, leaked password, phishing) are on by default. Custom alerts (DLP violations, activity rules) require additional rule configuration in the Admin Console. *** ## Part 3: Admin SDK Agent Tools (Optional) This enables Clarion's AI agents to look up users, suspend accounts, revoke OAuth tokens, investigate emails, and more. It uses the same service account and delegation from Part 2 — you just need to add the Admin SDK and Gmail scopes. ### Step 1: Add Admin SDK and Gmail Scopes 1. Go to [Google Workspace Admin Console](https://admin.google.com) as a **Super Admin** 2. Navigate to **Security > Access and data control > API controls** 3. Click **Manage Domain Wide Delegation** 4. Find the existing entry for your service account's Client ID (added in Part 2, Step 2) 5. Click **Edit** and update the OAuth Scopes to include all six (comma-separated, no spaces): ``` https://www.googleapis.com/auth/apps.alerts,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.user.security,https://www.googleapis.com/auth/admin.reports.audit.readonly,https://www.googleapis.com/auth/gmail.readonly,https://www.googleapis.com/auth/gmail.modify ``` 6. Click **Authorize** **Gmail scopes**: `gmail.readonly` enables the agent to search and read emails during investigation. `gmail.modify` enables trashing malicious emails. Both scopes use domain-wide delegation to impersonate the affected user's mailbox — the service account does not need direct mailbox access. **Propagation delay:** Scope changes can take up to 24 hours to propagate, though they typically take effect within a few minutes. ### Step 2: Upload Credentials in Clarion 1. In the Clarion integration settings, go to the **Agent Tools (Admin SDK)** tab: * Enter the **Super Admin Email** (e.g. `admin@yourdomain.com`) — this is the account the service account will impersonate * Upload the **JSON key file** from Part 1, Step 3 2. Click **Save** ### Step 3: Verify * When an issue is opened and triggers an agent, the agent should be able to use Google Workspace tools (user lookup, suspend, etc.) * You can test by ensuring the service account can impersonate the admin: if credentials are wrong, agent tool calls will fail with auth errors *** ## Troubleshooting ### `Request had insufficient authentication scopes` The token doesn't include the required scope. This happens when using `gcloud auth print-access-token` for Workspace APIs. Use the Python script method (Part 2, Step 4) which explicitly requests the correct scope. ### `unauthorized_client: Client is unauthorized to retrieve access tokens using this method` Domain-wide delegation is not configured correctly. Verify both: 1. **Cloud Console**: Service account has domain-wide delegation enabled (Advanced settings) 2. **Admin Console**: Client ID is authorized with the required scopes (Security > API controls > Domain-wide Delegation) If both are set, wait a few minutes for propagation and retry. ### `Service account key creation is disabled` Your organization enforces `iam.disableServiceAccountKeyCreation`. See the note in Part 1, Step 3 for how to temporarily override this policy. ### `Google Workspace Alert Center API has not been used in project ... before or it is disabled` Enable the Alert Center API in **APIs & Services > Library**. Search for "Google Workspace Alert Center API" and click **Enable**. *** ## Summary Checklist | Task | Where | | ----------------------------------------------------------- | -------------------------------------------------------- | | Create Google Cloud project | Google Cloud Console | | Enable Alert Center + Pub/Sub + Gmail APIs | Google Cloud Console | | Create service account with JSON key | Google Cloud Console | | Create Pub/Sub topic with Alert Center publisher permission | Google Cloud Console | | Enable domain-wide delegation on service account | Google Cloud Console (service account Advanced settings) | | Authorize `apps.alerts` scope in Admin Console | Google Workspace Admin Console | | Configure Alert Center to publish to topic | Python script | | Connect integration in Clarion + create monitor | Clarion UI | | Create push subscription with OIDC auth | Google Cloud Console | | (Optional) Add Admin SDK + Gmail scopes in Admin Console | Google Workspace Admin Console | | (Optional) Upload service account credentials in Clarion | Clarion UI | # Grafana Source: https://docs.clarion.cantina.xyz/integrations/grafana Connect Grafana to Clarion to receive alerting notifications for AI-powered triage and response. This guide walks you through connecting Grafana to Clarion. Grafana's unified alerting system sends webhook notifications to Clarion, where AI agents triage and respond to your infrastructure and application alerts. **Estimated time:** 5-10 minutes. You will need access to your **Grafana instance** (with Alerting permissions) and a **Clarion workspace**. ## Prerequisites * A **Grafana** instance (self-hosted or Grafana Cloud) with unified alerting enabled * Alerting admin or editor permissions in Grafana * A **Clarion workspace** with the Grafana integration available *** ## Step 1 — Create a monitor in Clarion 1. In Clarion, go to **Settings > Integrations** 2. Find **Grafana** and click **Add Monitor** 3. After you select the default severities Clarion generates a **webhook URL** and a **webhook secret** (Bearer token) 4. Copy both values — you'll need them in the next steps Copy the webhook secret immediately — it is only displayed once. If you lose it, you'll need to regenerate the monitor. *** ## Step 2 — Create a contact point in Grafana 1. In your Grafana instance, navigate to **Alerting > Contact points** 2. Click **+ Create contact point** 3. Configure the contact point: * **Name**: Give it a descriptive name (e.g. `Clarion`) * **Integration type**: Select **Webhook** * **URL**: Paste the webhook URL from Clarion * **HTTP Method**: Leave as `POST` * **Authorization Header — Credentials**: Paste the webhook secret from Clarion Setting the **Credentials** field in the Authorization Header section causes Grafana to send the secret as a `Bearer` token in the `Authorization` header, which is how Clarion authenticates incoming requests. 4. Click **Save contact point** *** ## Step 3 — Route alerts to the Clarion contact point You can route alerts to Clarion by updating your **notification policy** or by adding Clarion as a contact point on individual alert rules. ### Option A — Default notification policy 1. Go to **Alerting > Notification policies** 2. Edit the **default policy** (or create a nested policy) 3. Set the **Contact point** to the Clarion contact point you created 4. Save the policy ### Option B — Per-rule contact point 1. Go to **Alerting > Alert rules** 2. Open the alert rule you want to forward to Clarion 3. In the **Notifications** section, override the contact point and select the Clarion contact point 4. Save the rule Repeat for each alert rule you want Clarion to receive. *** ## Severity mapping Clarion maps the `severity` label from your Grafana alerts to its own severity levels: | Grafana `severity` label | Clarion severity | | ------------------------------ | ---------------- | | `critical` | Critical | | `high` | High | | `warning`, `medium` | Medium | | `low`, `info`, `informational` | Low | | *(missing or unrecognized)* | Medium | To control how Clarion prioritizes your alerts, add a `severity` label to your Grafana alert rules (e.g. `severity = critical`). If no severity label is present, alerts default to **Medium**. *** ## What happens next Once configured, Clarion will automatically: * Receive alerts from Grafana in real time via the webhook * Parse alert metadata including labels, annotations, dashboard links, and panel URLs * Triage incoming alerts using AI agents and surface actionable insights # Guardrail Source: https://docs.clarion.cantina.xyz/integrations/guardrail Connect Guardrail to Clarion to receive Guard alerts for AI-powered triage and response. This guide walks you through connecting your Guardrails account to Clarion. The setup involves creating a webhook-based Response Channel in Guardrails and linking it to a Clarion monitor. **Estimated time:** 5-10 minutes. You will need access to your **Guardrails dashboard** and **Clarion workspace**. The Clarion integration wizard generates the webhook URL and signing secret for you. Keep the wizard open alongside your Guardrails dashboard. ## Prerequisites * Access to your **Guardrails** dashboard with permissions to create Response Channels * A **Clarion workspace** with the Guardrails integration wizard open *** ## Part 1: Create the Webhook Response Channel in Guardrails ### Step 1 — Open the Responses menu 1. Log in to your **Guardrails** dashboard 2. Open the **Responses** menu and click **Create new response channel** ### Step 2 — Select Webhook as the channel type 1. Under **Create response channel**, select **Webhook** as the channel type *** ## Part 2: Configure the Webhook in Clarion ### Step 3 — Create a new monitor in Clarion 1. In Clarion, go to **Integrations** 2. Navigate to **Guardrails** and click **Create a new monitor** ### Step 4 — Connect the webhook URL 1. Copy the **Webhook URL** generated by the Clarion integration wizard 2. In Guardrails, paste this URL into the webhook configuration for your new Response Channel 3. Click **Add webhook integration** ### Step 5 — Add the signing secret 1. In Guardrails, copy the **Signing Secret** displayed after adding the webhook 2. In Clarion, paste this value into the **HMAC Key** field Make sure you copy the signing secret exactly — this is used to verify that incoming webhooks are authentic. ### Step 6 — Finish creating the Response Channel 1. Complete the remaining fields and save the Response Channel in Guardrails *** ## Part 3: Assign the Response Channel to Your Guards ### Step 7 — Assign to Guards 1. Once the Response Channel is created, click **Assign to Guards** 2. From the list, select the Guards you want to send alerts to Clarion for *** ## What happens next Once configured, Clarion will automatically: * Receive alerts from Guardrails in real time via the webhook * Analyze and triage incoming Guard events using AI agents * Surface actionable insights and recommended responses # Halo Source: https://docs.clarion.cantina.xyz/integrations/halo Connect Halo (HaloPSA) to Clarion so agents can search, create, update, close, and comment on Halo tickets during issue triage. This guide walks you through connecting your Halo (HaloPSA / HaloITSM) instance to Clarion. Once connected, Clarion agents can call Halo's REST API on your behalf to look up existing tickets, open new ones, update and close them, and add comments as part of an investigation. **Estimated time:** 5 minutes. You will need **Halo administrator** access to register an API application. ## Prerequisites * A **Halo** instance and administrator access to **Configuration → Integrations → Halo API** * The ability to create a **Client Credentials** application in Halo * A **Clarion workspace** with the Halo integration page open *** ## Step 1 — Register a Client Credentials application in Halo 1. Sign in to Halo as an administrator. 2. Go to **Configuration → Integrations → Halo API**. 3. Select **Authorise a new application**. 4. Choose **Client Credentials** as the authentication method. 5. Copy the generated **Client ID** and **Client Secret**. Copy the Client Secret immediately and store it securely — Halo may only show it once. Consider using a dedicated service application rather than one tied to a personal account. 6. On the application's **Permissions** tab, grant the permissions needed to read and create tickets (for example, the ticket read/write scopes, or `all`). 7. If you use a **hosted** Halo solution, note your **Tenant** identifier and your **Authorisation server URL** from the same **Halo API** page — you may need them in the next step. *** ## Step 2 — Enter credentials in Clarion 1. In Clarion, open **Integrations** and find **Halo (HaloPSA)** under Development & Planning. 2. Enter your **Halo URL** — your web-app base address, e.g. `https://acme.halopsa.com`. Clarion derives the REST API (`/api`) and authorisation server (`/auth`) from it. 3. Paste the **Client ID** and **Client Secret** from Halo. 4. **Hosted solutions only:** enter your **Tenant**, and an **Authorisation server URL** if it differs from your Halo URL. 5. Click **Connect**. Clarion verifies the credentials by requesting an access token and making a lightweight ticket query before saving. If the credentials or URL are wrong, you'll see a clear error and nothing is persisted. *** ## What agents can do Once connected, agents on this workspace gain access to the `/halo` action, which exposes these tools: | Tool | What it does | | ---------------- | ----------------------------------------------------------------------------------------------- | | `search_tickets` | Search tickets, optionally filtered by a free-text query, open/closed state, client, or agent | | `get_ticket` | Fetch a single ticket's details by its numeric ID | | `create_ticket` | Open a new Halo ticket with a summary and details | | `update_ticket` | Change an existing ticket's summary, details, status, priority, assigned agent, client, or type | | `close_ticket` | Move an existing ticket to a closed status | | `add_comment` | Add a note/action to an existing ticket (private by default, or visible to the end user) | `create_ticket`, `update_ticket`, `close_ticket`, and `add_comment` write to Halo, so they require human approval before they run — you stay in control of when a ticket is actually changed. `search_tickets` and `get_ticket` are read-only. Approval policies are managed in **Settings → Tools**. `add_comment` is retry-safe: if the ticket's most recent note is already identical, it returns that note instead of posting a duplicate. *** ## Disconnect To remove the integration: 1. In Clarion, open **Integrations → Halo (HaloPSA)**. 2. Click **Disconnect**. This deletes the stored credentials. Agents on this workspace will no longer see the `/halo` action, and any saved skills that reference it will surface the integration as missing until you reconnect. *** ## Troubleshooting ### "Halo rejected the client credentials" The Client ID or Secret is wrong, the application is not set to the **Client Credentials** method, or it lacks ticket permissions. Re-check the application in **Configuration → Integrations → Halo API**. ### "Halo returned 404" The Halo URL is likely wrong. Use your web-app base URL (e.g. `https://acme.halopsa.com`), not the `/api` or `/auth` path. For hosted solutions, confirm your **Tenant** and **Authorisation server URL**. # Hexagate Source: https://docs.clarion.cantina.xyz/integrations/hexagate Connect Hexagate to Clarion to receive on-chain monitor alerts for AI-powered triage and response. This guide walks you through connecting your Hexagate account to Clarion. The setup involves adding a Clarion webhook to your Hexagate monitors so that alerts are forwarded automatically. **Estimated time:** 5-10 minutes. You will need access to your **Hexagate dashboard** and **Clarion workspace**. The Clarion integration wizard generates the webhook URL for you. Keep the wizard open alongside your Hexagate dashboard. ## Prerequisites * Access to your **Hexagate** dashboard with permissions to manage Monitors * A **Clarion workspace** with the Hexagate integration wizard open *** ## Part 1: Get the Webhook URL from Clarion ### Step 1 — Open the Clarion integration wizard 1. In Clarion, go to **Integrations** 2. Navigate to **Hexagate** and start the setup wizard 3. Copy the **Webhook URL** generated by Clarion — you will need this in the next steps *** ## Part 2: Add the Webhook to a Hexagate Monitor ### Step 2 — Open Hexagate and navigate to your Monitors 1. Log in to your **Hexagate** dashboard 2. Navigate to **Monitors** ### Step 3 — Open a monitor you want to connect 1. Select one of your existing monitors 2. Navigate to the **Actions** step within the monitor configuration ### Step 4 — Add the Clarion webhook channel 1. Click **Add a new channel** 2. Select **Webhooks** as the channel type 3. Paste the **Webhook URL** you copied from the Clarion wizard 4. Add it to the monitor **Important:** Make sure you paste the webhook URL exactly as provided by Clarion — any extra spaces or missing characters will prevent alerts from being delivered. *** ## Part 3: Assign the Webhook to Additional Monitors ### Step 5 — Repeat for each monitor 1. For every additional monitor you want to send alerts to Clarion, open the monitor and navigate to **Actions** 2. Select the **Clarion webhook** you created in Step 4 from the available channels 3. Save the monitor You only need to create the webhook channel once. After that, you can select it from the channel list on any monitor. *** ## What happens next Once configured, Clarion will automatically: * Receive alerts from Hexagate in real time via the webhook * Analyze and triage incoming monitor events using AI agents * Surface actionable insights and recommended responses Hexagate **Info**-severity events are mapped to **Low**-severity issues in Clarion. If you do not want these events to open issues, disable **Low** severity for the Hexagate monitor. This also suppresses Hexagate **Low**-severity events, since both map to Clarion **Low**. # Huntress Source: https://docs.clarion.cantina.xyz/integrations/huntress Connect Huntress to Clarion for endpoint detection and response (EDR) data enrichment during issue triage. This guide walks you through connecting your Huntress account to Clarion. Huntress provides endpoint detection and response (EDR) data that Clarion uses to enrich issue triage with real endpoint intelligence. **Estimated time:** 5 minutes. You will need **Huntress Admin** access. ## Prerequisites * Access to your **Huntress Dashboard** as an admin * A **Clarion workspace** with the Huntress integration wizard open *** ## Step 1 — Generate API Credentials in Huntress 1. In the Huntress dashboard, click the **menu button** in the upper-right corner. 2. Select **API Credentials**. 3. In the **User API Credentials** section, click **Add**. 4. Select the appropriate user and copy the generated **API Key** and **API Secret** Copy the API Secret immediately — it will only be shown once. Store it securely. *** ## Step 2 — Enter Credentials in Clarion 1. In Clarion, open the **Huntress integration** from your workspace settings 2. Paste the **API Key** and **API Secret** from Huntress 3. Click **Connect** to activate the integration Clarion checks the credentials against Huntress before saving them, so a mistyped key or secret is reported straight away instead of failing quietly later. *** ## Step 3 — Choose the organization Huntress only issues API credentials at the account level. If you are an MSP, that means a single key can read every client organization in your account — so Clarion asks which one this workspace represents. 1. In the connected **Huntress integration**, find the **Organization** section. 2. Open the picker and **search by the client's name** as it appears in Huntress. The list is not ordered to match your Clarion workspace names, so searching is usually faster than scrolling. 3. Select the organization and click **Save**. Once an organization is set, Clarion restricts everything Huntress-related to that client: incident polling, webhook events, and the Huntress data available to triage agents. If you are a direct Huntress customer rather than an MSP, leave this set to **Entire account (all organizations)** — the default. Changing the organization restarts ingestion for the new scope, picking up its currently open incidents. Issues already created for the previous organization are left untouched. *** ## Step 4 — Set up webhook alerts (optional) Webhooks let Huntress push **Incident Reports** and **Escalations** to Clarion in real time, where they become issues and flow through automated triage. Configuring webhooks in Huntress requires the **account admin** role. 1. In Clarion, open the connected **Huntress integration** and find the **Webhook alerts** section. Copy the **Webhook URL**. 2. In the Huntress dashboard, go to **Integrations → Add an Integration → Webhooks** and click **Add Endpoint**. 3. Paste the Clarion **Webhook URL** as the destination URL. 4. Enable only the **Incident Reports** and **Escalations** categories. 5. Open the endpoint's **⋯** menu and choose **View Signing Secret**. Copy it. 6. Back in Clarion, paste the signing secret into the **Signing secret** field and click **Save**. 7. In Huntress, use the endpoint's **Send Test** option to confirm Clarion receives deliveries. *** ## What happens next Once configured, Clarion will (within the organization you selected): * Query Huntress for endpoint data during triage (e.g. matching IP addresses to known managed endpoints) * Use EDR context to validate or dismiss suspicious sign-in alerts from other integrations (e.g. Okta) * Provide agents with visibility into which devices are protected and their current status * Turn incoming **Incident Report** and **Escalation** webhooks into issues and run automated triage on them (if webhooks are configured) # Hypernative Source: https://docs.clarion.cantina.xyz/integrations/hypernative Connect Hypernative to Clarion for on-chain threat monitoring and AI-powered alert triage. This guide walks you through connecting Hypernative to Clarion. Hypernative monitors on-chain threats and protocol risks — once connected, its alerts flow into Clarion for AI-powered triage and incident response. **Estimated time:** 5-10 minutes. You will need access to your **Hypernative dashboard** and a **Clarion workspace**. ## Prerequisites * Access to your **Hypernative dashboard** with permission to manage Actions and Custom Agents * A **Clarion workspace** with the Hypernative integration available *** ## Step 1 — Generate the webhook URL and header secret in Clarion 1. In Clarion, open the agent that should triage Hypernative alerts 2. Add a **Hypernative** monitor in the agent's **Monitors** section 3. Clarion generates a **webhook URL** and a **Clarion binding header secret** for that monitor 4. Copy both values exactly as shown — you'll need them in the next step The Clarion binding header secret is shown only during setup or after rotating it. Do not put the secret in the webhook URL. *** ## Step 2 — Create a webhook Action in Hypernative 1. In the Hypernative dashboard, go to **Actions** 2. Click **Add action** 3. Select **Webhook** as the action type 4. Configure the action: * **Name**: Give it a descriptive name (e.g. `Clarion Webhook`) * **URL**: Paste the webhook URL from Clarion * **Request header**: Add `X-Clarion-Webhook-Secret` with the Clarion binding header secret from Clarion 5. Click **Save** **Important:** Do not use the "Send test alert" button — Hypernative does not send test alerts for webhook action types. *** ## Step 3 — Attach the Action to your Custom Agents 1. In Hypernative, go to **Custom Agents** 2. For each agent you want to send alerts to Clarion, click to edit it 3. Add the newly created webhook Action to the agent's action list 4. Save the agent Repeat for all agents whose alerts you want Clarion to receive. *** ## Step 4 — Attach the Action to your Watchlists 1. In Hypernative, go to **Watchlists** 2. Open each watchlist and add the Clarion webhook to Actions under the **Configure Alert Policy** 3. Navigate to Actions, and configure the webhook *** ## Step 5 — Verify the integration Since Hypernative doesn't support test webhooks, use **Alert Replay** to verify: 1. Go to **Risk Insights > Alerts** in Hypernative (alternatively you can replay alerts from a Watchlist > Alerts as well) 2. Remove the default date filter to see recent historical alerts 3. Open any recent alert, make sure it was triggered from Watchlists 4. Click **Alert Replay** to re-trigger the alert **Important:** Alert replay is only available for **Watchlists** and not for **Custom agents**. **Caution:** Alert Replay triggers the alert across **all** configured action destinations and notification channels — not just Clarion. Make sure you're okay with that before replaying. 5. Check the Clarion **Issues** page — the replayed event should show up within a few seconds # incident.io Source: https://docs.clarion.cantina.xyz/integrations/incident-io Connect incident.io to Clarion so agents can create alerts in incident.io and use its incident-management tools during triage. This guide walks you through connecting incident.io to Clarion. Once connected, agents can create alerts in incident.io — handing them off to your on-call and escalation policies — and, optionally, use incident.io's incident-management tools (incidents, alerts, on-call schedules, escalations) to investigate during triage. **Estimated time:** 5 minutes. You'll need permission to create an **HTTP alert source** in incident.io, and (optionally) an **API key** for the incident-management tools. ## Prerequisites * An **incident.io** account with permission to manage alert sources * A **Clarion workspace** with the incident.io integration page open *** ## Step 1 — Create an HTTP alert source in incident.io For each destination Clarion should be able to raise alerts on: 1. In incident.io, go to **Alerts → Alert sources**. 2. Create a new **HTTP** alert source and give it a recognisable name, for example *Clarion — Production*. 3. Copy the **alert source config ID** shown in the source's URL and the **bearer token** incident.io generates for it. Each alert source maps to one incident.io routing configuration. Create one per scenario if you want different alerts to follow different paths. *** ## Step 2 — Add the alert source in Clarion 1. In Clarion, open **Integrations** and find **incident.io**. 2. Under **Alert sources**, click **Add alert source**. 3. Enter a **name**, the **alert source config ID**, and the **bearer token** from Step 1. 4. Click **Connect incident.io** (or **Add alert source** if already connected). Use the **Test** button next to a source to send a test alert and immediately resolve it, confirming the config ID and token are valid. *** ## Step 3 (optional) — Enable the incident-management tools To let agents look up and manage incidents, alerts, on-call schedules, and escalations during triage: 1. In incident.io, create an **API key** under **Settings → API keys**. 2. In Clarion's incident.io integration page, paste the key under **MCP access** and click **Save**. Write actions (creating or updating incidents, responding to escalations, starting analyses) always pause for human approval before they run. *** ## Using incident.io in a skill Add the **incident.io** tools to a skill or workspace prompt so the agent can create an alert — or take other incident-management actions — when it decides, based on what it found during triage, that a situation warrants it. The incident.io alert links back to the originating Clarion issue. # Iru Source: https://docs.clarion.cantina.xyz/integrations/iru Connect Iru to Clarion so agents can look up devices, users, applications, and vulnerabilities from your Iru tenant during issue triage. This guide walks you through connecting your Iru tenant to Clarion. Once connected, Clarion agents can call Iru's REST API on your behalf to enrich investigations with device, user, application, and vulnerability data, and Clarion discovers your device fleet into the Brain as device assets. **Estimated time:** 5 minutes. You will need **Iru Admin** access to your tenant and the ability to create API tokens. ## Prerequisites * An **Iru** tenant (US or EU) with admin access to **Settings → Access** * Your tenant API host — for example `acme.api.kandji.io` (US) or `acme.api.eu.kandji.io` (EU) * A **Clarion workspace** with the Iru integration page open *** ## Step 1 — Create an API token in Iru 1. Sign in to your **Iru** tenant as an admin. 2. Go to **Settings → Access**. 3. Click **Add API Token**. 4. Copy the generated **API token**. Copy the API token immediately — Iru only shows it once. Store it securely. Avoid tying the token to an admin account that may be removed; consider a dedicated service admin. 5. **Configure permissions.** 6. Grant the token the following **read** permissions: * **Devices** (required) — list devices, fetch device details, activity, status, and installed apps * **Users** (required) — look up users by email or ID * **Prism** (required) — inventory queries for device information, launch agents/daemons, local users, and applications **Devices (read)** is also what powers device discovery into the Brain — keep it granted so Clarion can sync your device fleet. 7. Grant the token the following **write** permissions under **Device Actions**: * **Daily Check-In** — trigger an immediate MDM check-in to refresh device state * **Lock Device** — remotely lock a managed device * **Update Location** — request the device's current location *** ## Step 2 — Enter credentials in Clarion 1. In Clarion, open **Integrations** and find **Iru** under device management. 2. Enter your tenant **API URL**: * US tenants: `acme.api.kandji.io` * EU tenants: `acme.api.eu.kandji.io` You can paste the bare hostname or a full `https://` URL — Clarion parses out the subdomain and region automatically. 3. Paste the **API token** from Iru. 4. Click **Connect**. Clarion verifies the token by calling Iru's `/users` endpoint before saving. If the token is invalid or the URL is wrong, you'll see a clear error and nothing is persisted. *** ## What agents can do Once connected, agents on this workspace gain access to the `/iru` action, which exposes a curated set of read-only Iru tools: | Tool | What it returns | | -------------------------------------------- | -------------------------------------------------------------------------------------- | | `list_devices` | Device summaries, optionally filtered by platform (`mac`, `iphone`, `ipad`, `appletv`) | | `get_device_details` | Full device record — general info, hardware, network, MDM state | | `find_devices_for_user` | Devices assigned to a given email address | | `get_user` / `get_user_by_id` / `list_users` | Iru user lookups | | `list_vulnerabilities` | CVEs detected on a specific device | | `get_device_status` | Blueprint and library-item status for a device | | `get_device_activity` | Recent activity/event stream for a device | | `list_device_apps` | Applications installed on a single device | | `list_audit_events` | Workspace-wide audit log events (cursor-paginated, newest first) | | `prism_device_information` | Iru Prism — device information records | | `prism_launch_agents_and_daemons` | Iru Prism — LaunchAgents/Daemons (macOS) | | `prism_local_users` | Iru Prism — local OS user accounts (macOS) | | `prism_applications` | Iru Prism — installed application inventory across devices | *** ## Device discovery into the Brain Beyond on-demand agent lookups, Clarion discovers your device fleet into the Brain as **device** assets (name, model, platform, OS version, serial number, last check-in). When a device's assigned user matches a synced identity (Okta / Google Workspace), the device is linked to its owner — so an issue involving that user surfaces their devices as related assets. Devices refresh on each asset sync (the manual **Sync** action or the scheduled auto-update). No extra configuration is needed beyond the **Devices** read permission granted above. *** ## Disconnect To remove the integration: 1. In Clarion, open **Integrations → Iru**. 2. Click **Disconnect**. This deletes the stored credentials. Agents on this workspace will no longer see the `/iru` action, and any saved skills that reference it will surface the integration as missing until you reconnect. *** ## Troubleshooting ### "Iru returned 404 for tenant" The tenant subdomain or region is wrong. Double-check the API host in **Iru → Settings → Access**: * US tenants use `*.api.kandji.io`. * EU tenants use `*.api.eu.kandji.io`. The subdomain (e.g. `acme`) must match the prefix shown in your Iru admin URL. # Jira Source: https://docs.clarion.cantina.xyz/integrations/jira Connect Jira Cloud to Clarion with an Atlassian service account so agents can create, look up, and search issues during triage. This guide shows how to connect Jira Cloud to Clarion using an Atlassian service account and OAuth 2.0 client credentials. **Estimated time:** 10-15 minutes. You need access to: * A **Clarion workspace** * **Atlassian Administration** for your Jira site * A service account that can view, search, and create issues in the Jira projects you want Clarion to use ## Prerequisites Before connecting Jira in Clarion, make sure you have: * Your Jira site URL, for example `https://example.atlassian.net` * A Jira service account with access to the relevant projects * An OAuth 2.0 credential created for that service account * These credential scopes: * `read:jira-work` * `write:jira-work` Clarion uses the service account’s client credentials to request short-lived Jira access tokens automatically. You do not need to reconnect the integration just because an access token expires. *** ## Step 1 - Create a Jira service account 1. In **Atlassian Administration**, open **Directory** and create a **service account**. 2. Grant the service account access to **Jira**. 3. Make sure the service account has the Jira project permissions it needs in the projects Clarion will use. The service account should be able to: * Search issues * View issue details * Create issues in the target project *** ## Step 2 - Create OAuth 2.0 credentials for the service account 1. Open the service account in **Atlassian Administration**. 2. Go to **Credentials**. 3. Create an **OAuth 2.0** credential. 4. Grant only these scopes: * `read:jira-work` * `write:jira-work` 5. Copy the **Client ID** and **Client secret**. Keep the client secret somewhere safe. You will paste it into Clarion during setup. *** ## Step 3 - Connect Jira in Clarion 1. In Clarion, go to **Integrations**. 2. Open **Jira**. 3. Enter: * **Site URL** * **Client ID** * **Client Secret** * **Default Project Key** (optional, but recommended) 4. Click **Connect Jira**. *** ## Step 4 - Verify and maintain the connection After connecting: 1. Review the saved Jira site and client ID. 2. Set or update **Default Project Key** if you want Clarion to fall back to a project automatically. 3. Click **Save** after any changes. 4. Click **Verify Connection** to confirm Clarion can access Jira successfully. 5. Use **Disconnect** if you want to remove Jira access from the workspace. Agents can still pass `projectKey` explicitly per tool call. If omitted, Clarion falls back to the configured default project key. *** ## How Jira tools use this integration When Jira tools are enabled, Clarion can: * Create issues * Fetch issue details * Search issues with JQL Clarion manages Jira access tokens automatically from the stored client credentials. *** ## Troubleshooting ### "Failed to resolve Jira cloud ID" Check that **Site URL** is exactly your Jira Cloud URL, for example: * `https://example.atlassian.net` Do not include a path such as `/jira`, `/projects`, or `/browse`. ### "Jira credential is missing required scopes" Recreate or update the OAuth 2.0 credential so it includes: * `read:jira-work` * `write:jira-work` ### Verify Connection fails even though the credential is valid Make sure the service account itself has Jira product access and project-level permissions in the projects Clarion needs to read or create issues in. ### "Project key is required" when creating issues Set **Default Project Key** in the Jira integration, or pass `projectKey` directly in the Jira tool call. # JumpCloud Source: https://docs.clarion.cantina.xyz/integrations/jumpcloud Connect JumpCloud to Clarion to ingest directory and identity events via Insights Rule webhooks and enable agent-driven investigation and response using a JumpCloud service account. This guide explains how to connect JumpCloud to Clarion. Once configured, Clarion receives directory and identity events from JumpCloud Insights Rules through a webhook notification channel and can use a JumpCloud service account to investigate and respond to issues. **Estimated time:** 10-15 minutes. You will need **JumpCloud Admin** access and access to the Clarion workspace where you want to connect JumpCloud. ## Prerequisites * Access to a JumpCloud organization with permission to manage Notification Channels, Insights Rules, and Service Accounts * Access to the Clarion workspace where you want to configure the JumpCloud integration ## Create a webhook notification channel in JumpCloud 1. Sign in to the **JumpCloud Admin Portal**. 2. Open **Settings** and navigate to the **Notification Channels** tab. 3. Select **Webhook** and click to add a new channel. ## Get the webhook URL and secret from Clarion 1. Open Clarion and go to **Integrations** > **JumpCloud**. 2. Click **Connect** to generate a webhook URL and secret for this workspace. 3. Copy the **Webhook URL** and **Secret**. You will paste these into JumpCloud in the next step. ## Configure the webhook channel in JumpCloud 1. Return to the JumpCloud Notification Channel you started creating. 2. Enter a name for the channel, for example `Clarion`. 3. Paste the **Webhook URL** from Clarion into the URL field. 4. Set the authentication type to **Token** and paste the **Secret** from Clarion as the **Auth Token**. 5. You can use **Test Webhook** to send a sample payload to Clarion. An example payload looks like: ```json theme={null} { "type": "user_lockout", "tags": [ { "key": "user_id_123", "value": "user_123" }, { "key": "event_type", "value": "lockout" } ], "channels": { "channel_object_ids": ["channel_456"] }, "organization_object_id": "org_789" } ``` 6. When the test succeeds, save the webhook channel. ## Link the channel to Insights Rules For each Insights Rule you want to forward to Clarion: 1. Open the rule in JumpCloud. 2. Under **Actions**, add the **Clarion** webhook channel as a notification channel. 3. Click **Save**. Clarion now receives events from the rules you linked to the Clarion webhook channel. ## Create a JumpCloud service account for agent tools Connecting a JumpCloud service account lets Clarion agents call the JumpCloud API to investigate issues and, optionally, remediate them. 1. In the JumpCloud Admin Portal, open **Settings** and select the **Service Accounts** tab. 2. Click **Create a new service account**. 3. Name the service account `Clarion` and select a role that matches the access you want Clarion to have. To allow Clarion to remediate issues, select the **Manager** role. 4. Set the **Secret Lifetime** to **365 days**. 5. Copy the **Client ID** and **Client Secret** shown. The secret is only displayed once. ## Connect the service account in Clarion 1. In Clarion, open again the **Integrations** > **JumpCloud** integration page. 2. Paste the **Client ID** and **Client Secret** from JumpCloud. 3. Click **Save Service Account**. Clarion can now use the JumpCloud API to support investigation and response actions on incoming issues. ## Troubleshooting ### Test webhook returns an authentication error * Confirm the authentication type is set to **Token** in the JumpCloud webhook channel * Confirm the **Auth Token** matches the secret shown in Clarion exactly, with no leading or trailing whitespace * If the secret has been rotated, reconnect the integration in Clarion to generate a new secret and update the JumpCloud channel ### Issues are not arriving in Clarion * Confirm the Clarion webhook channel is attached to each Insights Rule you want to forward * Confirm the rule is enabled and has recently matched events in JumpCloud * Re-run **Test Webhook** from JumpCloud to verify the channel still reaches Clarion ### Service account credentials are rejected * Confirm the service account is active in the JumpCloud Admin Portal * Confirm the role assigned to the service account includes the permissions required for the actions you want Clarion to perform * If the client secret is lost or expired, generate a new secret in JumpCloud and save the new **Client ID** and **Client Secret** in Clarion # Linear Source: https://docs.clarion.cantina.xyz/integrations/linear Connect Linear to Clarion so agents can create issues authored by the Clarion app, not by a person on your team. This guide shows how to connect Linear to Clarion. Once connected, Clarion agents can create issues during triage. Issues are authored by **Clarion** in Linear, so they appear separate from any human team member's account. **Estimated time:** 2 minutes. You need access to: * A **Clarion workspace** with permission to manage integrations * A **Linear workspace** with permission to authorize OAuth applications ## Prerequisites * A Linear account with permission to install OAuth applications in your Linear workspace * At least one Linear team where Clarion should create issues *** ## Step 1 - Connect Linear 1. In Clarion, open **Integrations** and find **Linear**. 2. Click **Connect Linear**. You'll be redirected to Linear to authorize Clarion. 3. Review the requested permissions in Linear, then click **Authorize**. Linear redirects you back to Clarion with the integration connected. Issues Clarion creates will be authored by the Clarion app in Linear, not by you personally. Linear shows the Clarion app icon next to each issue Clarion creates. *** ## Step 2 - Choose a default team (optional) After connecting, you can pick a **default team** in the Linear integration page. When an agent creates an issue without specifying a team, Clarion uses the default. Without a default, agents must always pass an explicit team. *** ## What Clarion can do After connecting Linear, agents can: * **Create issues** with a title, description, and optional priority * **Choose the Linear team** for each issue, or use the default Clarion does not currently read or update existing issues — issue creation is one-way from Clarion to Linear. *** ## Disconnect Linear To disconnect: 1. Open the **Linear** integration in Clarion. 2. Click **Disconnect**. 3. Confirm the dialog. Clarion revokes its Linear access token immediately. Issues Clarion previously created remain in Linear unchanged. # Microsoft Defender XDR Source: https://docs.clarion.cantina.xyz/integrations/microsoft-defender-xdr Poll Defender XDR security incidents from Microsoft Graph and triage them with identity-aware playbooks. Clarion polls **Microsoft Defender XDR** incidents through the Microsoft Graph security API using app-only authentication, hydrates each incident with its constituent alerts, and routes it to the right scenario playbook. **Estimated time:** 10 minutes. You will need a **Global Administrator** or **Privileged Role Administrator** in the Microsoft tenant to grant app-only consent. ## Prerequisites * A Microsoft tenant with **Defender XDR** licensed and generating incidents * Ability to grant admin consent for application permissions in Microsoft Entra ID ## Connect 1. In Clarion, open **Integrations** and find **Microsoft Defender XDR**. 2. Click **Connect** and complete the Microsoft admin-consent flow. 3. Grant the requested **application** permissions for reading security incidents and alerts. 4. Return to Clarion; the integration appears as connected and polling begins. Only workspace admins can change the connection. Members can view the integration's state. ## What Clarion ingests Correlated Defender XDR incidents, hydrated with their alerts so the agent sees the whole incident rather than a headline. Clarion reports **severity drift** between the incident and its alerts, and names which Microsoft products contributed. ## What agents can do | Tool | What it returns | | ---------------- | ------------------------------------- | | `list_incidents` | Defender XDR incidents, filterable | | `get_incident` | One incident hydrated with its alerts | ## Better together with Entra Connect [Microsoft Entra](/integrations/microsoft-entra) as well. With it, the Defender XDR agent can pivot a principal named in an incident through your directory — group membership, role assignments, sign-in risk — and carry out approved identity remediation. Without it, the agent reports and escalates rather than acting. ## Related agents The [Microsoft Defender XDR](/learn/agents/our-agents) agent ships five skills: incident triage plus identity scenario playbooks for impossible travel, MFA and session hijacking, OAuth and app abuse, and admin compromise. If you also run **Microsoft Sentinel**, use the combined [Microsoft Sentinel & Defender XDR](/learn/agents/our-agents) agent instead — it adds KQL hunting, phishing, endpoint forensics, ransomware scoping, Azure control-plane investigation, and UEBA anomaly analysis. ## Disconnect Click **Disconnect** on the integration page. This removes the workspace's Clarion binding and any Defender XDR monitors under it. It does **not** revoke the Clarion application in your Microsoft tenant — do that from Entra ID if you want the consent removed. # Microsoft Entra ID Source: https://docs.clarion.cantina.xyz/integrations/microsoft-entra Connect Microsoft Entra ID (Azure AD) to Clarion to enforce enterprise single sign-on for your organization. This guide explains how to register an app in Microsoft Entra ID (formerly Azure AD) and connect it to Clarion. Once configured, users who sign in with a mapped email domain are required to authenticate through Microsoft Entra. **Estimated time:** 10-15 minutes. You will need **Microsoft Entra admin** access and access to the Clarion workspace where you want to configure SSO. ## Prerequisites * Access to the [Microsoft Entra admin center](https://entra.microsoft.com) with permission to register applications * Access to the Clarion workspace settings as a company manager ## Register an app in Microsoft Entra ID 1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com). 2. Go to **Identity** > **Applications** > **App registrations**. 3. Click **New registration**. 4. Enter a name (for example, `Clarion SSO`) and click **Register**. 5. On the app overview page, copy the **Application (client) ID** — you will need this in Clarion. 6. Note your **Directory (tenant) domain** shown under **Overview** (for example, `contoso.onmicrosoft.com`). ## Create a client secret 1. In your registered app, go to **Certificates & secrets**. 2. Click **New client secret**, enter a description and expiry, then click **Add**. 3. Copy the **Value** immediately — it is shown only once. ## Add the SSO connection in Clarion 1. Open Clarion and go to **Settings** > **Single Sign-On (SSO)**. 2. Click **Add Connection**. 3. Enter the following values: * **Tenant Domain** — your Microsoft Entra tenant domain, for example `contoso.onmicrosoft.com` * **Client ID** — the Application (client) ID from your app registration * **Client Secret** — the secret value you copied * **Email Domain** — the email domain whose users will be required to sign in via Entra, for example `contoso.com` 4. Click **Create Connection**. ## Verify the connection After saving: * The connection appears in the **Microsoft Entra / Azure AD** section of the SSO settings page showing the tenant domain, client ID, and mapped email domain. * Users who sign up or sign in with the mapped email domain will be redirected to Microsoft Entra for authentication. ## Remove a connection To remove an SSO connection, click the trash icon next to the connection on the SSO settings page and confirm the deletion. Users on the mapped domains will no longer be required to sign in via Microsoft Entra. ## Troubleshooting ### `401 Unauthorized` when saving * Confirm you are signed in to Clarion with an account that has manager access to the workspace. ### The tenant domain is rejected * Enter only the domain portion, for example `contoso.onmicrosoft.com`. Do not include `https://`. ### Users are not redirected to Entra after setup * Confirm the **Email Domain** matches the domain part of the users' email addresses exactly (for example `contoso.com`, not `contoso.onmicrosoft.com`). * Allow a few minutes for the connection to propagate after creation. # Microsoft Sentinel Source: https://docs.clarion.cantina.xyz/integrations/microsoft-sentinel Connect Microsoft Sentinel to Clarion to poll incidents as issues and give triage agents Sentinel and Defender investigation tools. This guide explains how to connect Microsoft Sentinel to Clarion. Once connected, Clarion polls a Sentinel workspace for new incidents and alerts, ingests them as Clarion issues, and your triage agents gain Microsoft Sentinel and Defender tools to investigate and hunt during triage. **Estimated time:** 5–10 minutes. You will need **Microsoft Entra admin** access to grant tenant-wide consent, plus access to the Clarion workspace where you want to connect Sentinel. ## What this integration provides Connecting Sentinel unlocks two things, both covered by a single connection: | Capability | What it does | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Sentinel Incidents monitor** | Polls Microsoft Sentinel incidents from a specific data-lake workspace and ingests them as Clarion issues. | | **Agent tools** | **MS Sentinel Triage** — list and fetch Sentinel/Defender incidents and alerts, hunt across Defender tables, look up files / IPs / users / machines, and read user-related sign-in sessions during triage. **MS Sentinel Data Lake** — run KQL queries against the Sentinel data lake (sign-ins, audit logs, partner sources) and search the table catalog for cross-source hunting. | ## How the connection works Unlike the [Microsoft Entra ID SSO](/integrations/microsoft-entra) integration, you do **not** register your own app. Clarion ships a single multi-tenant Entra application — **Clarion Sentinel** — and a tenant admin grants it consent inside your tenant. * **One consent per workspace.** A single tenant-wide admin-consent screen covers incident polling, KQL queries, and the Sentinel triage tools. You don't manage client IDs or secrets. * **Monitors are configured separately.** The connection only stores the OAuth credential. You pick which workspace(s) to poll, and with what filters, when you add a monitor. * **One workspace per monitor.** Add a second monitor to ingest from another workspace under the same Entra tenant. ## Prerequisites * A **Microsoft Entra admin** account that can grant tenant-wide admin consent * A Microsoft Sentinel workspace with incidents you want to ingest * Access to the Clarion workspace where you want to connect Sentinel * *(Recommended)* Your tenant onboarded to the **Microsoft Sentinel data lake** — required for the **Data lake** workspace picker and the Data Lake KQL tools. Incident polling works without it (see [Troubleshooting](#troubleshooting)). ## Step 1 — Connect Sentinel in Clarion 1. Open Clarion and go to **Integrations** → **Microsoft Sentinel**. 2. Click **Connect with Microsoft**. You'll be redirected to Microsoft to sign in. Microsoft Sentinel integration page with the Connect with Microsoft button ## Step 2 — Grant tenant-wide admin consent Sign in with a **Microsoft Entra admin** account. Microsoft shows a **Permissions requested** screen for the **Clarion Sentinel** app. It requests: | Permission | Why | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | **Maintain access to data you have given it access to** | Lets Clarion refresh its access offline so polling continues without re-prompting (`offline_access`). | | **Sign in and read user profile** | Identifies the consenting tenant and account (`openid`). | | **Read securitycenter information by MCP** | Grants the Sentinel/Defender **triage** tools — incidents, alerts, and advanced hunting. | | **Sentinel Platform Delegated API Access** | Grants the **data lake** tools — KQL queries and workspace listing. | Review and click **Accept**. Microsoft admin-consent screen for the Clarion Sentinel app Microsoft labels the app as **unverified** / "not published by Microsoft." That's expected for a tenant-consented line-of-business app — consent is granted inside *your* tenant and applies only there. After you accept, Microsoft redirects you back to Clarion and the integration shows **Connected**, along with your tenant. You can **Disconnect** here at any time. ## Step 3 — Add a Sentinel Incidents monitor On the connected integration page, click **Add monitor**. Connected Sentinel integration with the Add monitor button Fill in the monitor form: Create Microsoft Sentinel Monitor dialog * **Name** — a label for this monitor, e.g. `Microsoft Sentinel` or a per-region name like `Sentinel EU`. * **Sentinel workspace** *(required)* — two tabs cover the two ways to provide it: * **SIEM workspace** *(default)* — paste the workspace identifier. It's shown as **Workspace ID** on the **Log Analytics workspace overview** in the Azure portal. * **Data lake** — pick the workspace from a dropdown listing the workspaces the connected tenant can see. Requires your tenant to be onboarded to the **Microsoft Sentinel data lake**. To find your Workspace ID, see [Finding your workspace ID](#finding-your-workspace-id) below. * **Severity filter** *(optional)* — all severities are checked by default. Uncheck **Critical / High / Medium / Low** to skip incidents of those severities. The filter is applied after Sentinel returns incidents. Unchecking *everything* disables the filter — incidents of every severity are ingested. * **Search** *(optional)* — a substring matched against each incident's title and description. For example, type `phishing` to ingest only incidents whose title or description contains "phishing." Leave empty to ingest every incident that matches the severity filter. Click **Save** (or **Continue** when attaching the monitor to an agent). Clarion begins polling that workspace for new incidents. ### Finding your workspace ID On the **SIEM workspace** tab you enter the workspace identifier by hand. In the Azure portal, open **Microsoft Sentinel**, confirm the **selected workspace**, then read the **Workspace ID** from that workspace's **Log Analytics workspace** overview. Identifying the Sentinel workspace in the Azure portal ## How incident polling works * Clarion polls each connected monitor about **once a minute** and opens a Clarion issue for every new Sentinel incident that passes your severity and search filters. * Polling is **forward-only** — a monitor ingests incidents created *after* it's connected, tracked by each incident's creation time. * Incidents are **deduplicated by their Sentinel incident ID**, so retries and overlapping polls never create duplicate issues. * Each issue carries the Sentinel incident title, description, severity, and a deep link back to the Defender/Sentinel portal, plus the full incident payload for agents to read without an extra round-trip. ### Severity mapping Clarion maps Sentinel's severity onto its own issue severities: | Sentinel severity | Clarion severity | | ----------------- | ---------------- | | `critical` | critical | | `high` | high | | `medium` | medium | | `low` | low | | `informational` | low | | `unknown` | medium | ## Agent tools Once connected, attach Sentinel tools to a skill in the skill editor so your triage agents can investigate alerts directly: * **MS Sentinel Triage Tools** — list and fetch Sentinel and Defender incidents and alerts, run advanced hunting across Defender tables, and look up files, IPs, users, machines, and user-related sign-in sessions. * **MS Sentinel Data Lake Tools** — run KQL queries against the Sentinel data lake (sign-ins, audit logs, partner sources) and search the table catalog for cross-source hunting. Clarion ships a built-in **Sentinel security** agent with skills for incident triage and advanced-hunting pivots that already use these tools. **Incident ID formats differ.** The triage tools' *Get Incident By Id* expects a **Sentinel** incident identifier (a GUID or numeric Sentinel ID), which is **not** the Defender incident number shown in the Defender portal. If a lookup by number fails, use *ListIncidents* to find the incident and its correct identifier first. ## Monitoring multiple workspaces Each monitor polls exactly **one** workspace. To ingest from several workspaces in the same tenant, click **Add monitor** again and pick a different workspace — each monitor keeps its own filters and sync health. You only consent once per Clarion workspace, no matter how many Sentinel workspaces you poll. ## Disconnect Click **Disconnect** on the integration page to remove the Sentinel connection. This also removes all Sentinel monitors for the workspace so polling stops cleanly. Other integrations are unaffected. ## Troubleshooting ### Re-connect required If the integration shows **Re-connect required**, the stored credentials are no longer usable — typically because a tenant admin reset consents or the refresh token expired. Click **Connect with Microsoft** and sign in again to resume incident polling and agent queries. You don't need to disconnect first. ### Couldn't list workspaces > The tenant may not be onboarded to the Microsoft Sentinel data lake, or the integration may need to be reconnected. The **Data lake** workspace picker and the Data Lake KQL tools require your tenant to be onboarded to the **Microsoft Sentinel data lake**; **incident ingestion does not.** If listing fails, switch to the **SIEM workspace** tab and enter the **Workspace ID** — the monitor will still poll incidents normally. If you expect the data lake to be available, reconnect the integration. ### Required Microsoft service not enabled (AADSTS650052) This means your tenant has no service principal for one of the Microsoft resources the connection requires — Microsoft only provisions these for some clients while the feature is in preview. Consent can't be recorded against a resource that doesn't exist in your tenant, so the connect flow stops with `AADSTS650052`. Two resources are required, and **either** can be the missing one: | Resource | Backs | Resource app ID | | ------------------------------ | ------------------------------------- | -------------------------------------- | | **Sentinel Platform Services** | Data lake tools and workspace listing | `4500ebfb-89b6-4b14-a480-7f749797bfcd` | | **Microsoft Defender MCP** | Sentinel/Defender triage tools | `7b7b3966-1961-47b5-b080-43ca5482e21c` | Clarion's error message names the specific service that's missing and includes the exact command to run. A tenant administrator creates the missing service principal by running the matching command in **Azure Cloud Shell** ([shell.azure.com](https://shell.azure.com)): ```bash theme={null} # Sentinel Platform Services az ad sp create --id 4500ebfb-89b6-4b14-a480-7f749797bfcd # Microsoft Defender MCP az ad sp create --id 7b7b3966-1961-47b5-b080-43ca5482e21c ``` To check whether a service principal already exists, run `az ad sp show --id ` — a "does not exist" response confirms it's the one to create. Then connect again. ### "Microsoft did not return a refresh token" The Clarion Sentinel app needs the `offline_access` permission to poll on your behalf. Ask your Entra admin to grant **offline\_access** and try connecting again. ### "The sign-in used a different tenant than the one that granted consent" The account you signed in with at the second screen belongs to a different tenant than the one that granted admin consent. Reconnect using the **same account** that approved the consent. ### No incidents are arriving * Confirm the **Workspace ID** is correct and matches a workspace that actually receives incidents. * Check the monitor's **severity filter** — if you checked only `Critical`, lower-severity incidents are skipped by design. * Check the **Search** filter — a substring that doesn't match any incident title/description will suppress everything. * Remember polling is **forward-only**: incidents created before the monitor was connected aren't backfilled. # Microsoft Teams Source: https://docs.clarion.cantina.xyz/integrations/microsoft-teams Connect Microsoft Teams to Clarion so agents can post notifications to channels and chats, request approvals via Adaptive Cards, and reach the right people during incidents. This guide walks you through connecting Microsoft Teams to Clarion. Once configured, Clarion can post issue notifications to Teams channels and chats, request approvals through interactive Adaptive Cards, and let agents send messages to users in your Microsoft Entra tenant. The setup has four parts and is driven entirely from the Clarion UI: 1. **OAuth admin consent** — grant Clarion access to your Microsoft Entra tenant. 2. **Bot installation** — add the Clarion bot from the Microsoft Teams app store. 3. **Member mapping** — link Clarion workspace members to their Teams accounts. 4. **Notification channel** — pick a default Teams channel or chat for notifications. **Estimated time:** 15-20 minutes. You will need **Microsoft Entra admin** access (to grant tenant-wide consent), permission to add apps to your **Microsoft Teams** organization, and access to the Clarion workspace where you are configuring the integration. ## Prerequisites * A **Clarion workspace** with permission to manage integrations * A **Microsoft Entra** (Azure AD) account with permission to grant admin consent for tenant-wide applications * Permission to add apps from the Microsoft Teams app store (or [Teams Admin Center](https://admin.teams.microsoft.com) access if your organization blocks store apps) * A team and channel (or chat) in Microsoft Teams where Clarion should post notifications *** ## Step 1 — Connect with Microsoft 1. In Clarion, open **Integrations** and find **Microsoft Teams**. 2. Click **Connect with Microsoft**. A new tab opens to the Microsoft admin consent screen. 3. Sign in with a Microsoft Entra account that can grant tenant-wide consent. 4. Review the requested permissions and click **Accept** to grant consent for the entire tenant. Microsoft redirects back to Clarion and the integration is marked as connected. Clarion uses the **admin consent** flow with app-only (client credentials) tokens. The consenting account does not need to be the same account that uses Clarion day-to-day, because admin consent applies to your whole Microsoft Entra tenant. After connecting, Clarion shows a banner that setup is not complete until the remaining steps are finished. Click **Finish setup** to continue, or open **Integrations → Microsoft Teams → Open Teams configuration** at any time. *** ## Step 2 — Install the Clarion bot in Teams OAuth gives Clarion access to your tenant's directory and chats, but posting messages requires the Clarion bot app to be installed in your organization's Teams app catalog. The bot is published on the Microsoft Teams app store, so you can add it directly without uploading a package. 1. On the **Setup** page, find the **Bot Installation** card. 2. Click **Open in Teams app store** to open the [**Clarion by Cantina**](https://teams.cloud.microsoft/l/app/24e750bb-eba3-4abb-be8c-023749e0faf8) listing. 3. Click **Add** to install the bot for your organization. 4. Back in Clarion, click **Verify Installation**. When verification succeeds, the card shows a **Verified** badge and Clarion stores the bot's catalog ID for your tenant. The bot only needs to be installed once per Microsoft Entra tenant. If you reconnect Clarion later, the existing bot installation is reused. ### Install the app for everyone Adding the bot to your app catalog makes it **available**, but by default only the person who added it — and the workspace members you map in Step 3 — can act on Clarion's Adaptive Cards from inside Teams. When someone the app is not installed for clicks a button on an approval or clarification card, Teams blocks the click before it reaches Clarion and shows: > This action can't be performed since the app does not exist or has been uninstalled. To let **any teammate in a Teams chat or channel** — including guests and people without a Clarion account — respond to approval and clarification requests, install the Clarion app for everyone in your tenant: 1. Open [Teams Admin Center → Manage apps → **Clarion by Cantina** → Users and groups](https://admin.teams.microsoft.com/policies/manage-apps/24e750bb-eba3-4abb-be8c-023749e0faf8/users-and-groups?action=installs). 2. With **Installs** selected, click **Edit installs** and choose **Everyone**, then save. This pairs with two workspace settings under **Settings → Tool policies**: * **Anyone can respond to human input** — lets any workspace member (including read-only users) and any teammate in the linked chat answer approvals and clarifications, even without a Clarion account. * **Unrestricted Microsoft Teams messaging** — lets agents deliver those cards to any chat or channel, not only the ones named in skills or instructions. Installing the app for everyone is what makes those responders able to click the card buttons; the audit log still records who unblocked the agent. Guests and federated (cross-tenant) users cannot be provisioned this way — Clarion's bot is single-tenant, so they will still see the error. ### Alternative: manual upload If your organization blocks apps from the Teams app store, you can side-load the bot package instead: 1. In the **Bot Installation** card, click **Download Bot Package** to download the Clarion bot manifest (a `.zip` file). 2. Open [Microsoft Teams Admin Center → Manage apps](https://admin.teams.microsoft.com/policies/manage-apps). You can also click the **Manage apps** link in the Bot Installation card to jump straight there. 3. Click **Upload new app** and select the downloaded package. 4. Approve the app for your organization, then click **Verify Installation** back in Clarion. *** ## Private-label the bot (MSPs) Managed service providers running one Clarion workspace per client can rename the Teams bot so the client sees the provider's brand instead of Clarion. This is a beta feature. Ask your Clarion contact to enable it for a workspace. When it is on, the **Setup** page shows a **Bot branding** card above **Bot Installation**: 1. Enter a **Bot name** (up to 30 characters; Microsoft rejects longer names) and, optionally, a **Publisher** name. Save. 2. Click **Download Bot Package**. The manifest carries your brand. 3. Upload it in [Microsoft Teams Admin Center → Manage apps](https://admin.teams.microsoft.com/policies/manage-apps) → **Upload new app**, and approve it for the organization. 4. Back in Clarion, click **Verify Installation**. Your client then sees your name and publisher on the app in Teams, a description with no mention of Clarion, and a welcome message that omits the Cantina sign-up, docs, and support buttons the default bot shows. Branded workspaces skip the app store. Clarion verifies the installation by bot name, and the store listing is named "Clarion by Cantina", so a store install will not match the name you set. Renaming after the package is uploaded invalidates the installed app. The uploaded package still carries the old name, so verification fails until you download the new package, upload it again, and re-verify. Each save increments the manifest version, which is what makes Admin Center treat the re-upload as an update instead of rejecting it as a duplicate. ### Known limitations * **Developer links stay Cantina's.** Teams requires website, privacy, and terms URLs in every manifest; branded packages still point at `cantina.xyz`. These appear in the app's About page in Teams. * **Issue cards deep-link to Clarion.** The "View Details" button on an issue card opens `clarion.cantina.xyz`, because that is where the issue lives. * **Icons are Clarion's.** Custom icons are not supported yet; the package ships the default color and outline icons. * **One brand per Microsoft tenant.** The tenant app catalog holds a single entry per app, so two workspaces on the same Entra tenant cannot use different bot names. Clarion rejects the second, conflicting brand. * **Branded tenants are upload-only.** There is no store listing under your name, so every install goes through Admin Center. * **Clearing a brand needs a fresh install.** Reverting to default branding resets the manifest version to `1.0.0`, which Admin Center will not accept as an update over a branded package. Remove the uploaded app first, then install "Clarion by Cantina" from the store. *** ## Step 3 — Link workspace members to Teams accounts For approval cards and direct messages to reach the right person, Clarion needs to know each workspace member's Microsoft Teams identity. 1. On the **Member Mapping** card, click **Auto-match** to link members whose Clarion email matches a Microsoft Entra user. 2. For any members who did not auto-match, use the dropdown next to their name to pick the correct Teams user. 3. At least one member must be linked before you can run the test connection in Step 4. Member mapping is stored as the user's Microsoft Entra object ID. If you re-invite a workspace member or they change email, you may need to re-link them. *** ## Step 4 — Test the connection 1. On the **Test Connection** card, click **Create Test Chat**. 2. Clarion creates a small group chat in Teams that includes the linked members and posts a test message. 3. Open Teams and confirm the message arrived. The card also shows a direct link to the test chat. If the test succeeds, the integration is ready to use. If it fails, check the troubleshooting section below. *** ## Step 5 — Choose a default notification channel Click **Back to Teams settings** to return to the main configuration page. The **Default notification channel** section lets you pick where Clarion posts notifications and approval requests by default. You can choose between two target types: * **Channel** *(recommended for broadcasts)* — pick a team, then a channel within that team. Anyone in the channel can see and respond to Clarion's messages and approval cards. * **Chat** — pick an existing Teams chat, or have Clarion create a new ad-hoc group chat with the workspace members you choose. Agents can still post to other channels or chats per-call when needed; this default is used when an agent does not specify a target. *** ## What Clarion can do Once Microsoft Teams is fully connected, agents can: * **Post messages to a Teams channel** — broadcast incident updates to a team channel. * **Post messages to a Teams chat** — send updates to an existing chat (group or 1:1) by chat ID. * **List channels and chats** the bot has access to, so agents can pick the right destination. * **Create an ad-hoc group chat** with specific users — used as a last resort when no existing channel or chat fits. * **List users in your Microsoft Entra directory** to look up who to message. Clarion also sends **issue notifications** and **approval cards** to the default target. Approval buttons (Approve / Reject) inside Teams are wired back to Clarion through the bot, so on-call responders can resolve approval requests without leaving Teams. *** ## Disconnect Microsoft Teams To disconnect: 1. Open the **Microsoft Teams** integration in Clarion. 2. Click **Disconnect** in the status card and confirm. Clarion stops sending notifications to Teams and clears the stored tenant credentials. The Clarion bot app remains in your Teams Admin Center until you remove it manually from **Manage apps**. # NightVision Source: https://docs.clarion.cantina.xyz/integrations/nightvision Bring DAST findings into Clarion so agents can look up vulnerability issues, scans, and targets during triage. NightVision is a dynamic application security testing (DAST) scanner. Connecting it gives agents read-only lookups over your findings, scans, targets, and projects — so a vulnerability report can be checked against what the scanner actually observed. **Estimated time:** 3 minutes. You will need a NightVision **service token**. ## Prerequisites * A **NightVision** account with scans configured * A service token with read access ## Connect 1. In NightVision, create a **service token**. 2. In Clarion, open **Integrations** and find **NightVision**. 3. Paste the **API token** and click **Connect**. The token is stored encrypted and never enters the agent sandbox. ## What agents can do | Tool | What it returns | | --------------- | ------------------------------------ | | `list_issues` | Vulnerability issues, filterable | | `get_issue` | Full detail for one issue | | `list_scans` | Scan history | | `list_targets` | Configured scan targets | | `list_projects` | Projects in your NightVision account | This integration is **read-only**: no ingest, no poller, and no scan triggering. It exists to enrich an investigation with DAST evidence, not to run the scanner. ## Where it helps Pair NightVision with the vulnerability-domain skills. When a bug-bounty submission or a dependency finding claims an exploitable path, the agent can check whether your own DAST already saw it — and whether the target is in scope at all. ## Disconnect Click **Disconnect** on the integration page. The stored token is deleted. # NinjaOne Source: https://docs.clarion.cantina.xyz/integrations/ninjaone Connect NinjaOne to Clarion to triage RMM conditions and let agents look up device health, patching, and software during an investigation. This guide walks you through connecting your NinjaOne tenant to Clarion. Once connected, Clarion turns NinjaOne's triggered conditions into issues your agents can triage, and gives those agents read-only lookups across every managed device. **Estimated time:** 5 minutes. You will need **NinjaOne system administrator** access to create the API client app. ## Prerequisites * Access to your NinjaOne instance as a **system administrator** * A **Clarion workspace** with the NinjaOne integration open *** ## Step 1 — Create an API client app in NinjaOne 1. In NinjaOne, go to **Administration → Apps → API**. 2. Open the **Client app IDs** tab and click **Add**. 3. Set **Application platform** to **API Services (machine to machine)**. 4. Under **Allowed grant types**, select **Client Credentials**. 5. Under **Scopes**, select **Monitoring**. 6. Save, then copy the **Client ID** and **Client Secret**. Copy the client secret immediately — NinjaOne shows it only once. If you lose it, create a new client app rather than reusing an old one. Clarion only ever requests the **Monitoring** scope, which is read-only. It never asks for Management or Control, so it cannot run scripts, reboot machines, or start remote sessions. *** ## Step 2 — Connect in Clarion 1. In Clarion, open the **NinjaOne integration** from your workspace settings. 2. Choose your **Region**. This is the NinjaOne instance you sign in to — for example `app.ninjarmm.com` for the United States or `eu.ninjarmm.com` for Europe. Credentials issued in one region will not work against another. 3. Paste the **Client ID** and **Client Secret**. 4. Click **Connect**. Clarion verifies the credentials against NinjaOne before saving them, so a mistyped secret or the wrong region is reported straight away rather than failing quietly later. *** ## Step 3 — Add a NinjaOne monitor The integration on its own gives your agents device lookups. To turn NinjaOne's triggered conditions into Clarion issues, add a **NinjaOne monitor**: 1. Open the agent you want to receive NinjaOne conditions. 2. Add a **NinjaOne** monitor. 3. Optionally narrow what gets ingested: * **Severity filter** — leave everything selected to ingest every severity. Unchecked severities are dropped before an issue is created. * **Organizations** — a comma-separated list of NinjaOne organization IDs. Leave it empty to cover the whole tenant. Only *triggered conditions* become issues. The rest of NinjaOne's activity log — job progress, policy edits, condition resets — is not turned into issues, though your agents can still read it per device. *** ## Step 4 — Choose how conditions reach Clarion Under **Ingestion** on the integration page you can pick one of two delivery methods. **Polling (default).** Clarion checks NinjaOne every minute for new triggered conditions. Nothing to configure, and it works on any tenant. **Webhook.** NinjaOne pushes each triggered condition to Clarion the moment it fires, which removes the polling delay. Turning the switch on registers the webhook in NinjaOne for you. NinjaOne supports **one webhook destination per API client app**. Enabling the webhook for a second monitor repoints NinjaOne at that monitor rather than adding a second delivery. Two things can stop the webhook from being registered: * The API client app was not created by a **system administrator**. * The same client app already has a **PSA channel** configured, such as ConnectWise or Autotask. In either case, either create a separate API client app for Clarion, or stay on polling. Polling delivers the same conditions with the same filters — only the delay differs. Switching back to polling deregisters the webhook in NinjaOne automatically. *** ## What your agents can do With NinjaOne connected, agents triaging *any* issue — not only NinjaOne ones — can look up: * **Devices** — search by hostname, or list with a NinjaOne device filter * **Device detail** — OS, organization and location, approval status, and last check-in * **Health** — NinjaOne's own health rollup for a device * **Patching** — applicable OS and software patches and their install state * **Software** — installed applications and versions * **Services** — Windows service state and start type * **Storage** — disks, volumes, free space, and SMART status * **Network** — interfaces and the last logged-on user * **Conditions** — what is currently firing, on one device or across the tenant Every one of these is read-only. *** ## Troubleshooting **"NinjaOne rejected these credentials."** The client ID or secret is wrong, or the region does not match the instance you sign in to. Check the region first — it is the most common cause. **"These credentials were accepted but lack the `monitoring` scope."** Edit the client app in **Administration → Apps → API** and add the Monitoring scope. **No issues appearing.** Confirm a NinjaOne monitor exists and is attached to an agent, that the condition you expect is actually firing in NinjaOne, and that its severity is not excluded by the monitor's severity filter. **Conditions from the wrong customers.** Set the monitor's **Organizations** filter to the organization IDs this workspace should cover. # Notion Source: https://docs.clarion.cantina.xyz/integrations/notion Connect Notion to Clarion with a connection token so agents can search and read your docs, runbooks, and databases for context during triage. This guide shows how to connect Notion to Clarion using a Notion connection (a workspace-scoped bot with its own token — previously called an internal integration). **Estimated time:** 5-10 minutes. You need access to: * A **Clarion workspace** * A **Notion workspace** where you are a **workspace owner** (only workspace owners can create connections) ## Prerequisites Before connecting Notion in Clarion, make sure you have: * Workspace-owner access in Notion * A decision about which pages, wikis, and databases Clarion should be able to read Notion grants access **page by page**, not workspace-wide. Clarion can only see content that you explicitly share with the connection. Sharing a top-level page shares everything nested under it. *** ## Step 1 - Create a Notion connection Notion calls these "connections" (previously "internal integrations") — a bot scoped to your workspace with its own token. 1. In Notion, go to **Settings** → **Connections** → **Develop or manage connections**. This opens Notion's Developer portal ([app.notion.com/developers](https://app.notion.com/developers)). 2. Click **Create a Connection**, give it a name (e.g. "Clarion"), and pick the workspace to connect. 3. In the connection's **Configuration** tab, enable the read capabilities: * **Read content** * **Read user information** (name and email is fine) Clarion is read-only — you do not need any insert or update capabilities. 4. Copy the connection's token from the **Configuration** tab (it starts with `ntn_`). If you set an expiration on the token, note the date — Clarion will lose access when it expires and you will need to paste a fresh token. *** ## Step 2 - Share content with the connection Clarion can only read pages that are shared with the connection. Either: * **Per page:** open a page, click **•••** → **Connections**, and add your new connection. All sub-pages inherit access. * **In bulk:** open the connection in the Developer portal and add pages and databases from its content access settings. Most teams share their top-level engineering wiki or runbooks page once — everything nested under it becomes readable. *** ## Step 3 - Connect Notion in Clarion 1. In Clarion, go to **Integrations**. 2. Open **Notion**. 3. Paste the connection token. 4. Click **Connect**. Clarion validates the token and shows the connected Notion workspace name. *** ## Step 4 - Verify the connection After connecting, click **Verify**. This confirms the token still works and that at least one page is shared with the connection. If verification warns that no pages are shared, go back to [Step 2](#step-2---share-content-with-the-connection) — the token is valid, but agents will get empty search results until content is shared. *** ## How Notion tools use this integration When Notion tools are enabled, Clarion agents can: * **Search pages and databases by title.** Notion's API matches titles only, so agents search with distinctive keywords and then read pages in full. * **Read a page as Markdown**, including runbooks, incident docs, and architecture notes. * **Query databases** (data sources) with filters and sorts — useful for runbook tables, service catalogs, and on-call rotations. * **List workspace members** to resolve document owners or mentions. Clarion never writes to your Notion workspace. *** ## Troubleshooting ### "Notion rejected the token" * Check you copied the connection's full token from its **Configuration** tab (it starts with `ntn_`). * The token may have expired (if it was created with an expiration) or been revoked. Create a fresh one and reconnect. ### "The Notion token authenticated but lacks the required read capabilities" Open the connection in Notion's Developer portal and enable the **read content** and **read user information** capabilities in its **Configuration** tab. Capability changes take effect immediately. ### Searches come back empty The connection has no shared content. Share pages via a page's **••• → Connections** menu or the connection's content access settings in the Developer portal. Remember access is page-by-page — a valid token alone grants nothing. ### Enterprise workspaces Notion Enterprise admins can restrict who may install or add connections. If you cannot add the connection to pages, ask a workspace owner to approve it first. # Okta Source: https://docs.clarion.cantina.xyz/integrations/okta Clarion is a security operations platform that helps teams detect, investigate, and respond to identity and access threats. Install the Clarion Okta app from the Okta Integration Network to connect your Okta org to Clarion. This guide explains how to install the Clarion Okta API Service integration from the Okta Integration Network (OIN) and connect it to Clarion. Once configured, Clarion can ingest Okta security events, triage suspicious activity, and support response actions from a single workflow. **Estimated time:** 5-10 minutes. You will need **Okta Admin** access and access to the Clarion workspace where you want to connect Okta. Use the OIN catalog installation flow described below. Do not create a custom Okta API Services app or manually configure an Okta Event Hook for this integration. ## Prerequisites * Access to an Okta org with permission to install API Service integrations * Access to the Clarion workspace where you want to configure the Okta integration * A secure place to store the client secret shown during the Okta install flow ## Supported Okta scopes The Clarion Okta app supports the following Okta API scopes: * `okta.eventHooks.manage` - create, update, verify, and delete the Clarion-managed Okta Event Hook * `okta.logs.read` - read Okta System Log events used for monitoring and investigation enrichment * `okta.users.manage` - look up users and their group memberships, and support response actions such as account suspension from Clarion * `okta.groups.manage` - remove a user from a group to de-escalate group-derived privilege during response (requires human approval in Clarion) ## Install the Clarion app in Okta 1. Sign in to the **Okta Admin Console**. 2. Go to **Applications** > **API Service Integrations**. 3. Click **Add Integration**. 4. Search for **Clarion by Cantina**. 5. Select the integration and continue to the authorization step. 6. Review the requested scopes, then click **Install & Authorize**. 7. Copy the **Client Secret** from the one-time confirmation dialog and store it securely. 8. Open the installed Clarion integration in Okta and copy the **Client ID** from the **General** tab. 9. Note your Okta org domain, for example `company.okta.com`. When entering the Okta domain in Clarion, you can paste the hostname, a full Okta URL, or an Admin Console hostname such as `company-admin.okta.com`. Clarion automatically normalizes it to the org hostname, such as `company.okta.com`. ## Connect Okta in Clarion 1. Open Clarion and go to **Integrations** > **Okta**. 2. Enter the following values: * **Okta Domain** - your Okta org hostname only, such as `company.okta.com` * **Client ID** - the value from the installed Clarion integration in Okta * **Client Secret** - the value shown during **Install & Authorize** 3. Click **Connect**. 4. Clarion validates the credentials, provisions the managed Okta Event Hook, and saves the integration. ## Verify the connection After connecting: * The Okta integration status in Clarion should show **Connected** * The **Managed Okta connection** section should show the connected org and Event Hook ID * Clarion should provision the webhook endpoint automatically without requiring additional Okta-side Event Hook setup ## Enable Clarion detection rules Click **Add recommended filters** to enable Clarion's detection rules. These rules monitor for suspicious activity and open issues, adding an extra layer of security on top of Okta's built-in alerts. ## Upgrade an existing installation for new scopes Okta does not add newly approved scopes to an API Service integration that is already installed. For example, an existing Clarion installation does not automatically receive `okta.groups.manage` when Clarion adds group-removal support. Rotating that installation's client secret does not add the scope either. To authorize the updated scopes: 1. In the **Okta Admin Console**, go to **Applications** > **API Service Integrations** and install **Clarion by Cantina** again. 2. Confirm that the authorization screen includes `okta.groups.manage`, then click **Install & Authorize**. 3. Copy the new **Client ID** and **Client Secret**. Keep the previous Okta installation until the new connection is working. 4. In Clarion, go to **Integrations** > **Okta**, click **Disconnect**, and connect again using the new credentials. 5. Confirm that Clarion shows the integration as **Connected** and has provisioned the managed Event Hook. 6. Revoke the previous Clarion API Service integration in Okta. The previous client ID and secret continue to authorize only the scopes granted when that integration instance was installed. Okta creates new credentials for the newly authorized instance, so you must save those credentials in Clarion before group-removal actions can work. ## Reconnect an existing Okta integration If your workspace connected Okta before the OIN-based app flow was introduced, Clarion may show **Reconnect required** instead of **Connected**. If Clarion still has the saved Okta app credentials, use **Recreate managed hook** to create a fresh Clarion-owned Event Hook without re-entering credentials. If Clarion asks for new credentials: 1. Install **Clarion by Cantina** from **Applications** > **API Service Integrations** in the same Okta org. 2. Copy your **Okta Domain** and the generated **Client ID** and **Client Secret** from the installed app. 3. Return to Clarion and use **Save credentials and reconnect** on the Okta integration page. If you no longer have the original client secret, rotate it from the installed Clarion app in Okta before reconnecting. ## What Clarion does after connection Once connected, Clarion can: * Receive supported Okta events in real time * Use Okta System Log data to enrich investigations * Open issues and triage suspicious activity in Clarion * Support response actions such as suspending compromised accounts, or removing a user from a group to revoke privilege, when initiated from Clarion workflows ## Troubleshooting ### `401 Unauthorized` during connect * Confirm you are using the **Client ID** and **Client Secret** from the installed **Clarion by Cantina** API Service integration in the same Okta org * If you no longer have the client secret, generate a new secret in Okta and reconnect Clarion with the rotated value ### The Okta domain is rejected or the token request fails * Paste the Okta org hostname or full Okta URL from the same org; Clarion automatically removes protocol, path, trailing dots, and supported Admin Console suffixes * If the value is still rejected, confirm it belongs to an Okta org domain such as `company.okta.com`, `company.okta-emea.com`, or `company.oktapreview.com` * Confirm you are using the Client ID and Client Secret from the installed Clarion app in that same Okta org ### The connection succeeds but no hook is created * Confirm the integration was installed from **Applications** > **API Service Integrations** * Confirm the authorized app includes the supported scopes listed above * Retry the Clarion connection or use **Recreate Hook** from the Okta integration page in Clarion # OpenClaw Source: https://docs.clarion.cantina.xyz/integrations/openclaw Monitor AI agents for policy violations, unusual tool use, and skill activity via ClawSight telemetry. OpenClaw sends agent telemetry to Clarion through the **ClawSight** plugin, so the AI agents running in your environment are monitored the same way any other workload is. **Estimated time:** 5 minutes. You will need access to your ClawSight plugin configuration. ## Prerequisites * OpenClaw with the **ClawSight** plugin installed * Ability to edit `openclaw.plugin.json` ## Step 1 — Connect in Clarion 1. In Clarion, open **Integrations** and find **OpenClaw**. 2. Enter an **API token** — this is the bearer token ClawSight will authenticate with. Use a strong, unique value. 3. Click **Connect**. Clarion shows you the **platform URL** to use. ## Step 2 — Configure ClawSight In `openclaw.plugin.json`, set: * `platformUrl` — the URL Clarion showed you. The plugin appends `/v1/telemetry/ingest` automatically, so do not add it yourself. * `apiToken` — the same token you entered in Clarion. Telemetry starts arriving once the plugin reloads. ## What Clarion watches * **Skill activity** — which skills agents invoke, and how often. * **Policy violations** — actions that break the policies you configured. * **Unusual tool use** — tool calls that fall outside an agent's established pattern. These feed the [AI Agent Monitoring](/learn/agents/our-agents) agent. The AI Agent Monitoring template ships without bundled skills. Attach skills from the [library](/learn/skills/our-skills), or write your own, to define how these events should be triaged. ## Rotate the token Enter a new value in **Update API Token** on the integration page, then update `apiToken` in the plugin config to match. ## Disconnect Click **Disconnect** on the integration page. Telemetry sent afterwards is rejected. # PagerDuty Source: https://docs.clarion.cantina.xyz/integrations/pagerduty Connect PagerDuty to Clarion so agents can page your on-call rotation through PagerDuty's Events API v2 during triage. This guide walks you through connecting PagerDuty to Clarion. Once connected, agents can trigger PagerDuty incidents from a skill or workspace prompt whenever they decide — based on what they found during triage — that an on-call human needs to be paged. **Estimated time:** 5 minutes. You'll need permission to add an **Events API v2** integration to at least one PagerDuty service. ## Prerequisites * A **PagerDuty** account with permission to manage services * One or more **services** in PagerDuty configured with the escalation policies you want Clarion to use * A **Clarion workspace** with the PagerDuty integration page open *** ## Step 1 — Enable PagerDuty in Clarion 1. In Clarion, open **Integrations** and find **PagerDuty**. 2. Click **Enable PagerDuty**. The integration is now active but won't deliver anything yet — PagerDuty needs at least one notification channel. *** ## Step 2 — Create an Events API v2 integration in PagerDuty For each service Clarion should be able to page, generate a routing key: 1. In PagerDuty, open the **service** you want Clarion to page. 2. Go to the **Integrations** tab. 3. Click **Add another integration**. 4. Choose **Events API v2** as the integration type. 5. Give it a recognisable name, for example *Clarion — SecOps*. 6. Click **Add** and copy the **Integration Key** (also called *routing key*) that PagerDuty shows you. Each routing key targets exactly one PagerDuty service and its escalation policy. If you want different paths for different scenarios (e.g. SecOps vs Platform on-call), create one routing key per service. *** ## Step 3 — Add the channel in Clarion 1. Back on the Clarion PagerDuty integration page, click **Add channel**. 2. Enter a **name** that identifies the rotation — for example *SecOps on-call*. 3. Paste the **routing key** from PagerDuty. 4. Click **Add channel**. 5. Use the **Send test event** button next to the new row to confirm the routing key is valid. Clarion sends a `trigger` event and immediately resolves it, so the test will briefly appear in PagerDuty before clearing itself. Repeat for any other services you want to wire up. *** ## Step 4 — Reference PagerDuty in a skill or workspace prompt PagerDuty isn't a Clarion escalation channel — operators don't acknowledge pages back into Clarion. Instead, agents call PagerDuty directly when a skill or the workspace system prompt tells them to. 1. Open a **skill** (or the **workspace system prompt**) in Clarion. 2. Type `#` in the editor and pick **PagerDuty** from the channel/notification menu. 3. The block embeds with no extra configuration — the agent picks which PagerDuty channel to page at runtime, so the same skill works in any workspace that has PagerDuty channels configured. ### What the agent can do When the skill runs and the workspace has at least one PagerDuty channel, the agent gets two tools: | Tool | Purpose | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `mcp__pagerduty__list_channels` | List channels the workspace has configured (returns `id` + `name`). The agent calls this first to know which channels exist. | | `mcp__pagerduty__trigger_alert` | Page a specific channel. The agent passes the channel `id`, a `summary` (the PagerDuty incident title), and a `severity` (`critical` / `error` / `warning` / `info`). Optionally a `dedupKey` to coalesce repeats, and `customDetails` to surface structured fields in PagerDuty's "Custom Details" panel. | The routing key never leaves the Clarion server — the agent only ever sees the channel id. Clarion resolves the id to the routing key when actually calling the PagerDuty Events API. ### Default approval gating `trigger_alert` requires human approval by default because it pages on-call humans. The agent pauses, the configured notification channel pings the operator, and execution resumes once the request is approved. You can change this in **Workspace → Tools** for `mcp__pagerduty__trigger_alert` if you want certain skills to page automatically. ### Severity rules of thumb * `critical` — production is down, someone needs to act in minutes. Routes through PagerDuty's escalation policy at full urgency. * `error` — urgent but not immediately dangerous. Sensible default for "this is bad, someone should look at it." * `warning` — action will be needed but not right now. Good for backlog work surfaced during triage. * `info` — FYI; will not page in most PagerDuty service configurations. ### Coalescing repeat pages with `dedupKey` If a skill might trigger more than once for the same underlying condition (e.g. the agent runs again on a recurring issue), pass a stable `dedupKey` — for instance the issue id, the affected resource ARN, or any identifier that uniquely names the condition. PagerDuty will *update* the existing incident instead of opening a new one. Omit `dedupKey` and Clarion generates a key based on the channel and summary, so accidental re-fires inside a single agent run still coalesce. ### Alert title and details Clarion automatically rewrites every PagerDuty alert so the on-call responder can act on it without leaving PagerDuty: * The incident **summary** is always prefixed with `[Cantina Clarion]` regardless of what the agent supplied. * The incident's **Custom Details** panel always includes a `clarion_url` field linking back to the source issue in Clarion (or to the workspace if the agent run wasn't issue-driven). *** ## Disconnect To remove the PagerDuty integration: 1. In Clarion, open **Integrations → PagerDuty**. 2. Remove the individual channels you no longer need, or 3. Disconnect the whole integration from the integrations list. Disconnecting deletes the stored routing keys. Re-enabling later means re-adding each channel; the PagerDuty services themselves are unaffected. *** ## Troubleshooting ### "PagerDuty test failed: ..." The routing key was rejected. Common causes: * The key was copied with extra whitespace — re-copy from PagerDuty. * The integration in PagerDuty is **Events API v1** rather than v2. Clarion only supports v2. * The PagerDuty service the integration belongs to has been deleted or suspended. # Replit Source: https://docs.clarion.cantina.xyz/integrations/replit Connect your Replit Enterprise Account to Clarion so the exposure agent can find deployments that are reachable from the public internet but were never meant to be. This guide walks you through connecting a Replit Enterprise Account to Clarion. Once connected, Clarion's Exposure Agent sweeps the Account daily: it lists your workspaces and deployments, reads each deployment's privacy setting, checks whether the public ones actually answer on the internet, and opens an issue for anything that looks internal but is reachable by anyone. **Estimated time:** 5 minutes. You will need to be an **admin of a Replit Enterprise Account**, since the Admin API is only available to Account admins on Enterprise Accounts. ## Prerequisites * A **Replit Enterprise Account**, and **admin** access to it * The ability to create an **Admin API key** with read scope * A **Clarion workspace** with the Replit integration page open One Clarion workspace connects one Replit Account. The key you paste grants read access to everything in the Account that issued it, so create it from the Account whose deployments you want swept. *** ## Step 1 — Create an Admin API key in Replit 1. Sign in to Replit as an Account admin. 2. Open your **Account** settings and find the **Admin API** section. 3. Create a new API key with **read** scope. 4. Copy the key. It begins with `rpl_`. Copy the key immediately and store it securely — Replit may only show it once. Grant read scope only; Clarion never writes to Replit. *** ## Step 2 — Enter the key in Clarion 1. In Clarion, open **Integrations** and find **Replit** under Development & Planning. 2. Paste your **Admin API key**. 3. Click **Connect**. Clarion checks the key against Replit before saving it. If the key is wrong or the Account is not entitled to the Admin API, you'll see a clear error and nothing is stored. To rotate a key later, paste the new one and connect again — it replaces the old one. *** ## What the exposure agent does The Exposure Agent runs a daily sweep of every provider you have connected. For Replit it: | Step | What happens | | ------------------ | ------------------------------------------------------------------------------------------------------ | | Enumerate | Lists the Account's workspaces and their deployments | | Read posture | Records each deployment's privacy as `public`, `password`, or `private` | | Check reachability | Requests the root of public deployments only, and records the response status — never the page content | | Classify | Separates deployments that show a login page from those serving open content | | File | Opens and escalates an issue for each reachable deployment that looks internal, up to ten per run | | Remember | Records each verdict so an intentionally public site stops being re-reported | Deployments set to `password` or `private` are recorded as gated and never contacted. The reachability check is read-only: Clarion requests the deployment's root address, follows at most two redirects, and keeps only the status code, byte count, and whether the page mentioned signing in. No page content, headers, or cookies are stored, shown, or sent to the agent. ### Agent tools Once connected, agents on this workspace gain access to the `/replit` action, which exposes these read-only tools: | Tool | What it does | | ----------------------- | ------------------------------------------------------------------------------ | | `list_workspaces` | List every workspace in the connected Account | | `list_projects` | List a workspace's projects, including who owns each | | `list_deployments` | List a workspace's deployments with their privacy setting, status, and address | | `get_deployment` | Fetch one deployment's current privacy setting and status | | `list_members` | List a workspace's members, used to route a finding to its owner | | `probe_deployment_root` | Check whether one public deployment answers on the internet | All six are read-only and need no approval. None of them can change anything in Replit. *** ## Disconnect To remove the integration: 1. In Clarion, open **Integrations → Replit**. 2. Click **Disconnect**. This deletes the stored key. The exposure agent stops sweeping Replit, and any saved skills that reference the `/replit` action will surface the integration as missing until you reconnect. *** ## Troubleshooting ### "Replit rejected the key" The key is malformed, unknown, revoked, or expired. Create a fresh Admin API key in your Replit Account settings and connect again. Check that you copied the whole key, including the `rpl_` prefix. ### "The key needs read scope and Enterprise Admin API entitlement" Replit authenticated the key but refused the request. Either the key was issued without read scope, or the Account is not an Enterprise Account with Admin API access. Confirm both with your Replit administrator. ### A deployment I expected is missing from the sweep summary If the summary says coverage was **incomplete**, Replit returned more results than a single sweep walks, and some deployments were not examined. Each run starts from the beginning rather than resuming where the last one stopped, so the same deployments are examined every time and the ones past the limit stay unexamined until the limit is raised. The summary reports this per run, so incomplete coverage is always stated rather than implied. If you see it, let us know how many workspaces and deployments your Account has. # SentinelOne Source: https://docs.clarion.cantina.xyz/integrations/sentinelone Forward Singularity Endpoint threat detections from SentinelOne into Clarion as issues. This guide explains how to connect SentinelOne to Clarion. Once configured, every threat SentinelOne raises on your chosen site becomes a Clarion issue that agents can triage and investigate. **Estimated time:** 10-15 minutes. You will need **Site Admin** (or higher) access in SentinelOne, plus access to the Clarion workspace where you want to connect SentinelOne. ## What you'll configure Connecting SentinelOne takes three things: | What | Purpose | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Clarion webhook URL + secret** | SentinelOne posts threats to this URL. The secret, sent as the `x-webhook-secret` header, authenticates them. Both are generated when you click **Connect**. | | **SentinelOne API token** | A Service User token with the **SOC role** that lets Clarion enrich each issue with the full threat details and run response actions (mitigate, isolate, set verdict/status). Without it, issues are sparse. | | **Console URL** | Your tenant URL, used for the "View in SentinelOne console" deep link on issues. | ## Prerequisites * A SentinelOne console with at least one Linux, macOS, or Windows agent enrolled * An admin role on the SentinelOne account or site you want to forward * Access to the Clarion workspace where you want to configure the integration ## Step 1 — Connect SentinelOne in Clarion 1. Open Clarion and go to **Integrations** → **SentinelOne**. 2. Click **Connect**. Clarion generates the webhook URL and a webhook secret for this workspace. 3. **Copy the webhook URL and secret immediately.** The secret is shown only once; if you lose it you'll have to disconnect and reconnect to generate a new one. Keep these on your clipboard or paste them into a password manager — you'll need them in steps 3 and 4. ## Step 2 — Create a SentinelOne Service User (SOC role) You can use a personal API token (tied to your user) for testing, but for the actual integration we recommend a dedicated **Service User** so the token survives if the original creator's account changes. 1. In the SentinelOne console: **Policies and settings → User management → Service Users**. 2. Click **+ New Service User**. 3. Fill in: * **Name:** `clarion-integration` * **Description:** `Used by Clarion to enrich and action threats.` * **Scope:** prefer **Site** (the specific site you're forwarding from) over Account — least privilege. * **Role:** **SOC**. This grants both read and edit access on Threats, so Clarion can enrich issues *and* run response actions (mitigate, isolate, set verdict/status). A custom role with equivalent Threats read/edit access also works. A read-only role (e.g. Viewer) only enriches issues and cannot action threats. * **Expiration:** set to 1 year; rotate annually. 4. Save → the console shows the **API Token** once. Copy it immediately. ## Step 3 — Paste console URL and API token into Clarion Back on Clarion's SentinelOne configure page, fill in **Console details**: * **Console URL** — your tenant URL, e.g. `https://your-tenant.sentinelone.net`. No trailing slash. * **Site ID / Account ID** — optional; populated automatically once the first real threat lands but you can pre-fill them if you have them. * **API token** — paste the token from step 2. Click **Save**. The page will show `API token (stored — leave blank to keep)` next to the field on subsequent visits, confirming the token is set. ## Step 4 — Configure the SentinelOne side SentinelOne sends webhooks via the **Singularity Webhook** marketplace app. The built-in Notifications channels (SMTP, Syslog) don't support arbitrary headers, so the marketplace app is required for auth to work. ### 4a. Install Singularity Webhook 1. SentinelOne console → **Marketplace**. 2. Search for **Singularity Webhook**. 3. **Install** (or **Add Configuration** if already installed). Scope to the site you want to forward from. ### 4b. Configure Threat Response Action 1 In the configuration screen: * Toggle **Make Response Actions available as Manual Response Actions from Threats** to **on** (so you can also fire the webhook manually from a threat in the SentinelOne console). * Under **Advanced**, leave **Auto-Disable on Unauthorized Error** on. * Expand **Threat Response Action 1**: * **Name:** `Clarion` * **Description:** `Forward threats to Clarion` * **Automation Trigger Options:** `All Threats` * **URL:** paste the **Clarion webhook URL** from step 1. * **Action:** `POST` * **Webhook Request Body:** switch to **Custom** (the presets ship without custom headers, so they can't authenticate). ### 4c. Custom Body The webhook body only needs the threat ID — Clarion fills in the rest. Paste this as **Define custom message body**: ```json theme={null} { "threatId": "${activity.threatInfo.threatId}" } ``` Use the `${activity.…}` placeholder syntax (braces, not `$(…)` parentheses). `${activity.threatInfo.threatId}` and `${activity.id}` both resolve to the threat ID and work equally well. ### 4d. Headers Set **Headers** to: ```json theme={null} {"Content-Type": "application/json", "x-webhook-secret": "${Var1}"} ``` Then scroll down to the **Secret variables** section: * **Var1 — Secret variable description:** `Clarion webhook secret` * **Var1 — Secret variable value:** paste the **Clarion webhook secret** from step 1. Click **Install**. ### 4e. Test the connection In the Threat Response Action 1 view, click **Test Connection**. SentinelOne should report `Status 200` (or `201`) — and you should see a corresponding `webhook accepted: alert created` log line in your Clarion environment. SentinelOne's "Test Connection" sends the template with `${activity.…}` placeholders unsubstituted (because there's no threat in scope during the test). A test issue *will* be created in Clarion with literal-string placeholder values in the payload — that's expected. A real threat detection produces the resolved payload. ## Step 5 — Verify with EICAR The cleanest end-to-end test is the [EICAR test file](https://www.eicar.org/download-anti-malware-testfile/). On any enrolled endpoint: ```bash theme={null} echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > /tmp/eicar.com ``` Within \~1 minute SentinelOne mitigates the file, posts the thin webhook to Clarion, and Clarion calls back to fetch the full threat. You should see an issue titled `[SentinelOne] eicar.com — ` under **Issues**, with full description (file path, SHA256, mitigation status, endpoint IP, site name, deep link back to the console). ## How severity is mapped SentinelOne's payload doesn't include a `severity` field — only `confidenceLevel: "malicious" | "suspicious" | …`. Clarion maps it like this: | SentinelOne `confidenceLevel` | Clarion severity | | ----------------------------- | ---------------- | | `malicious` | high | | `suspicious` | medium | | anything else | medium (default) | If a custom template ever sends a `severity` field with `Critical`/`High`/`Medium`/`Low`/`Informational`, Clarion uses that directly and ignores the confidence fallback. ## Troubleshooting ### `webhook rejected: missing authentication header` in Clarion logs The `x-webhook-secret` header isn't reaching Clarion. Most common causes: * You switched the Singularity Webhook body mode from **Custom** to a preset; presets drop custom headers. * The `Var1` value field is blank, while the headers JSON references `${Var1}`. * The headers JSON has a syntax error and SentinelOne is silently sending no headers. ### `webhook rejected: invalid authentication token` The `x-webhook-secret` value doesn't match what's stored on the Clarion integration. You probably rotated the secret in Clarion (disconnect + reconnect) and forgot to update Var1 in SentinelOne, or vice versa. Reconnect in Clarion and re-paste the new secret into Var1. ### Issues are created but with empty fields The API token is missing, expired, or scoped to the wrong account/site, so Clarion can't pull the threat details. Regenerate the token in SentinelOne and re-paste it into Clarion's **API token** field. ### `${activity.…}` placeholders showing as literal text in the issue payload You're most likely seeing a Test Connection issue, where placeholders don't substitute by design — see step 4e. If a real detection also shows the literal `${activity.threatInfo.threatId}` string, re-paste the minimal template exactly as shown in step 4c (braces, not `$(…)` parentheses). ### `Authentication issue occurred while running automated_response_actions. (1) Invalid json value for Body field` SentinelOne validates the Custom Body as JSON at save time, before any substitution. A bare `${activity}` or `$(activity)` is not valid JSON. Only string-position placeholders (`"threatId": "${activity.threatInfo.threatId}"`) work. ## Why the API token matters With the minimal body above, the webhook only carries the threat ID — Clarion needs the API token to turn that into a complete issue (threat name, classification, host, file, mitigation status, console link). The same token also lets Clarion run response actions back in SentinelOne (mitigate, isolate, set verdict/status), which is why we recommend the **SOC role** rather than a read-only one. Without a token, issues will be sparse, so we strongly recommend configuring one. # Slack Source: https://docs.clarion.cantina.xyz/integrations/slack Install the Clarion app for Slack — what Clarion does, how it works inside Slack, where to find the Add to Slack button, and how your data is handled. This page is the home of the **Clarion app for Slack**: what Clarion does, how it integrates with your Slack workspace, how to install and configure it, and how your data is handled. ## What Clarion does [Clarion](https://clarion.cantina.xyz) is [Cantina](https://www.cantina.security)'s agentic security orchestration platform. Security teams are overwhelmed by fragmented tooling, alert fatigue, and manual response processes. Clarion connects to the tools in your security stack — SIEM, EDR, WAF, IAM, cloud providers, on-chain monitors, and more — ingests their signals into a single place, correlates related events in real time, and uses AI agents to triage, investigate, and respond: autonomously where you allow it, with human approval where you don't. Slack is where your team meets Clarion. Agents deliver issue updates to your channels, ask for approval before running sensitive actions, and answer questions when you mention the app — so most of the day-to-day workflow happens without leaving Slack. ## How Clarion integrates with Slack ### Messages Clarion sends Clarion posts to Slack in these situations: * **Issue notifications** — when a monitor or a connected security tool raises something that needs attention, Clarion posts a summary to your configured notification channel. * **Approval requests** — when an agent wants to run a gated action (for example, suspending a user account), it posts an approval request with interactive **Approve** / **Reject** buttons. The agent stays paused until someone responds or the request times out. * **Clarification requests** — when an agent needs input to continue (a choice between options, or freeform input), it asks in the channel or via direct message. * **Agent updates during investigations** — agents can post progress updates, reply in threads, and send direct messages to linked workspace members (for example, paging the on-call engineer). * **Incident channels** — during incident response, agents can create a dedicated channel and invite the relevant responders. * **Weekly triage summary** — every Monday morning Clarion posts last week's triage numbers (issues opened, triage runs, resolved, false-positive rate) together with the issues still waiting on a human and any integrations that need fixing. It posts to your Agent notifications channel by default, and is on by default — both can be changed on **Integrations → Slack**. Agents can only post to channels and people that are explicitly configured in your workspace settings or mentioned in your workspace instructions and skills — they cannot pick arbitrary destinations. Clarion posting a critical issue notification and a tool-approval request in a Slack channel ### Messages Clarion responds to * **@-mentions** — mention the Clarion app in any channel it has been invited to (for example, `@Cantina Clarion what happened with issue #42?`) to start a conversation. The app acknowledges with a 👀 reaction, then an agent replies in a thread. Mention it again in the same thread to ask follow-ups. * **Button clicks** — **Approve** / **Reject** buttons on approval requests and option buttons on clarification requests are wired back to Clarion and resume the paused agent run. Mentioning the Clarion app in Slack and getting an agent reply in a thread Only members of the connected Clarion workspace can converse with the app: if someone else mentions it, the app replies with a short explanation instead of answering. *** ## Installing — where the "Add to Slack" button is The Clarion app for Slack is installed from inside the Clarion dashboard, so the install button becomes visible after you sign in: 1. Go to [clarion.cantina.xyz](https://clarion.cantina.xyz) and click **Log in** in the top-right corner — or **Get started** to create an account. 2. Once you're in your workspace, open **Integrations** in the sidebar. 3. Select **Slack** in the integrations catalog. 4. Click **Install Slack App** — this is the app's "Add to Slack" button. A new tab opens to Slack's standard authorization screen. 5. Check that the correct Slack workspace is selected in the top-right of Slack's page, review the requested permissions, and click **Allow**. 6. Slack confirms the installation and redirects you back to Clarion. Return to **Integrations → Slack** — the integration now shows **Installed app** along with your Slack workspace's name. The bot token is captured automatically from Slack during installation; there are no keys to copy or paste. **Estimated time:** about 5 minutes. You need access to a Clarion workspace with permission to manage integrations, and permission to install apps in your Slack workspace — some Slack workspaces require admin approval for new apps. ## After installing — first steps 1. **Choose a default notification channel.** On **Integrations → Slack**, the **Default notification channel** section appears once the app is installed. Type to search your channels, pick the one where Clarion should post notifications and approval requests by default — or click **Create channel** to make a fresh one such as `#clarion-alerts` — then click **Save**. Saving points agents at that channel for routine notifications and routes investigation approvals there; both can be changed later in your workspace settings. 2. **Give the channel list a moment.** Slack has no channel-search API, so Clarion keeps its own searchable copy of your channel list and syncs it in the background. Right after installing, a large Slack workspace can take a few minutes to finish; the picker shows the progress and how recently it synced. New channels and renames arrive within seconds after that. 3. **Using a private channel?** Invite the app by mentioning it in that channel — it becomes searchable straight away. Click **Refresh** if you'd rather re-sync the whole list. 4. **Link your team members.** Approval requests and direct messages reach people through their Slack identity. Members whose Slack email matches their Clarion email are linked automatically; everyone else can set their Slack handle in their notification settings. See [Members](/learn/settings/members). 5. **Check the weekly summary.** The **Weekly triage summary** section on **Integrations → Slack** controls the Monday digest: switch it off to opt out, point it at a different channel than your Agent notifications channel, or press **Send summary now** to post last week's digest immediately and confirm it lands where you expect. 6. **Say hello.** Invite the app to a channel and mention it — `@Cantina Clarion summarize the open issues` — to confirm everything works. To learn more about how agents use notifications and approvals, see [Notifications](/learn/notifications/introduction). ## Permissions the app requests | Slack scope | Why Clarion needs it | | ------------------------------------------------------ | ------------------------------------------------------------------------- | | `chat:write`, `chat:write.public` | Post notifications, approval requests, and agent replies | | `app_mentions:read` | See when someone mentions the Clarion app so it can respond | | `channels:read`, `groups:read`, `im:read`, `mpim:read` | List channels and conversations so you can pick notification destinations | | `channels:history`, `groups:history` | Read messages in channels the app is a member of, for incident context | | `channels:join` | Join public channels it needs to post in | | `channels:manage`, `groups:write` | Create incident channels and invite responders | | `im:write` | Open direct messages with users, for example to page the on-call | | `reactions:write` | Acknowledge messages with emoji reactions | | `team:read` | Read your Slack workspace name to label the connection | | `users:read`, `users:read.email` | Match Clarion members to Slack users for approvals and direct messages | ## Privacy and data handling When you install the app, Clarion stores your Slack workspace ID and name and the bot access token (encrypted at rest). To operate, it also stores a searchable list of the channels the app can see (name, whether it is private or archived, and channel ID — never message content), the channels you configure for notifications, the mapping between Clarion workspace members and their Slack user IDs, and the Slack conversations the app takes part in — mentions of the app, its replies, and messages agents read for incident context — which are processed by Clarion's AI agents to generate responses. Cantina's privacy policy explains in full how third-party data is collected, managed, stored, and deleted: * **Privacy policy:** [cantina.security/privacy-policy](https://www.cantina.security/privacy-policy) * **Terms of use:** [cantina.security/terms-of-use](https://www.cantina.security/terms-of-use) * **Support:** [support@cantina.security](mailto:support@cantina.security) ## Reinstall or remove the app * **Reinstall** — if the connection breaks or Clarion requests new permissions, the button on **Integrations → Slack** reads **Reinstall Slack App**; click it to run the authorization flow again. * **Remove** — uninstall Clarion from your Slack workspace's app management page (**Settings & administration → Manage apps** in Slack). This revokes the bot token and stops all Clarion messages to that workspace. # Splunk Source: https://docs.clarion.cantina.xyz/integrations/splunk Connect Splunk to Clarion so agents can forward an issue's details and original payload to your Splunk HTTP Event Collector (HEC) during triage. This guide walks you through connecting Splunk to Clarion using the **HTTP Event Collector (HEC)**. Once connected, Clarion agents can forward the issue they are triaging — its details plus the original payload Clarion ingested — to Splunk as an event, so your issues and investigations land in your SIEM alongside the rest of your data. **Estimated time:** 5 minutes. You will need access to **Splunk → Settings → Data Inputs → HTTP Event Collector** and the ability to create a token. ## Prerequisites * A **Splunk** deployment (Splunk Cloud or Splunk Enterprise) with the **HTTP Event Collector** enabled * Permission to create an **HEC token** * Your **HEC endpoint URL**, including the port (Splunk Cloud and most self-hosted deployments use `8088`) * The HEC endpoint must be reachable from Clarion's servers * A **Clarion workspace** with the Splunk integration page open *** ## Step 1 — Create an HEC token in Splunk 1. Sign in to **Splunk**. 2. Go to **Settings → Data Inputs → HTTP Event Collector**. 3. Confirm the collector is enabled under **Global Settings** (toggle **All Tokens** to **Enabled**). Note the **HTTP Port Number** (default `8088`). 4. Click **New Token**. 5. Give the token a name (for example, `Clarion Integration`) and complete the wizard. You can optionally set a default **index**, **source**, and **sourcetype**. 6. Copy the generated **token value**. Treat the HEC token like a password. Anyone with the token and endpoint can send events into your Splunk indexes. *** ## Step 2 — Find your HEC URL The HEC endpoint depends on your Splunk deployment. Your stack's **web URL is not** the HEC endpoint. | Deployment | HEC URL | Port | | --------------------------------- | --------------------------------------------- | ------------- | | **Splunk Cloud (production)** | `https://http-inputs-.splunkcloud.com` | 443 (default) | | **Splunk Cloud on GCP/Azure** | `https://http-inputs..splunkcloud.com` | 443 (default) | | **Splunk Cloud free trial** | `https://.splunkcloud.com` | 8088 | | **Self-hosted Splunk Enterprise** | `https://` | 8088 | `` is the identifier in your Splunk Cloud URL (e.g. `prd-p-abc12` in `prd-p-abc12.splunkcloud.com`). Note the required `http-inputs-` prefix for production Cloud stacks. Splunk Cloud **free-trial** stacks (and many on-prem deployments) present a **self-signed certificate**. For those, enable **Allow self-signed certificate** on the configuration form (see Step 3). Production Cloud stacks have valid certificates — leave it off. ## Step 3 — Enter credentials in Clarion 1. In Clarion, open **Integrations** and find **Splunk** under **Security & Monitoring**. 2. Enter your **HEC URL** from the table above. The `https://` scheme is optional (Clarion adds it), and you don't need the `/services/collector` path — Clarion appends it. Include `:8088` only for trial/self-hosted stacks. 3. Paste the **HEC token** from Step 1. 4. Optionally set a default **index**, **source**, and **sourcetype**. Leave these blank to use the defaults configured on the token. 5. If your stack serves a self-signed cert (trial / on-prem), enable **Allow self-signed certificate**. 6. Click **Connect**. Clarion validates the endpoint and token by sending a single test event before saving. If the endpoint is unreachable or the token is rejected, you'll see a clear error and nothing is persisted. *** ## Step 4 — Verify events reached Splunk Because **Connect** sends one test event, you can confirm data is landing right away. 1. In Splunk, open **Search & Reporting**. 2. Search the last 15 minutes for the test event: ```spl theme={null} index=* "Clarion Splunk HEC connection test" ``` If you set a default **index** on the integration, scope to it (e.g. `index=security ...`). Otherwise events land in the index bound to your HEC token — use `index=*` if you're unsure which. 3. One matching event (with `forwarded_by=clarion`) confirms the endpoint, token, and index are all working. To verify **agent-forwarded issues** later, search for the events Clarion sends during triage: ```spl theme={null} index=* forwarded_by=clarion ``` Each event is JSON, so Splunk auto-extracts fields you can filter and report on: | Field | Example | Meaning | | -------------------- | ------------------------------------------ | -------------------------------------- | | `forwarded_by` | `clarion` | Marks events Clarion sent | | `subject_kind` | `issue` | What was forwarded | | `subject.reference` | `ISS-1423` | Clarion issue reference | | `subject.severity` | `high` | Severity at forward time | | `subject.url` | `https://app.clarion.com//issues/1423` | Link back to Clarion | | `triage_summary` | `Confirmed benign…` | The agent's note, when provided | | `original_payload.*` | — | The untouched payload Clarion ingested | To find one specific issue, search by its reference — for example `index=* "ISS-1423"`. If you set a **sourcetype** (e.g. `clarion:issue`), `sourcetype="clarion:issue"` also scopes to Clarion's events. *** ## What agents can do Once connected, agents on this workspace gain access to the `/splunk` action. When an agent uses it during triage, Clarion forwards a single event to your HEC endpoint containing: * **Issue details** — number, title, description, severity, status, source, disposition, and a link back to the issue in Clarion * **The original payload** — the untouched event Clarion ingested for the issue * **The agent's triage summary** — an optional note the agent attaches describing its findings The agent can override the destination **index**, **source**, or **sourcetype** per event; otherwise the defaults you configured are used. The event is sent to your collector's `/services/collector/event` endpoint. To make an agent forward issues, add the **Splunk** action to a skill the agent runs (for example, a skill that forwards every confirmed threat to your SIEM). *** ## Disconnect To remove the integration: 1. In Clarion, open **Integrations → Splunk**. 2. Click **Disconnect**. This deletes the stored HEC URL and token. Agents on this workspace will no longer see the `/splunk` action, and any saved skills that reference it will surface the integration as missing until you reconnect. *** ## Troubleshooting ### "Splunk rejected the HEC token" The token is disabled or incorrect. In **Settings → Data Inputs → HTTP Event Collector**, confirm the token is **Enabled**, that **All Tokens** is enabled under **Global Settings**, and that you copied the full token value. ### "Splunk returned 404 — that URL isn't an HEC collector" You're pointing at the wrong host — most often the stack's **web UI** instead of HEC. Use the HEC URL from the table in Step 2 (for production Splunk Cloud, the `https://http-inputs-.splunkcloud.com` form), and confirm HEC is enabled (**Global Settings → All Tokens → Enabled**). Clarion appends `/services/collector/event`, so enter only the base URL. ### "Self-signed certificate" / TLS errors Your stack presents a certificate Clarion doesn't trust — common on Splunk Cloud **free-trial** stacks and on-prem deployments. Enable **Allow self-signed certificate** on the configuration form. Leave it off for production Cloud stacks (which have valid certificates). ### "Failed to reach the Splunk HEC endpoint" The endpoint isn't reachable from Clarion's servers. If your collector is on a private network, expose it (or its HEC port) so Clarion can deliver events, then reconnect. # Status Page Source: https://docs.clarion.cantina.xyz/integrations/status-page Crawl a third-party status page and raise an issue when your vendors publish an incident. Your dependencies publish incidents on status pages nobody watches at 3am. This integration crawls them for you and turns each newly published incident into a Clarion issue — so a vendor outage reaches your queue as fast as one of your own alerts. **Estimated time:** 2 minutes per page. You need only the status page URL. ## Prerequisites * The public URL of a status page you want watched * The page must be an **Atlassian Statuspage** or an **Instatus** page ## Connect 1. In Clarion, open **Integrations** and find **Status Page**. 2. Click **Connect** — the integration activates immediately; there is no credential. 3. Add a monitor per page, pasting its URL. Clarion detects the provider and resolves the machine-readable source automatically: the `incidents.json` v2 API for Atlassian Statuspage, or the validated RSS/Atom feed for Instatus (which often lives on a different host). Set a **default severity** per monitor so a page whose incidents always matter to you can be escalated harder than one that rarely does. ## How the crawl works Each page is polled every two minutes. Clarion tracks the newest incident it has seen plus a set of recent incident ids, which is what makes new-incident detection reliable across both providers. The first poll **seeds** the page rather than importing its entire history — you get the next incident, not a backlog. A page that is quiet on its first poll is still marked as seeded, so the first real incident afterwards is queued rather than being mistaken for backlog. Per-monitor sync health is tracked like every other poller, so a page that moves or breaks surfaces as an integration health issue rather than going quietly silent. ## Where it helps Status-page incidents give an agent the cheapest possible answer to "is this us?". A spike in errors that coincides with your CDN publishing a degradation is a very different investigation from the same spike with every vendor green. ## Disconnect Click **Disconnect** on the integration page, or disable an individual monitor to stop watching one page. # Tailscale Source: https://docs.clarion.cantina.xyz/integrations/tailscale Connect Tailscale to Clarion to receive network and identity events — device approvals, key expiry, policy changes, and user lifecycle — as issues. This guide explains how to connect Tailscale to Clarion. Once configured, Clarion receives Tailscale webhook events and opens issues that agents can triage and investigate. **Estimated time:** 5-10 minutes. You will need **Tailscale Owner or Admin** access and access to the Clarion workspace where you want to connect Tailscale. ## Prerequisites * A Tailscale account with Owner or Admin role * Access to the Clarion workspace where you want to configure the integration ## Add a Tailscale monitor in Clarion The Tailscale webhook is configured as a **monitor**, so each one has its own URL and signing secret. 1. Open Clarion and go to **Integrations** → **Tailscale**. 2. In the **Monitors** section, click **Add monitor** and choose **Tailscale**. 3. Copy the generated **Webhook URL** and **Secret** shown on the monitor. You will paste these into Tailscale in the next step. ## Configure the webhook in Tailscale 1. Sign in to the [Tailscale admin console](https://login.tailscale.com/admin). 2. Navigate to **Settings** → **Webhooks**. 3. Click **Add endpoint**. 4. Paste the **Webhook URL** from Clarion into the **Endpoint URL** field. 5. Paste the **Secret** from Clarion into the **Secret** field. 6. Select the event types you want to receive. Clarion handles all Tailscale event types: * **Device events**: `nodeNeedsApproval`, `nodeApproved`, `nodeKeyExpiringSoon`, `nodeKeyExpiryDisabled`, `nodeKeyExpiryEnabled`, `nodeNotSeen` * **Policy events**: `policyUpdate` * **User events**: `userNeedsApproval`, `userApproved`, `userSuspended`, `userRoleUpdated`, `userCreated`, `userDeleted` 7. Click **Save**. 8. Use **Send test event** to verify the connection. Clarion will create a test issue to confirm delivery. ## Enable agent tools (API access) Beyond receiving events, you can let Clarion agents act on your tailnet — investigating devices, users, keys, DNS, and ACL policy, and (with approval) running remediation such as deauthorizing a device or suspending a user. This uses a Tailscale **OAuth client**; the client secret is stored encrypted and is never exposed to agents. 1. Sign in to the [Tailscale admin console](https://login.tailscale.com/admin). 2. Go to **Settings** → **OAuth clients** and click **Generate OAuth client**. 3. Grant the client the scopes for the capabilities you want. The minimal set for the full tool suite is: * `devices:core` — list/get devices, authorize/deauthorize, expire, set tags * `devices:routes:read` — list device subnet routes * `auth_keys:read` — list auth keys * `users` — list/get users, suspend/restore * `dns:read` — read DNS nameservers, preferences, and search paths * `policy_file:read` — read the ACL policy file * `account_settings:read` — read tailnet contacts Grant only the scopes you need — for read-only investigation, use the `:read` scopes and omit `devices:core` and `users`. 4. Copy the **Client ID** and **Client secret** (the secret is shown only once). 5. In Clarion, go to **Integrations** → **Tailscale** → **API access (agent tools)**, paste the Client ID and secret, and click **Save**. Leave **Tailnet** blank to use the OAuth client's default tailnet. The five write actions — authorize/deauthorize a device, set device tags, expire a device, and suspend/restore a user — require explicit human approval before an agent can run them. You can review and adjust approval requirements per tool under **Settings** → **Tools**. ## How severity is mapped | Event | Severity | | -------------------------------------------------------------------------------- | -------- | | `nodeNotSeen`, `userSuspended`, `nodePolicyViolation` | Critical | | `nodeNeedsApproval`, `userNeedsApproval` | High | | `policyUpdate`, `userRoleUpdated`, `nodeKeyExpiringSoon`, `nodeKeyExpiryEnabled` | Medium | | All other events | Low | ## Verifying the connection After saving the webhook in Tailscale, send a test event from the Tailscale admin console. A test issue will appear in Clarion under **Issues**, confirming the integration is working. # Telegram Source: https://docs.clarion.cantina.xyz/integrations/telegram Deliver Clarion approvals, clarifications, and alerts to a Telegram chat through your own bot. Telegram is a [notification channel](/learn/notifications/introduction): agents deliver approval requests, clarification questions, and escalations into a Telegram chat, and replies resume the run. **Estimated time:** 5 minutes. You will need the ability to create a bot with Telegram's **@BotFather**. ## Prerequisites * A **Telegram** account * A group or channel you want Clarion to post into ## Step 1 — Create a bot 1. In Telegram, open a chat with **@BotFather**. 2. Send `/newbot` and follow the prompts to name your bot. 3. BotFather replies with a **bot token** in the form `123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11`. The bot token is a credential. Anyone holding it can post as your bot. Store it securely and rotate it from BotFather if it leaks. ## Step 2 — Add the bot to your chat 1. Add the bot to the group or channel you want notifications in. 2. Grant it permission to post messages. 3. Note the **chat ID** for that conversation — group and channel IDs are negative numbers, e.g. `-1001234567890`. ## Step 3 — Connect in Clarion 1. In Clarion, open **Integrations** and find **Telegram**. 2. Paste the **bot token** and click **Connect**. 3. Under **Add Channel**, give the destination a **name** (e.g. `Alerts`) and paste its **chat ID**. You can add several channels — each becomes selectable as a [notification destination](/learn/notifications/introduction). ## What agents can do | Tool | What it does | | --------------- | ------------------------------------------------------- | | `send_message` | Post a message to a configured Telegram channel | | `list_channels` | List the Telegram channels configured on this workspace | ## Rotate the token Open **Integrations → Telegram** and enter a **New bot token**. Existing channels keep working. ## Disconnect Click **Disconnect** on the integration page. Configured channels are removed, and any notification destination pointing at Telegram stops delivering. # Tenderly Source: https://docs.clarion.cantina.xyz/integrations/tenderly Connect Tenderly to Clarion to receive smart contract monitoring alerts for AI-powered triage and response. This guide walks you through connecting your Tenderly account to Clarion. By the end, Clarion will receive Tenderly alerts via webhooks and have API access to your Tenderly project for monitoring smart contracts and transactions. *** ## Prerequisites * A Tenderly account with access to the project you want to monitor. * Access to the Clarion dashboard. *** ## Step 1 — Generate a Tenderly Access Token 1. Open Tenderly and go to **Settings**. 2. Under settings, find the **Integrations** section and click **Generate Access Token**. 3. Give the token a descriptive name (e.g. `Clarion`). 4. Copy the access token immediately — it is only displayed once. Store this token somewhere safe temporarily. You'll need it in the next step and won't be able to view it again. *** ## Step 2 — Connect Tenderly to Clarion 1. In Clarion, navigate to **Integrations** and find the **Tenderly** integration. 2. Paste the access token you copied in Step 1 and click **Connect**. 3. Once connected, click **Configure** on the integration page. *** ## Step 3 — Create a Monitor in Clarion 1. Switch to the **Monitor** tab and click **Add New Monitor**. 2. Go back to Tenderly **Settings** and copy your **Account Slug** and **Project Slug**. 3. Paste both slugs into the corresponding fields in Clarion. 4. Leave the **Webhook Secret** field empty for now — you'll fill it in after setting up the webhook in Tenderly. 5. Click **Create Monitor**. Clarion will generate a webhook URL that you'll need in the next step. Copy the generated webhook URL — you'll use it to set up the destination in Tenderly. *** ## Step 4 — Set Up the Webhook Destination in Tenderly 1. In Tenderly, go to **Alerts** and switch to the **Destinations** tab. 2. Select **Webhook** as the type under **Add Destination**. 3. Paste the webhook URL generated by Clarion in Step 3. 4. Save the destination. Once created, Tenderly will display a **Signing Secret** for this webhook. 5. Copy the **Signing Secret**. *** ## Step 5 — Add the Signing Secret to Clarion 1. Go back to Clarion and open the monitor you created in Step 3. 2. Click on the monitor. 3. Paste the **Signing Secret** from Tenderly into the **Webhook Signing Secret** field. 4. Save the monitor. Your Tenderly monitor is now fully configured and secured with the signing secret. *** ## Step 6 — Attach the Webhook to Your Alerts 1. In Tenderly, go to **Alerts** and review each alert rule that is defined. 2. For every alert you want Clarion to receive, edit the rule and ensure the Clarion webhook is set as a destination. *** You're done! Clarion is now connected to Tenderly and will receive alerts for all configured monitors. # Threat Intel Source: https://docs.clarion.cantina.xyz/integrations/threat-intel Bring vulnerability advisories, supply chain threats, and security feeds into Clarion for AI-powered triage and response. The **Threat Intel** integration brings external security intelligence into Clarion for AI-powered triage. It is a built-in, auto-connected integration — there is no third-party account to link. Pick the monitor that matches how your intelligence is delivered; you can add both. ## Choose a monitor Receive structured vulnerability advisories and supply chain threat payloads from a scanner or threat-intel service via a signed inbound webhook. Real time. Subscribe to a published RSS or Atom feed — vendor security blogs, CERT/CSIRT bulletins, advisory feeds. Clarion crawls it and opens an issue for each new item. ## Which one do I need? | | [Threat Intel webhook](/integrations/threat-intel/webhook) | [RSS Feed](/integrations/threat-intel/rss-feed) | | ------------- | ---------------------------------------------------------- | -------------------------------------------------------- | | **Direction** | Your sender pushes to Clarion | Clarion pulls from a URL | | **Input** | Signed JSON (`vulnerability` / `threat`) | RSS 0.9/1.0/2.0 or Atom feed | | **Latency** | Real time | Crawled every 6 hours (or on demand) | | **Best for** | Scanners, vuln / supply-chain services | Security blogs, CERT bulletins, advisory & release feeds | Threat Intel is auto-connected, so it already appears on the Integrations page — you only need to add the monitor you want. Both monitor types are managed from the same **Threat Intel** integration. Clarion ships a built-in **Threat Intelligence** agent that triages advisories and feed items, correlating them to your environment. Assign it to either monitor (or both) to automate the first pass. # RSS Feed Source: https://docs.clarion.cantina.xyz/integrations/threat-intel/rss-feed Subscribe Clarion to an RSS or Atom feed — security blogs, CERT/CSIRT bulletins, advisory feeds — and open an issue for each newly-published item. The **RSS Feed** monitor subscribes Clarion to a published **RSS or Atom feed** — security advisory feeds, vendor security blogs, CERT/CSIRT bulletins, or release/changelog feeds. Clarion crawls the feed and opens an issue for each newly-published item, then triages it with AI agents. **Estimated time:** 5 minutes. You will need a **Clarion workspace** and a public `https://` feed URL. *** ## Step 1 — Create the monitor 1. In Clarion, go to **Settings > Integrations** 2. Find **Threat Intel** and click **Add Monitor** 3. Pick the **RSS Feed** monitor type 4. Enter the **Feed URL** — a public `https://` RSS or Atom feed 5. Pick a **default severity** — RSS items carry no severity of their own, so every issue from this feed uses this value 6. Click **Create** The feed must be reachable over public `https://`. For safety, Clarion refuses internal, private, or cloud-metadata addresses and re-checks every redirect hop. *** ## How crawling works * Clarion crawls the feed **every 6 hours** automatically. You can also click **Crawl now** on the monitor's Configure page to fetch immediately. * Supports **RSS 0.9 / 1.0 / 2.0** and **Atom**. * The **first crawl** seeds the monitor with the feed's current contents and does **not** open issues for the existing backlog. After that, each newly-published item becomes one issue. * Items are de-duplicated by their feed GUID, so re-seeing the same entry across crawls never creates a second issue. *** ## Opening issues for backlog items To open issues for entries that already existed when you connected the feed: 1. Open the monitor's Configure page and click **Load latest** 2. Tick the items you want 3. Click **Create alerts for selected** A single crawl opens at most 50 new issues, so a churning feed can't flood your workspace — the newest items are kept. Feed content is treated as untrusted: secret-shaped tokens are redacted before anything is stored or displayed. *** ## What happens next Once configured, Clarion will automatically: * Crawl your feed every 6 hours (and whenever you click **Crawl now**) * Open an issue for each newly-published item, at the feed's default severity * Triage incoming issues with AI agents and surface actionable insights Clarion ships a built-in **Threat Intelligence** agent that triages feed items and correlates them to your environment. Assign it to this monitor to automate the first pass. # Threat Intel webhook Source: https://docs.clarion.cantina.xyz/integrations/threat-intel/webhook Send structured vulnerability advisories and supply chain threats to Clarion via a signed webhook for AI-powered triage. The **Threat Intel webhook** monitor accepts structured JSON payloads describing a vulnerability or a supply chain threat — for example a scanner posting a CVE finding or a malicious-package detection. Clarion turns each into an issue and triages it with AI agents. **Estimated time:** 5 minutes. You will need a **Clarion workspace** and a sender that can sign requests with HMAC-SHA256. *** ## Step 1 — Create the monitor 1. In Clarion, go to **Settings > Integrations** 2. Find **Threat Intel** and click **Add Monitor** 3. Pick the **Threat Intel** monitor type and give it a name 4. Click **Create** Clarion generates a **webhook URL** and a **signing secret**. Copy both right away. Copy the signing secret immediately — it is only displayed once. You can regenerate it later from the monitor's Configure page, but you cannot view the current value. *** ## Step 2 — Send signed events Point your sender at the webhook URL with an HTTP `POST`. The body must be a JSON **object** up to **100 KB**, signed with HMAC-SHA256. * Compute `HMAC-SHA256(raw_request_body, signing_secret)` and send the **hex digest** in the `x-signature` header. * The payload must contain a `vulnerability` object, a `threat` object, or both. Either one alone is enough. **`vulnerability` fields** | Field | Required | Notes | | ---------------- | -------- | ---------------------------------------------------------------- | | `package` | Yes | Affected package name | | `currentVersion` | Yes | Version in use | | `fixedVersion` | No | Version that resolves the issue | | `advisory` | No | Advisory ID (e.g. a CVE or GHSA) — prefixed onto the issue title | | `severity` | No | Drives the issue's severity (see mapping below) | **`threat` fields** | Field | Required | Notes | | ----------------- | -------- | ----------------------------------------------- | | `type` | Yes | Threat type (e.g. `malware`, `typosquat`) | | `package` | Yes | Affected package name | | `detectedVersion` | No | Version observed | | `advisory` | No | Advisory reference | | `severity` | No | Drives the issue's severity (see mapping below) | | `indicator` | No | IOC / indicator string | Any extra fields you include are preserved on the issue for the triage agent to reason about — nothing is dropped. ```bash theme={null} SECRET="" BODY='{"vulnerability":{"package":"lodash","currentVersion":"4.17.20","fixedVersion":"4.17.21","advisory":"CVE-2021-23337","severity":"high"}}' SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$SECRET" | sed 's/^.* //') curl -X POST "https:///api/webhooks/threat-intel/" \ -H "Content-Type: application/json" \ -H "x-signature: $SIG" \ -d "$BODY" ``` A successful request is accepted asynchronously (HTTP `202`); Clarion validates the payload and opens the issue on its worker. The issue title is derived from the payload — for example `CVE-2021-23337: Vulnerability in lodash@4.17.20` or `Supply chain threat: typosquat (left-pad@1.0.0)`. *** ## Severity mapping The issue severity comes from the payload's `severity` string (the `vulnerability` value takes precedence over the `threat` value): | Payload `severity` | Clarion severity | | -------------------------------------- | ---------------- | | `critical` | Critical | | `high`, `error` | High | | `medium`, `moderate`, `warning` | Medium | | `low`, `info`, `informational`, `note` | Low | | *(missing or unrecognized)* | High | *** ## What happens next Once configured, Clarion will automatically: * Accept signed payloads at the monitor's webhook URL * Open an issue for each vulnerability or threat, with the severity mapped above * Triage incoming issues with AI agents and surface actionable insights Clarion ships a built-in **Threat Intelligence** agent that triages advisories and correlates them to your environment. Assign it to this monitor to automate the first pass. # Twilio (SMS & phone) Source: https://docs.clarion.cantina.xyz/integrations/twilio Reach members by SMS or a voice call for high-urgency events. Twilio powers Clarion's **SMS** and **phone call** channels. Both are for urgency rather than interaction: an SMS or a call gets a human's attention, and the conversation continues in Clarion, Slack, or Teams. Twilio is configured by your Clarion platform administrator, not per workspace. If the integration page says Twilio is not yet configured, contact your administrator. ## Prerequisites * Twilio enabled for your Clarion instance * Workspace members with a **verified phone number** on their profile ## Connect 1. In Clarion, open **Integrations** and find **Phone**. 2. Click **Connect**. 3. Send a **test SMS** or place a **test call** to a member to confirm delivery. Members set their own phone number in their profile — see [Members](/learn/settings/members). A member without a number cannot be reached by SMS or call and will not appear in the picker. ## As a notification destination SMS can be selected as a [notification destination](/learn/notifications/introduction), targeting one or more workspace members. SMS is **notification only**. It carries no interactive approval buttons, so an approval request delivered by SMS still has to be answered in Clarion, Slack, or Teams. Pair SMS with an interactive channel rather than using it alone. ## What agents can do | Tool | What it does | | ------------------------ | ---------------------------------------- | | `send_sms_to_member` | Text a workspace member | | `make_call_to_member` | Place a voice call to a workspace member | | `list_workspace_members` | List members reachable by phone | Both send actions are scoped to workspace members — an agent cannot dial an arbitrary number. ## Disconnect Click **Disconnect** on the integration page. SMS destinations stop delivering and the phone tools disappear from agent skills. # Vanta Source: https://docs.clarion.cantina.xyz/integrations/vanta Connect a Manage Vanta Application so Clarion agents can read live compliance and vendor-risk data and perform separately approved writes. Clarion's native Vanta integration uses the [Manage Vanta REST API](https://developer.vanta.com/reference/manage-vanta/overview). It queries your Vanta tenant live; it does not copy Vanta vulnerabilities, assets, issues, tests, controls, frameworks, discovered vendors, managed vendors, or documents into Clarion. You need Vanta administrator access to create a **Manage Vanta Application**. This connection is for automating your own Vanta tenant, not the Vanta public marketplace OAuth flow. ## Create a Manage Vanta Application 1. In Vanta, create a Manage Vanta Application for Clarion. 2. Set the application's **Access level** to **Read and write**. Clarion requests `vanta-api.all:read`, `vanta-api.all:write`, and `vanta-api.documents:upload` during token exchange; Vanta does not ask you to select those scopes individually. See Vanta's [document upload guide](https://developer.vanta.com/docs/guides/upload-a-document). 3. Copy the client ID and client secret. Clarion requests all three scopes when it validates or refreshes a token. Vanta remains the authority that grants or rejects those scopes. Vanta issues one one-hour token per application and revokes the prior token when another is issued, so use a dedicated Manage Vanta Application for each Clarion workspace and do not reuse it in another token-minting service. ## Connect Vanta in Clarion 1. Open **Integrations → Compliance & GRC → Vanta**. 2. Enter the client ID and client secret. 3. Click **Connect Vanta**. Clarion validates the credentials server-side before completing setup. The client secret and cached access token are encrypted in Clarion and are never returned to the browser, put in schedule prompts, or sent to agent sandboxes. Use **Verify connection** to run a bounded live health check. ## Agent tools Connected chats, agents, and scheduled agent runs can read bounded, cursor-paginated pages of Vanta vulnerabilities, vulnerability remediations, tests, documents, controls, frameworks, issues, discovered vendors, discovered-vendor accounts, and managed vendors. They can also inspect managed-vendor risk attributes, assessments, security reviews, findings, and document metadata. Vendor-document tools do not download or return document content or document URLs. Detail tools accept exact opaque Vanta IDs. Evidence delivery has two separate tools: * `upload_document_evidence` uploads a trusted Clarion knowledge artifact or server-built issue export to an existing Vanta document as a draft. * `submit_document` submits that document and makes the evidence auditor-visible. Both are external writes and require human approval in Clarion, even though the Vanta application has write scopes. Upload never submits implicitly, and a submission requires its own approval. Agents cannot upload from arbitrary URLs, host filesystem paths, or inline base64 data. `add_discovered_vendor_to_managed` is another separate external write. It converts one exact discovered vendor into a managed Vanta vendor and always requires human approval. Reviewing or recommending a vendor never invokes it implicitly. ## New Vendor Risk Reviewer The built-in **New Vendor Risk Reviewer** handles operational vendor-risk review. It reads Vanta's live `NEEDS_REVIEW` discovered-vendor queue, gathers bounded account and device usage context, checks for existing managed-vendor duplicates, and includes available risk attributes, assessments, security reviews, findings, and document metadata. It returns an evidence-backed digest and prioritized investigation queue. For each discovery, the reviewer presents account coverage and pagination completeness in a compact summary table, then lists every distinct associated user's display name and email address in a per-vendor contact table. A separate device table maps each computer display name to the owner's name and email when Vanta provides them; computers without an owner are marked accordingly. The reviewer follows account cursors to completion and does not silently replace the full result with a first-page sample. These contacts show who is associated with the discovery so reviewers can follow up, but they are not treated as confirmed vendor business owners. The reviewer identifies contacts only and never messages them automatically. This differs from the **SOC 2 Evidence Collector**, which samples Clarion vulnerability issues and delivers approved draft compliance evidence. The vendor reviewer does not collect SOC 2 evidence and does not synchronize Vanta vendors into Clarion. The reviewer includes a user-editable weekly schedule for Monday at 08:00 UTC. The schedule is pinned to the installed agent, operates live against Vanta, and is strictly read-only: it never converts, ignores, or rejects vendors and never creates tickets or other external records. Deactivating the agent prevents its scheduled runs. Adding a discovery to managed status is a separate, approval-required action. The current [Manage Vanta OpenAPI specification](https://developer.vanta.com/reference/manage-vanta.json) does not expose mutations for ignoring or rejecting discovered vendors, so those recommendations must be completed manually in Vanta. Richer risk data can also be absent until a discovery becomes a managed vendor; missing Vanta risk data is not proof that a vendor is safe. The reusable **Review newly discovered Vanta vendors** skill is available independently in Clarion's skill catalog, so it can be attached to custom agents as well as the built-in reviewer. ## SOC 2 Evidence Collector The built-in **SOC 2 Evidence Collector** runs monthly on the first day of the month at 09:00 UTC. Its schedule is pinned to the created agent and remains editable in Clarion. Deactivating the agent prevents scheduled execution. The agent samples Clarion vulnerability issues, verifies linked remediation pull requests with the existing GitHub tools, lists Vanta documents live, and asks for clarification if several documents could be the target. An approved upload creates draft evidence. The monthly schedule never submits the document automatically. If Vanta is disconnected before a run, its tools are omitted and either built-in agent reports the missing integration instead of receiving credentials or repeatedly calling a broken endpoint. ## Disconnect or rotate credentials Use **Update credentials** after rotating the Vanta client secret. Clarion validates the replacement before persisting it. Use **Disconnect** to delete the workspace's Vanta integration and encrypted credentials; Vanta tools then disappear from new agent runs. ## Troubleshooting * **Credentials rejected:** verify the client ID/secret and that the application uses the client-credentials grant. * **Scope or operation denied:** grant all three required scopes to the Manage Vanta Application, then update the credentials in Clarion so they are validated again. * **Rate limited:** wait and retry. Clarion reuses a valid cached token instead of minting one per tool call. * **Document is ambiguous:** select or name one intended document; Clarion does not assume tenant-specific document IDs. This release does not add Vanta MCP, webhooks, automatic polling, bulk synchronization, or public marketplace OAuth. # Vercel Source: https://docs.clarion.cantina.xyz/integrations/vercel Monitor deployments, runtime errors, firewall attacks, and domain health — and sweep for unintended public exposure. Connecting Vercel gives Clarion visibility into your deployments and the edge in front of them, and feeds two agents: **Vercel Platform** for operational and security events, and the **Exposure Agent** for finding sites that are public when they shouldn't be. **Estimated time:** 3 minutes. You will need permission to install an integration on your Vercel team. ## Prerequisites * A **Vercel** team where you can install integrations * The Vercel integration configured for your Clarion instance (contact your administrator if the page says otherwise) ## Connect 1. In Clarion, open **Integrations** and find **Vercel**. 2. Click **Install** — you are taken to Vercel to authorize the integration. 3. Choose the team and the projects Clarion may see. 4. Return to Clarion; the integration appears as connected. ## What Clarion ingests Events that feed the **Vercel Platform** agent: * Deployment failures and their build output * Runtime errors * Firewall and attack-challenge activity * Domain and certificate health ## Project discovery into the Brain Clarion discovers your projects and deployments as assets, along with firewall configuration, log drains, and edge configs. Projects correlate with the repositories that build them and the services that observe them, so a deployment failure resolves to the code and the service behind it. ## What agents can do | Tool | What it returns | | ------------------------------------- | ----------------------------------------------------- | | `list_projects` / `get_project` | Project inventory and configuration | | `list_deployments` / `get_deployment` | Deployments and their state | | `get_deployment_events` | Build and runtime event stream for a deployment | | `list_domains` / `get_domain_config` | Domains and their DNS/certificate configuration | | `list_members` | Team membership | | `trigger_redeployment` | Re-deploy — used for production rollback and recovery | `trigger_redeployment` changes production. It is gated by your workspace's tool policy and asks for approval unless you have explicitly allowed it. ## Exposure sweeps The [Exposure Agent](/learn/agents/our-agents) uses this integration for its daily sweep: it enumerates hosts and probes each one's root over read-only HTTPS from the Clarion sandbox, then files an issue per site that is publicly reachable and shouldn't be. Verdicts are written back to the Brain, so a site you confirm as intentionally public stops re-reporting. Because the probe runs from the sandbox, that sweep requires the **Bash** tool category at *Protected* or above. ## Disconnect Click **Disconnect** in Clarion, then remove the Clarion integration from your Vercel team. # Wiz Source: https://docs.clarion.cantina.xyz/integrations/wiz Connect Wiz to Clarion to ingest prioritized cloud security Issues, sync your cloud inventory, and let agents investigate and comment back in Wiz. This guide walks you through connecting a Wiz tenant to Clarion. Once connected, Clarion ingests prioritized Wiz Issues over a webhook, syncs cloud inventory into the Brain, and lets agents investigate and write back in Wiz with human approval. **Estimated time:** 15–20 minutes. You need a **Wiz admin** who can create a Custom Integration (GraphQL API) service account, plus `integrations:manage` in the Clarion workspace. ## Prerequisites * A **Wiz admin** who can create a **Custom Integration (GraphQL API)** service account. Clarion cannot grant provider permissions. * The **GraphQL API endpoint** from Wiz **Tenant settings** * A **Clarion workspace** where you have `integrations:manage` *** ## Step 1 — Create the service account 1. In Wiz, create a service account of type **Custom Integration (GraphQL API)**. 2. Scope it to only the Wiz projects Clarion should see. ### Required scope | Scope | Covers | | ---------- | ----------------------------------------------------------------------------------------------------------------------------- | | `read:all` | Issue ingestion and investigation, project and inventory context, vulnerability findings, SBOM, Graph Entity, and CloudEvents | ### Optional writeback scopes Grant each optional scope only if you want the matching Clarion agent tool: | Scope | Enables | | ----------------------------- | ------------------------------------------------------------- | | `write:issue_comments` | Add comments to regular Wiz Issues | | `write:issue_status` | Mark in progress, reopen, and reject regular Issues | | `write:threat_issue_comments` | Add comments to Threat Detection Issues | | `write:threat_issue_status` | Mark in progress, reopen, and resolve Threat Detection Issues | *** ## Step 2 — Enter credentials in Clarion 1. Open Clarion and go to **Integrations → Wiz**. 2. Enter the **API URL** — the GraphQL endpoint from Tenant settings, for example `https://api.us1.app.wiz.io/graphql`. Clarion accepts commercial hosts only; government GraphQL hosts are unsupported. 3. Choose the **Token URL** that matches your tenant: | Provider | Token URL | | ------------------------ | ------------------------------------- | | Amazon Cognito (default) | `https://auth.app.wiz.io/oauth/token` | | Auth0 | `https://auth.wiz.io/oauth/token` | 4. Enter the **Client ID** and **Client Secret**. 5. Click **Save**. Save validates that Wiz accepts the OAuth client credentials and that the fixed `issuesV2` access check passes. Wiz does not return a trustworthy granted-scope list, so Clarion does not verify the full read surface or the optional write scopes. A missing write permission surfaces when the tool runs. *** ## Step 3 — Add the Issues monitor The Issues monitor is available only after the service account validates. 1. On **Integrations → Wiz**, create the Issues monitor. Clarion generates the webhook URL and a bearer token. Copy the bearer token immediately — Clarion shows it once. 2. In Wiz, create a custom **Webhook** integration pointed at that URL. Use token auth so Wiz sends `Authorization: Bearer `. 3. Create an **Automation Rule** with **Issue** as the trigger source and that webhook as its action. Paste the body template from the Clarion page exactly (Clarion stores it as `wizIssuesWebhookTemplate`): ```json theme={null} { "schemaVersion": "wiz-issues/v2", "issue": { "id": "{{issue.id}}" } } ``` The payload is thin on purpose: Clarion stores the notification durably, then fetches the authoritative snapshot from Wiz by Issue ID. *** ## What happens next * A new active provider Issue creates one Clarion Issue. Later deliveries refresh the Wiz snapshot only and never change Clarion workflow status. * Connected triage agents pick up new Issues. * **Sync assets** pulls only the Wiz cloud inventory into the Brain and classifies it into compute, datastore, network, and identity. *** ## Agent tools Once connected, triage agents can use Wiz tools. Every Wiz write requires explicit human approval in Clarion. **Read tools:** Issue lookup and search, Issue evidence, project context, Graph Entity, CloudEvents search, vulnerability findings, SBOM artifact groups and component exposure, repositories, technologies, hosted technologies. **Write tools:** Issue comment, mark in progress, resolve, reject, reopen. *** ## Rotate the bearer token Rotate the token in Clarion, then replace it in the Wiz custom Webhook integration. Deliveries fail in between. *** ## Rotate the client secret Re-save the service account in Clarion with the new secret. Changing credentials invalidates the bound asset-inventory, SBOM, and vulnerability-finding sync state, so the next sync starts clean. *** ## Troubleshooting ### Save fails * Wrong GraphQL endpoint (a government host is rejected by design) * Wrong token URL for the tenant * Missing `read:all` ### Issues stop arriving * Token was rotated in Clarion but not in Wiz * The Automation Rule is disabled ### A write tool reports a missing permission The optional scope was never granted. Clarion never probes for it with a test mutation. # Zscaler Source: https://docs.clarion.cantina.xyz/integrations/zscaler Receive Zscaler Internet Access security and UEBA alerts as Clarion issues over a per-monitor webhook. Clarion receives **Zscaler Internet Access (ZIA)** Security and UEBA alerts over a webhook, turning each one into an issue for agent triage. **Estimated time:** 10 minutes. You will need admin access to the ZIA Admin Portal to configure a webhook destination. ## Prerequisites * A **Zscaler Internet Access** tenant * Admin rights to configure alert webhooks in the ZIA Admin Portal ## Step 1 — Create the monitor in Clarion 1. In Clarion, open **Integrations** and find **Zscaler**. 2. Click **Connect** and add a monitor. 3. Clarion generates a **webhook URL** and a **shared secret**, shown once. The secret is per monitor and stored encrypted. It authenticates the webhook — it travels in the request, never in the URL. Copy it when it is shown. ## Step 2 — Configure the webhook in Zscaler 1. In the **ZIA Admin Portal**, open the alert or webhook configuration for Security and UEBA alerts. 2. Add Clarion's webhook URL as the destination. 3. Configure the shared secret so Clarion can verify each delivery. 4. Send a test alert to confirm delivery. Clarion rejects deliveries that fail verification, so a misconfigured secret shows up immediately rather than silently dropping alerts. ## What Clarion ingests ZIA **Security** alerts (policy blocks, malware and threat detections, risky destinations) and **UEBA** alerts (anomalous user behaviour). Each becomes an issue with severity mapped from the Zscaler payload. ## Triaging Zscaler alerts Zscaler alerts route well to the identity and endpoint skill domains — a UEBA anomaly is usually best pursued through the user's identity provider and their device, both of which Clarion can reach if those integrations are connected. ## Disconnect Click **Disconnect** on the integration page, and remove the webhook destination from the ZIA Admin Portal. # Welcome to Clarion Source: https://docs.clarion.cantina.xyz/introduction One brain to orchestrate your entire security stack. [Clarion](https://clarion.cantina.xyz) is Cantina's agentic security orchestration platform that ingests signals from every security tool, correlates threats in real-time, and executes response playbooks autonomously. Your SOC team focuses on strategy while Clarion handles the noise. For a product overview, see the [Clarion platform page](https://www.cantina.security/platform). Reduce alert fatigue through intelligent deduplication and prioritization across all your security tools. Provide 24/7 instant threat response with AI-powered agents that act outside business hours. Capture team expertise in executable skills that persist when staff leave. ## Why Clarion? Security teams are overwhelmed by fragmented tooling, alert fatigue, and manual response processes. Clarion unifies your security operations into a single orchestration layer: * **Signal ingestion** — Consolidate signals from SIEM, EDR, WAF, SOAR, IAM, NDR, and more into one platform. * **Real-time correlation** — Automatically correlate threats across sources to surface what matters and eliminate false positives. * **Agentic response** — Execute response playbooks autonomously with AI agents that triage, escalate, and remediate. * **Proactive monitoring** — Monitor DNS records, HTTP endpoints, smart contracts, and infrastructure with configurable checks. * **Signal rules** — Define custom rules to automatically route, escalate, and act on security signals. # Getting started Source: https://docs.clarion.cantina.xyz/knowledge-base/getting-started Set up your Clarion workspace, create your first agent, and start triaging issues. This guide walks you through the essential steps to go from a fresh workspace to a live agent triaging real issues. ## 1. Create your workspace Sign in at [clarion.cantina.xyz](https://clarion.cantina.xyz). You may already have a workspace set up for you by the Cantina team. If not, you can create one yourself — all new workspaces require approval from the Cantina team before they go live. ## 2. Invite your team Open **Settings → Members** to invite teammates. Members receive notifications, review agent decisions, and approve sensitive actions when an agent asks.