Agents

​

What an agent is

An agent is a configured responder defined by:

• Monitors: The event sources it pays attention to.
• Skills: A skill is a reusable playbook that teaches the agent how to perform a specific class of tasks to a known standard, along with the tools available to investigate and remediate security issues.
• Tools: The actions it can execute, assigned through skills (Slack, DNS, Jira, AWS, and more).
• Notification preferences: How it requests human approval or clarification.

Start from a template, with pre-built agents for common SOC workflows like Smart Contract Security, Identity & Access, or DNS Infrastructure, or build one from scratch. For the product-level view of how agentic response works, see Agents on cantina.security.

​

What an agent does

• Triages issues: Produces a summary, report, recommendations, and risk assessment for every issue that matches its monitors.
• Digs in on escalations: Runs deeper analysis once an issue is escalated.
• Executes response: Calls tools to remediate (revoke a token, change a DNS record, post to Slack, file a Jira ticket).
• Asks for approval: Requests human approval before sensitive actions, or clarification when input is needed to proceed.
• Resumes: Suspended or paused investigations resume automatically once a human responds.

​

Our agents

Templates come in two shapes:

• Monitor-driven — the agent wakes up when a connected integration sends an event, and triages the issue that event produces.
• Scheduled — the agent has no monitors. It runs a recurring sweep against your connected tools and files issues from what it finds. Deactivating the agent pauses the sweep.

​

Cloud & platform

​

Identity & access

​

Endpoint & detection

​

DNS & external exposure

​

Code, supply chain & SDLC

​

Web3 & threat intelligence

​

Program, GRC & platform operations

​

The Community Library

Templates are the starting point, not the ceiling. The Community Library carries agents and skills proven by security teams already running Clarion — take an entire agent with its skills and scheduled jobs, or lift a single skill into an agent you already have. Sign in to read full skill bodies.

​

Creating agents

​

Start from a template

Templates are pre-built agents for common workflows. Each bundles a set of monitors, skills, and signal rules tuned for a specific domain.

• Smart Contract Security: Monitors on-chain activity, triages exploits, coordinates emergency pause workflows.
• Identity & Access: Tracks Okta, Microsoft Entra, JumpCloud, and 1Password events for impossible-travel, MFA bypass, and policy weakening.
• DNS Infrastructure: Watches your zones for unauthorized record changes, NS hijack, and dangling subdomains.
• Cloud Posture: CloudTrail, GuardDuty, and CloudWatch for AWS, with agent-driven IAM investigation.

To create from a template:

1. Open Agents in your workspace and click New agent.
2. Pick the template that matches your use case.
3. Review the bundled monitors, skills, and signal rules.
4. Configure notification channels. See Notifications.
5. Activate the agent.

​

Build from scratch

If no template fits, start with a blank agent.

1. Open Agents and click New agent → Blank.
2. Add monitors for the signals you want the agent to handle.
3. Add skills that describe how to respond. Use the skill library or write custom skills.
4. Configure notification preferences.
5. Activate.

Learn about Skills →

​

Monitors

​

Monitor types

Clarion supports monitor types across these categories:

• Identity & Access: Okta, Microsoft Entra ID, JumpCloud, 1Password, Google Workspace.
• Cloud: AWS CloudTrail, AWS GuardDuty, AWS CloudWatch, Amazon Inspector, GCP Cloud Logging, GCP Cloud Monitoring, GCP Security Command Center, Vercel.
• Source code: GitHub, Apex.
• On-chain: Hypernative, Hexagate, Tenderly.
• Endpoint: CrowdStrike Falcon, Huntress.
• Observability: Datadog, Grafana, Falco.
• Infrastructure checks: DNS zone monitoring, Better Stack uptime alerts.
• Generic: Webhook for any tool that can POST JSON.

Each Integration page describes how to set up monitors for that tool.

​

What you can do

• Create a monitor or multiple monitors for each connected tool, with type-specific configuration.
• Filter which events come through by severity or other criteria the monitor type supports.
• Enable / disable monitors without losing configuration.
• Assign monitors to agents so the right responder picks up each signal.

​

Scheduled & on-demand runs

​

Three ways a run starts

​

Scheduled agents

A schedule carries its own prompt — the instructions for that run — plus a standard five-field cron expression and an IANA timezone (UTC by default, so a platform schedule doesn’t inherit one team’s local time). Schedules are enabled or disabled individually, and deactivating the agent is the master off switch for all of them. Several agent templates ship with a schedule already attached, materialized and pinned to the agent when you create it: You can add your own schedules to any agent, or edit the ones a template brought.

​

What a scheduled run can do

A scheduled run is a full agent run, not a cut-down cron job:

• It files issues from what it finds, with a per-run cap so a bad night cannot flood the queue.
• It can ask a human for clarification mid-run and resume when someone answers — an overnight sweep does not have to guess or abort.
• It writes verdicts back to the Brain, so tomorrow’s run starts with what today’s decided and stops re-reporting things a human already parked.
• It posts a summary to the workspace’s notification destination, including a clean result, so silence is never ambiguous.

