Argus Brings AI Security Agents and Controlled Response to Open Source

Argus is a newly published, MIT-licensed security operations project that combines investigative AI agents with a separate system for approving and executing responses. Its source includes endpoint containment and opt-in autonomous playbooks, but teams still need to evaluate the software against their own infrastructure.

The project appeared on Show HN on October 24. By October 25, its repository contained implementations for seven specialist agents, a catalog of 27 actions, and vulnerability enrichment using CISA's Known Exploited Vulnerabilities catalog and scores from the Exploit Prediction Scoring System (EPSS). This is an early source-code project moving quickly, rather than an established enterprise product with demonstrated operational results.

Agents investigate, the broker controls execution

The most useful architectural detail is the separation between investigation and execution. Specialists cover triage, investigation, hunting, remediation proposals, posture reporting, red-team planning, and coordinated-threat response. Their tools read security data or create an action proposal. The proposal tool sends a request to the action broker and does not execute the requested change itself. The broker's policy code also excludes agent-originated requests from automatic approval.

That distinction matters because interpreting an alert and changing a production system require different permissions. An agent can assemble evidence and suggest a response while the broker handles parameter validation, policy checks, approvals, dry runs, and execution. The repository supports Anthropic, OpenAI, and Ollama providers, along with a no-provider mode using deterministic fallbacks. Running the application yourself does not, by itself, mean data stays local when an external model provider is configured.

The action catalog extends across cloud, identity, code, Kubernetes, and endpoint systems. Reading the current executor files confirms 27 named actions, including CrowdStrike host containment and SentinelOne endpoint disconnection. These are concrete API integrations with dry-run, execution, and rollback methods. The endpoint actions are classified as high risk, and their dry runs refuse server targets unless the operator explicitly permits them. That establishes what the code attempts to do, not how reliably it works in a particular deployment.

Autonomous response requires explicit configuration

Autonomous response uses a separate playbook engine, rather than giving the language model unrestricted execution access. The implementation subscribes to detection events, matches configured playbooks, renders action parameters, and routes requests through the broker. It checks action reversibility, risk, hourly limits, and the number of affected resources. Critical actions are excluded, while high-risk actions require a playbook-specific opt-in.

The global response switch defaults to off, tenants must opt in, and new playbooks start in shadow mode. Shadow mode records what would happen without executing the action. Enforced playbooks can schedule rollback, although operators can disable that timer or keep a change. The documentation also notes that an engaged kill switch blocks rollback until released. Those settings deserve explicit review before anyone treats automatic rollback as an operational safety net.

Threat intelligence adds context to findings

The threat-intelligence implementation is similarly inspectable. New findings containing CVE identifiers can trigger a queued enrichment job. The code records KEV membership and EPSS scores, preserves supporting details, and can raise severity according to configured rules. Disk caches and an offline mode support installations where feeds must be supplied manually. This helps organize vulnerability evidence; it does not establish that an attack occurred or that a remediation will succeed.

Start with monitoring and validation

The project's go-live guide recommends starting in monitoring-only mode with the kill switch engaged, read-only collector credentials, and intrusive testing disabled. Teams still need to tune detections, choose their data-handling arrangements, rehearse recovery, and decide which actions they are willing to delegate. The roadmap also leaves work on interface coverage, distributed controls, and larger agent evaluation datasets.

This assessment is based on the published code and documentation, not a deployment, penetration test, or independent security audit. The repository includes tests for endpoint actions, enrichment, and response controls, but several integration checks use mocked services. For builders, the immediate value is the ability to inspect how an AI-assisted security workflow separates evidence gathering, proposed changes, policy decisions, and execution before considering a limited pilot.

I'm Paras. I work at the intersection of AI, engineering, and distribution.

If you're building an AI or security product, I can help turn the underlying architecture into clear technical storytelling that explains what works today and what still needs validation.

Book a 30-minute call.