agentleFS
beenuarbeenuar/AiSOC/AGENTS.md

AiSOC

AGENTS.md6.1k starsChanged 11 days agoMITView on GitHub

AiSOC is an open-source, AI-assisted Security Operations Center: telemetry comes in from your own security tools, gets normalized, matched against a detection corpus, correlated into alerts, triaged by an agent, and acted on through governed response verbs. It runs on your own infrastructure — cloud or on-premises — under the MIT license. This file is for anyone changing the code, human or AI. It is the short version; each section points at the thing that is authoritative. If this file…

  • Reads credentials

We split this AGENTS.md into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never copy a number out of prose — it goes stale silently and several have.

    line 92

≈ “Common” is an estimate: at least 1 in 5 of the 36,368 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

Working in this repository

AiSOC is an open-source, AI-assisted Security Operations Center: telemetry comes in from your own security tools, gets normalized, matched against a detection corpus, correlated into alerts, triaged by an agent, and acted on through governed response verbs. It runs on your own infrastructure — cloud or on-premises — under the MIT license.

This file is for anyone changing the code, human or AI. It is the short version; each section points at the thing that is authoritative. If this file and the tree disagree, the tree is right and this file is a bug.

Get it running

make up        # CORE profile: 16 long-running services, ~8 GB memory, ~20 GB disk
make doctor    # what is up, what is not, and what to do about it
make smoke     # the golden pipeline, eight stages, end to end

make up generates real secrets into .env, creates an administrator and prints its password once. There is no step where you hand-edit a compose file. make up-full adds the rest (21 services, ~12 GB) and switches on the lake writer and the entity graph.

A first run shows real data with no credentials configured: the CISA Known Exploited Vulnerabilities catalogue is a genuine public feed that needs no API key, and a small local model does the triage.

The shape of the system

One event's journey, which is the thing worth understanding first:

connector  →  services/ingest  →  Kafka raw_events  →  services/fusion  →  Postgres alerts
  polls a      normalizes to       the spine            archives to the       + services/realtime
  vendor       OCSF, projects                           lake, matches         pushes to the console
  API          actor/action/                            detections,           ↓
               resource/location                        correlates,        services/agents
                                                        promotes           triages with an LLM
                                                                              ↓
                                                                        services/actions
                                                                        executes a governed verb

Each hop is a service in services/. The stores are Postgres (operational), ClickHouse (the event lake), Neo4j (the entity graph), Qdrant (vectors), Redis and Kafka.

Fuller treatment: docs/architecture/README.md and the architecture page on the docs site.

Where things live

PathWhat is in it
services/The backend services above, one directory each
apps/webThe Next.js console
apps/docsThe documentation site
packages/Published SDKs, the benchmark harness, the offline sandbox
detections/Generated detection YAML — see the warning below
schemas/event_catalog/Vendor event types mapped to a normalized action and a sensitivity
plugins/One marketplace manifest per connector
scripts/The CI gates. Most are runnable alone and most have --self-test
infra/Compose overlays, Terraform, Grafana dashboards
plans/Locked planning documents. Do not edit these.

