Skip to content

Blog

AI SOC Agent with clickdetect!

Hey guys, souzo here. Today I'm announcing the AI SOC agent for clickdetect.

I've been working on a plugin system for clickdetect for a while. To demonstrate the powerful capabilities of clickdetect, I have implemented the plugin clickagentic!

In this blog post I'll walk you through clickagentic to demonstrate the power of clickdetect.

Clickdetect repository: https://github.com/clicksiem/clickdetect

Clickagentic

Clickagentic the SOC AI agent

Clickagentic intercepts the generated alert before sending it to a webhook. It receives all content to analyze the alerts and generate an automated response.

Plugin System

I have implemented a plugin system in clickdetect, and now you can create your own plugin to do whatever you want like: - Block an IP in the firewall - Integrate your system without needing a webhook - Create your own SOC AI agent :)

Check the documentation for a more detailed explanation. https://clickdetect.souzo.me/plugin/

Agent response

This is the default response schema of the SOC agent.

  • summary(str): This is the summary generated by the agent
  • severity(Enum(Critical, High, Medium, Low)): The agent will generate a severity based on context of the alert
  • confidence(int): This is the confidence percentage of the generated response
  • false_positive_score(int): This indicates the percentage chance the alert may be a false positive
  • explanation(str): Detailed explanation of the alerts
  • mitigations(List[str]): Mitigation list for the generated alert
Installation

To use the clickagentic, you need to install the clickagentic packages

git clone https://github.com/clicksiem/clickdetect
uv sync --group clickagentic
Configuration

You need to configure the runner to run the clickagentic plugin and your LLM

Add this at the end of your runner.yml

plugins:
  clickagentic: # plugin id
    provider: 'openai' # provider: openai, anthropic, google, huggingface, ollama, openrouter, deepseek
    model: 'gpt-5.2' # model name from your provider
    token: 'xxx'
    false_positive: |
        Scanner 10.0.0.5 runs daily vulnerability scans and will trigger
        port-scan rules. Ignore alerts where source_ip is 10.0.0.5.

As you can see, you can set up your own false positive considerations.

Running

You can simply run the clickdetect with the configured runner

uv run clickdetect -r runner.yml

This is what the agent response looks like

Sample alert

Considerations

Cost

Each alert processed by clickagentic triggers a call to your LLM provider, which may incur API costs depending on the provider and model you choose. In high-volume environments, this can add up quickly. Consider filtering low-severity alerts before they reach the plugin to reduce unnecessary calls.

Privacy

Alert data sent to external LLM APIs (OpenAI, Anthropic, Google, etc.) may contain sensitive information such as IP addresses, usernames, or internal hostnames. If your environment has strict data residency or compliance requirements, consider using a local provider like Ollama to keep all data on-premise.

plugins:
  clickagentic:
    provider: 'ollama'
    model: 'llama3.2'
    token: ''

Known Limitations

Latency and query thresholds

Calling an LLM introduces latency that can range from a few hundred milliseconds to several seconds depending on the provider and model. If your clickdetect runner is configured with a detection threshold in seconds, the LLM response time may exceed that window and cause issues in the query cycle. It is recommended to use thresholds of at least one minute when running clickagentic, or to use a fast local model via Ollama to reduce response times.

Conclusion

With clickagentic, the possibilities are endless — automate triage, enrich alerts, and respond faster. You can automatically skip alerts with a false positive score above 90%. You can automate your SOC L1 process. Want to validate alerts in other systems? Try using MCP, or open an issue and let me know!

If this project helped you or sounds promising, please give it a star on GitHub — it means a lot and helps the project reach more people in the security community.

⭐ Star Clickdetect on GitHub

Have questions, ideas, or want to contribute? Open an issue or a pull request — the door is always open.

ElastAlert is dead, long live Clickdetect

Hey, souzo here.

ElastAlert has been around for a long time and served the security community well. But the ecosystem has changed — new datasources emerged, new integrations became standard, and the expectations around alerting tools grew significantly. ElastAlert has struggled to keep up.

This post introduces Clickdetect as a modern alternative: more datasources, more webhooks, more control over your queries, and a simpler operational model. If you are tired of working around ElastAlert's limitations, this is for you.

Clickdetect is a generic alerting and detection engine that supports any datasource you have and integrates with any webhook you want.

Check it out on GitHub: https://github.com/clicksiem/clickdetect.

You can also read my previous blog post about Building a powerful SIEM with Clickhouse and Clickdetect.

Clickdetect vs ElastAlert

Why replace ElastAlert with Clickdetect?

You may think — who is this guy trying to tell me that Clickdetect is better than ElastAlert when I've been using ElastAlert for years?

I'm just someone trying to build the best open source security project of my life.

Let me show you why this approach is better.

First of all, let me explain why you should choose Clickhouse instead of Elasticsearch.

Why replace Elasticsearch

See this Clickhouse post: Clickhouse Vs Elasticsearch I tested and I'm current running in a closed environment. I can guarantee, everything Clickhouse posted is real, and it's even better.

Scalability

  • Clickhouse scales better than OpenSearch/Elasticsearch with Distributed tables.
  • You can use big data schemas to centralize your data without being limited to your current storage.

