Detections Platform

​

What a detection is

A detection identifies suspicious activity or conditions in your environment so your security team can investigate and respond. Each detection is a Python notebook built with Marimo that checks data from connected tools or Cotool Logs. Once published, Cotool runs the notebook on a configurable schedule and turns qualifying findings into alerts for investigation.

​

Use any connected tool

Detections can work across the tools you connect to Cotool, using their available read-only actions to query activity and inspect current state. They can use your existing SIEM, identity provider, endpoint security tools, or other connected systems, and combine information from multiple tools in a single check. Cotool Logs is another data source for detections. You do not need to ingest a tool’s logs into Cotool before a detection can query that tool directly. Each detection needs the connections, permissions, and read-only actions required by its logic; detections that query Cotool Logs also need the relevant log streams enabled. For example, a detection could query sign-in events from your existing SIEM, look up the affected users in your identity provider, and flag activity involving privileged accounts. The detection brings those results together into findings with evidence for investigation.

​

How detections work

1. Define the check. Choose the sources, suspicious conditions, time window, and known benign exceptions. Cotool helps you express the logic in an editable Python notebook.
2. Test and publish. Run the draft, inspect its results, and publish a validated version. Scheduled runs use that published version, so unfinished draft edits do not change live behavior.
3. Evaluate on a schedule. Cotool queries the required sources, evaluates the detection’s conditions, and emits findings identifying the affected entities and supporting evidence. A successful run can return no findings.
4. Create alerts for investigation. Cotool records scheduled findings as hits and creates alerts for qualifying hits, applying the detection’s minimum severity and duplicate handling.

​

How findings become alerts

A hit records something the detection found, such as suspicious activity involving a user, host, or IP address. An alert is the investigation work created from a qualifying hit. It carries the detection’s evidence into the triage workflow. The detection’s Minimum severity setting controls which hits can create alerts. Lower-severity findings remain recorded as hits. Repeated findings can be correlated with existing hits rather than creating a new alert on every run, so the number of result rows does not necessarily equal the number of alerts. Alert routing determines what happens next: alerts can be assigned to a response agent for automatic triage or left unassigned for review. From there, your team can investigate, comment, escalate, and resolve the alert. See Alert Routing for setup details. Manual production runs let you inspect execution output without creating hits or alerts. Scheduled runs drive the alert workflow. This section covers detections that run in Cotool. For authoring rules deployed to an external security platform, see Detection Authoring.

​

Autotuning

Autotuning helps detections adapt to your environment as you investigate their alerts. Cotool uses alert feedback, including false-positive and benign outcomes, together with relevant alert comments to identify changes that could reduce noise while preserving useful findings. For example, repeated alerts from an approved automation account may reveal a specific benign pattern. Cotool can propose a targeted change to the detection, test it, and compare its results with the current published logic. The tuning workflow has three parts:

1. Learn from feedback. Cotool reviews available alert outcomes and comments to identify a change worth testing. Clear dispositions and comments give it better context about expected activity.
2. Evaluate the change. Cotool runs the candidate and compares it with the baseline. The evaluation tracks labeled false-positive or benign alerts eliminated, labeled true positives retained, and newly matched entities.
3. Review or apply. A proposal can be reviewed before publication or applied automatically when autotuning is enabled and the evidence and quality checks pass. Automatic application requires reducing labeled noise, retaining the labeled true positives in the evaluation, and keeping newly matched entities within the allowed limit.

These checks measure the available evaluation evidence; they do not guarantee that a change will catch every future threat. Published tuning changes appear in version history so you can inspect what changed and monitor subsequent results. Set the organization default in Settings > Detections. On an individual detection, Settings > Auto-apply tuning proposals can inherit that default or explicitly be set to On or Off. Turning it Off keeps reviewable proposals pending for manual approval; it does not stop proposal generation. Background proposals that fail the quality checks are rejected automatically. See Operate and Tune Detections for the review workflow.

​

Start with the library

Open Detections > Library and select a detection. Review its behavior and required log sources or tool connections. Complete missing requirements through Integrations before adding it. Select Add detection when the entry is eligible. Adding a library detection publishes it and starts its schedule. Open the added detection to review its settings and behavior in your environment. A connected integration and an enabled log source are different prerequisites. If an entry requires collected logs, follow Connect Log Sources and verify ingestion health.

​

Understand the lifecycle

The first publish enables scheduled execution, using an hourly cadence if none is configured. Later publishes preserve the existing schedule settings. Review Settings when making a detection live.

​

Inspect a detection

Open a detection from Detections to explore its tabs:

• Overview summarizes behavior, health, and version history.
• Logic shows the published detection logic.
• Alerts shows the detection’s alert activity.
• Executions shows individual runs and their output or errors.
• Settings controls scheduling, tuning, and the minimum severity for alerts.