​

Failure handling

Each schedule stamps its next firing time on every successful claim, and consecutive spawn failures trip a circuit breaker rather than retrying forever. Run history — start, result, and error — is kept per schedule, and a single run’s clarifications are reported together.

​

Ad-hoc runs

Run now fires a schedule immediately, out of band, without touching its cadence. Multiple in-flight runs are safe: each gets its own run record. This is the usual way to test a schedule’s prompt before trusting it overnight, and Members can do it even though authoring schedules is Admin-only. Retriggering an issue re-runs triage on an existing issue — after new evidence lands, after a skill was corrected, or when the first pass was thin. Chat is the fully ad-hoc path: the same tools and skills, driven by a person, with no schedule and no monitor involved. See AI chat.

​

The Brain

An alert names a host. It never says who owns it, what it supports, whether the behaviour is expected, or whether you’ve seen it before. The Brain is where those answers live, built and kept current from the systems you already run. The difference shows up before the evidence does. An agent with the Brain starts on the right entity (this person’s managed device, the service this host supports, the confirmed note that this pattern is expected) instead of opening five integrations to find it. The discovery work disappears; the investigation starts at the analysis.

​

Two halves, side by side

Graphs are connections. Memory is learning. Agents need both.

​

What makes it work

​

How the graph is built

Assets are the base layer: one row per real resource, keyed by its native provider id — an AWS ARN, a GitHub repo, a Datadog service, a Vercel project, a managed laptop. Re-syncs update the same row in place, so an asset is durable and anything attached to it survives. Systems are the derived layer. A correlation engine reads each asset’s identifiers and buckets the ones that agree: the same service name, the same EC2 instance, the same repository URL, the same Aurora cluster, the same GitHub topic or org custom property. Any bucket with two or more members becomes a System — which is how a Datadog service, the AWS resources tagged for it, and the repo it is built from become one thing an agent can reason about. Systems are rebuilt from scratch on every sync in an atomic swap. If a rebuild fails, the previous ones stay intact and the next sync tries again. That’s why annotations and knowledge anchor to the durable asset, never to the derived grouping. An asset can belong to several Systems at once — one per correlation rule it matches.

​

Where assets come from

• Integration-discovered — a provider actually saw it. Cloud resources and their per-account posture, repositories with their rulesets, workflows, alert counts and CODEOWNERS, observability services and monitors, hosting projects and deployments, managed devices and their owners.
• Correlation-inferred — synthesized from another asset’s identifiers, so a repository referenced in cloud tags still correlates even with no source-control integration connected.
• Agent-recorded — written during an investigation for things no integration owns: an attacker IP, a vulnerable package, an external domain. These survive correlation rebuilds.

​

Memory and timelines

Signals, rule fires, alerts, issues, remediations, and linked Jira or Linear tickets all point back at assets. Ask for any resource’s history and you get a single merged timeline instead of six queries. Assets are resolved to signals again at rule-fire time, so an asset discovered today still picks up the fires that referenced it last week.

​

Knowledge and business context

On top of the catalog sits curated knowledge — cards describing systems, services, platforms, datastores, and tools — plus workspace-level business context. Knowledge arrives two ways:

• Recurring feeds pull from Jira and Notion on a cadence, each with its own cursor.
• One-time intake parses uploaded documents and URLs, extracts candidate facts, and writes them as proposals.

Both paths bridge back to catalog assets, so a card that describes “the payments platform” can point at the real infrastructure it means.

​

Nothing unreviewed reaches a prompt

This is the load-bearing rule. Workspace-scoped facts are filtered before they enter any agent prompt: a fact reaches the model only if a human authored it or a human confirmed it. An unconfirmed agent proposal is visible in the UI for review and invisible to the prompt. That is deliberate prompt-injection defence. Agents read attacker-influenced material every day — alert payloads, repository files, external pages, vendor responses. Without the confirmation gate, “the Brain remembers what it learns” would mean “an attacker can write into every future investigation’s system prompt.” Locked knowledge elements force every change through the same review. Each proposed fact carries its origin, so a reviewer can see which run produced it and from what.

​

Writing back

During a run, an agent can:

• Annotate an asset or the workspace with a durable, attributed fact.
• Record assets the investigation turned up that no integration owns — every one in a single call.
• Link entities that belong together; those links feed correlation as extra join keys, exactly like discovered identifiers.

Writes are permission-gated and every one is attributed to the agent’s job, so a claim in the Brain always traces to the run that made it. The Knowledge Maintainer agent owns the periodic drain and the editorial policy for what gets kept.

​

What agents actually call

The Brain is exposed to agents as always-on tools, scoped to the workspace and the job: list and read assets, list correlated systems, search knowledge, read business context, search the merged timeline across assets, and the write paths above. There is no configuration step — connect an integration and the tools have something to answer with.