Big data standard schemas | Data lakehouse

You can create your own big data table using Apache Iceberg, Delta Lake, Hudi, etc.

This approach gives you a better way to store your data (I recommend Delta Lake by Databricks).

You can also integrate any data lake you already have with big data tables!

Better storage cost

  • You can cut your disk usage by 90% with Clickhouse while maintaining the same (or better) performance, thanks to its built-in compression.
  • 90% of disk usage reduction, are you crazy, this means your 1 Petabyte storage will be 100 terabyte usage storage!

More control

  • You have full control over your data — Clickhouse is like PostgreSQL, but built for your dreams.

More, more, more

  • Reading the Clickhouse documentation is a piece of heaven — you will discover functionalities you never knew existed!
  • WARNING: You could become addicted!

Ok, Clickhouse is better — but why Clickdetect over ElastAlert?

I built Clickdetect to be as generic as possible. You can even use Clickdetect with Elasticsearch if you are not ready to switch to Clickhouse as your datasource.

Datasource integrations

  • Elasticsearch/Opensearch: Yes, Clickdetect has integration with it.
  • Clickhouse: Of course.
  • Loki: Grafana Loki datasource integration — great if you want to replace Loki or the Grafana alerting engine.
  • VictoriaLogs: VictoriaLogs can match the performance of Elasticsearch and Clickhouse. I simply didn't choose it as the primary datasource because it is still very recent.
  • PostgreSQL: PostgreSQL integration — you can search through your database. If you use TimescaleDB or TigerData, this works great too.
  • Databricks (not implemented yet, but on my roadmap).

Webhooks

  • Generic: Generic integration — send to any webhook, including N8N.
  • DFIR Iris: Send alerts to DFIR Iris.
  • Forgejo/Gitea: Create issues from your alerts.
  • Email: Send alerts via e-mail.
  • Microsoft Teams: Send alerts to Microsoft Teams.
  • Slack: Send alerts to Slack.
  • Telegram: Send alerts to a Telegram bot.
  • Whatever you want: The Clickdetect documentation will show you how to implement your own webhook — or just open an issue!

Runtime management

  • You can use the reload option in Clickdetect to hot-reload your rules whenever a new rule is added to disk.
  • API: Clickdetect has an API to manage it programmatically.

You write your rules

  • Clickdetect is built to be simple. You write your query, and Clickdetect handles the rest.

ElastAlert rules vs Clickdetect rules

Let's make this concrete. Here is the same detection — multiple failed logins in a short window — written in both tools. This example uses Elasticsearch/OpenSearch as the datasource, so if you are already an ElastAlert user, you can migrate without touching your stack.

ElastAlert

name: Multiple Failed Logins
type: frequency
index: wazuh-alerts-*
num_events: 15
timeframe:
  minutes: 5
filter:
  - term:
      rule.groups: "authentication_failed"
  - term:
      data.win.system.eventID: "4625"
alert:
  - slack
slack_webhook_url: "https://hooks.slack.com/services/your/webhook/url"

ElastAlert owns the query logic. You configure what you want to detect through its abstraction layer — frequency, spike, flatline — and it builds the query for you. That works until you need something it does not support.

Clickdetect

runner.yml — your datasource and detector configuration:

datasource:
    type: elasticsearch
    url: http://localhost:9200
    index: wazuh-alerts-*
    username: elastic
    password: changeme

webhooks:
    slack:
        type: slack
        url: "https://hooks.slack.com/services/your/webhook/url"

detectors:
    5m_detector:
        for: "5m"
        rules:
            - "rules/windows/*.yml"
        webhooks:
            - slack

rules/windows/multiple_failed_logins.yml — the rule itself:

id: "a1b2c3d4-0000-0000-0000-000000000001"
name: "Windows - Multiple Authentication Failures"
level: 12
size: ">0"
active: true
rule: |-
    {
        "size": 0,
        "query": {
            "bool": {
                "filter": [
                    { "term": { "rule.groups": "authentication_failed" } },
                    { "term": { "data.win.system.eventID": "4625" } },
                    { "range": { "@timestamp": { "gte": "now-5m" } } }
                ]
            }
        },
        "aggs": {
            "by_user": {
                "terms": { "field": "data.win.eventdata.targetUserName", "min_doc_count": 15 }
            }
        }
    }

With Clickdetect, you write the query directly in Elasticsearch Query DSL. No abstraction layer, no hidden magic. If Elasticsearch can do it, Clickdetect can detect it.

The migration path is straightforward: keep your Elasticsearch/OpenSearch stack, swap ElastAlert for Clickdetect, and start writing your own queries. When you are ready to move to Clickhouse, it is just a datasource change in runner.yml.

Conclusion

If you made it this far, you now know why I built Clickdetect and what it can do for you.

Clickdetect is open source, actively maintained, and designed to grow with your infrastructure — whether you are running Elasticsearch today or planning a full move to Clickhouse tomorrow.

If this project helped you or sounds promising, please give it a star on GitHub — it means a lot and helps the project reach more people in the security community.

⭐ Star Clickdetect on GitHub

Have questions, ideas, or want to contribute? Open an issue or a pull request — the door is always open.