Conventions that are easy to guess wrong

  • detections/*.yaml is generated output. The engine loads services/fusion/app/data/detection_ruleset.json, compiled from Python spec modules. Editing the YAML changes nothing that runs.
  • The severity ladder is exactly five tiers — info | low | medium | high | critical. A vendor that publishes a distinct critical must map to critical, never be collapsed into high. Confidence is a separate 0–100 integer and is not severity.
  • A connector's normalized envelope nests the vendor payload under raw_event, not raw. Twenty-six connectors once used raw, missed the canonical-envelope check, and were silently misattributed and never promoted.
  • A new connector needs one registration, in _CONNECTOR_CLASSES in services/connectors/app/connectors/__init__.py. Everything else is discovery.
  • The tenant is never a parameter a caller or a model can set. It comes from the authenticated principal, or for service-to-service calls from a header. Three gates enforce this.
  • Secrets in connector config are vault-encrypted at the application layer; services/api owns the write path.

Figures, and how to re-derive them

Never copy a number out of prose — it goes stale silently and several have. Each of these regenerates:

FigureCurrentCommand
Executable detection rules2,535 of 7,015 on diskpython3 scripts/generate_corpus_stats.py --check
Rules that cannot fire2python3 scripts/check_detection_fields.py
Connectors87python3 scripts/generate_connector_count.py --check
Services per profileCORE 16, full 21python3 scripts/check_profile_service_counts.py
Claims with a gate behind them299 rowspython3 scripts/check_claim_gate_matrix.py

"Executable" means the rule was replayed through its real connector and the real engine and watched to fire. It is not a claim that the rule detects an attack, and that distinction is deliberate.

How a change gets accepted

main is protected: a pull request plus a set of required status checks. The checks are not decoration — most of them exist because something shipped broken in exactly the way they now prevent.

Before you push:

ruff check services/ scripts/ tests/ tools/ && ruff format --check .
python3 scripts/check_mypy_baseline.py

ruff is pinned (>=0.16.8,<0.17) and the version is the behaviour — a different one reformats files CI never asked for. Install the pin into a throwaway virtualenv rather than using whatever is on your PATH. Build a per-service environment from that service's own locked set with python3 scripts/service_requirements.py <service> --locked, and do not install anything else into it: adding one package has already moved a dependency off the lock and changed a generated artefact.

The bar for a fix

Three things, in order, and the middle one is not the hard part:

  1. A test that fails on the current tree for the stated reason — through the real transport, the real app with its real dependencies, and a real database.
  2. The fix.
  3. A negative control: revert the fix, watch the test fail again.

A passing test on a function nothing calls is indistinguishable from a working feature. This repository has found that shape dozens of times, which is why scripts/check_module_reachability.py exists.

Rules that are not negotiable

  • No attribution to any tool, AI assistant, editor or vendor for the work — not in code, comments, documentation, commit messages, trailers or pull request bodies. scripts/check_attribution.py enforces it.
  • No competitor product named outside an integration surface. Where one is the benchmark for a comparison, refer to it neutrally and keep the analysis. scripts/check_competitor_names.py enforces it; scripts/competitor_names.toml holds the integration allow-list.
  • Never present fabricated data as real. Seeded or sample data is gated behind demo mode; everywhere else shows an honest empty, zero or error state. A measurement nobody took reads "not measured", never 0.
  • Never raise a scanner ceiling to make a scan pass. Find the finding and fix it.
  • Do not edit anything under plans/.
  • Fetch every URL before you commit it and require a 200. A link that 404s is worse than no link: delete it and rewrite the sentence.

If you are an AI agent

Everything above applies. Four things specific to you:

  • Read before you assert. Several claims in this repository were wrong in both directions at different times — recorded as present when absent, then as absent after they had been written. Check the file is on disk and read past its rationale; a module docstring often opens by describing the problem it fixed, which is not a description of the current state.
  • Prefer testing the path over the function. The most productive defect class here is a test double more capable than the real thing: a fake store that answers any query, a mock that bypasses the transport.
  • Say what you could not verify. "I could not check X, and here is why" is worth more than an implied pass.
  • Nothing in this repository can make a third-party AI tool reach for AiSOC by default. That comes from publishing the packages and listing the MCP server in a registry, which is tracked work, not a documentation change.

Machine-readable summaries live at llms.txt and llms-full.txt. Both are generated by scripts/generate_llms_txt.py — change the generator, never the output.

Credits

AiSOC's development is funded and supported by Cyble.

Download now (ZIP)

Trending

Quiet since July.thin dataabout the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 0 mentionsJul 2026: 3 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the beenuar/AiSOC repository that our weekly crawl found: only 3 in all, so this is a hint, not a trend. There is no adoption data for this file yet.
  • Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.

    Of the AGENTS.md files we read, the 28,693 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.