​

Models & runtime

​

Tiers, not model names

Callers inside Clarion ask for a capability tier rather than a specific model, so a model generation change is one config edit and not a sweep through the codebase. Each tier resolves to an ordered chain of concrete provider/model candidates.

​

Model failover

Every tier’s chain pairs a primary with a cross-provider failover. When the primary hits a model-access failure — a provider outage, a capacity error, a model withdrawn — the run moves to the next candidate instead of failing. The failover is deliberately on a different provider. A failover to a sibling model on the same provider does not survive the failure mode that actually takes models offline. Candidates are compared canonically, so a bare model id and its provider/-prefixed twin collapse to one entry — the chain never retries the model that just failed under a different spelling.

​

Bring your own key (BYOK)

Enable BYOK for the workspace and paste an Anthropic or OpenAI API key in Settings → Workspace. Clarion infers the provider from the key prefix. A workspace with its own key runs only on its own providers:

• No cross-subsidy — your inference is billed to you.
• No tenant data through Clarion’s provider account.
• A run fails terminally rather than silently falling back to a Clarion key.

The key never enters the sandbox. Agent traffic goes through Clarion’s proxy, which attaches the credential host-side. Each tier resolves to a model on your own providers — by default the suggested model for that provider — and only ever fails over to another model on them. Clarion checks at save time that the key can serve every tier. Until you add a key, a BYOK-enabled workspace runs on the Clarion chain, so enabling the flag before pasting a key never takes the workspace down. Once a key has been added, removing it does not return the workspace to Clarion’s keys: runs fail until a key is added again.

​

What the sandbox can run

Agent runs execute in the opencode harness inside the sandbox. Clarion generates the harness’s provider configuration per run, which is why the set of usable models is not a fixed allowlist: it is every model opencode can be pointed at over one of the three wire protocols below. Naming a new model on a provider you already registered needs no Clarion release.

​

Bring your own provider

Beyond the two platform providers, a workspace can register credentials for any provider that speaks one of three wire protocols: Some gateways resell models from several vendors and serve each over that vendor’s own protocol: OpenCode Zen, OpenCode Go and Vivgrid. One key covers the whole gateway: Clarion drives each model over the protocol it needs, so a gateway’s Claude models go over Anthropic’s API and the rest over OpenAI’s. The picker prefills protocol and endpoint for the curated providers, and a custom entry covers anything not listed — you supply the base URL and key. A custom provider’s models all use the protocol you choose. Clarion can list the endpoint’s models to confirm the credential works before saving. A registered provider becomes addressable as provider/model anywhere a model is named. Any provider other than the two platform ones requires a stored credential: the proxy fails closed rather than reaching an unconfigured provider with a platform key.

​

Models settings

Workspaces with the BYO Models capability get Settings → Models, where you can see the resolved chain and override the model per tier. Without the capability the route is hidden and the workspace runs the platform defaults.

​

Subagents

An agent run can delegate to a subagent lane — a scoped worker with its own instructions, its own tool subset, and optionally its own model. Lanes are how a run does breadth-first exploration or a mechanical sweep without spending frontier-model context on it. What matters about Clarion’s implementation is where the decision is made: the trusted backend resolves the lanes, not the sandbox. Before the run starts, Clarion decides what each lane is, expands its tool scope against the tools the run can actually call, and stamps the answer onto the job. The sandbox receives a resolved answer rather than a declaration it could reinterpret. Two consequences follow:

• A lane whose tool scope cannot be expressed is dropped, not silently degraded. A subagent with an empty toolset is a failure that looks like success, so it is made visible instead.
• A lane bound to a non-inherited model has that model resolved to a concrete provider/model up front, under the same BYOK policy as the parent. A binding that cannot be resolved drops the lane — running a cheap-tier sweep on the frontier model, or a BYOK tenant’s traffic on a Clarion key, are both worse outcomes than the lane not existing.

Which lanes a workspace’s agents may delegate to is itself configurable.

​

Tool-call batching

Round trips, not tokens, are what make a long investigation slow. Clarion’s tool schemas are written so an agent asks for everything it needs in one call rather than one call per item:

• get_skill takes a list of skill ids. Skills are independent, so batching them costs one round trip instead of one each — and every skill in the batch renders in the run transcript.
• record_inferred_asset takes every asset an investigation turned up in a single call, up to 50. Duplicates inside a batch collapse to one row.
• MCP server decisions are batched by verdict: one call approves or denies many servers, and the result reports per-server outcome so a partly-landed batch is still legible.
• Clarifications are batched: several related questions reach the responder together, each labelled with its position in the batch.
• Tool catalog lookups batch ids, so a multi-capability triage resolves its whole tool surface at once.

A batched call that partly fails returns what succeeded alongside what didn’t, rather than discarding the whole batch — which is the guarantee batching exists to provide.