Argus Open-Source Security Platform Restricts Autonomous Agents with Dedicated Action Brokers
Argus is a self-hosted, multi-tenant security operations platform that lets AI agents analyze evidence while strictly forbidding direct environment modifications. All remediations are routed to a standalone action broker supporting dry runs, policy approvals, and kill switches.
Why it matters
You can deploy security triage agents without risking unintended infrastructure modifications by separating read-only inspection tools from execution pipelines.
TL;DR
- 01Agents are restricted to read-only tools and cannot directly modify target cloud or Kubernetes infrastructure.
- 02Remediations require an explicit Action Broker supporting typed actions, dry runs, rollbacks, and manual approvals.
- 03Production mode enforces HMAC-signed, hash-linked audit trails sent to immutable object storage.
Key facts
- Detection Rules
- 12 rules (swarm x4, identity x2, cloud, k8s, code, canary, anomaly, agentic)
- Typed Actions
- 25 in action broker
- Supported Inbound Sources
- 13 inbound parsers
- Outbound Notification Sinks
- 6 channels (webhook, Slack, Jira, ServiceNow, PagerDuty, email)
Architecture of Read-Only Agentic Operations
Argus enforces a strict trust boundary across its core architecture. Autonomous agents evaluate signals from 12 detection rules covering swarm behaviors, identity anomalies, cloud exposure, and canary tokens. However, the runtime completely prevents agents from issuing write commands directly to connected cloud APIs. When an agent determines that remediation is needed, its sole mechanism is invoking propose_action, which creates a pending ActionRequest record.
Remediation must flow through an independent Action Broker that supports 25 typed actions across AWS, Azure, GCP, Kubernetes, GitHub, Okta, and Entra. The broker governs changes via explicit approvals, dry runs, deterministic rollback routines, and global kill switches.
Deployment Requirements and Production Hardening
The backend is built with FastAPI, supporting SQLite for local prototyping and PostgreSQL plus Redis for distributed deployments. Setting APP_ENV=production activates strict runtime assertions: the platform refuses to boot without PostgreSQL, an active Redis queue, COOKIE_SECURE=true, external audit sinks, and enforced two-factor authentication or OpenID Connect.
Audit trails are hash-linked and HMAC-signed per tenant. Sinks support AWS S3 Object Lock and Azure immutable blobs, ensuring that agent activity cannot be tampered with even if API credentials are compromised.
Try it in 2 minutes
git clone https://github.com/thomasunise/argus.git
cd argus
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt -r requirements-dev.txt
python scripts/generate_secrets.py --write
uvicorn app.main:app --host 127.0.0.1 --port 8080bash
✓ When to use
- Use when deploying AI agents to investigate security alerts and triage cloud infrastructure misconfigurations.
- Use when building SecOps workflows that require strict audit trails, dry runs, and human-in-the-loop approvals.
✕ When NOT to use
- Do not use if you require fully hands-off, zero-latency autonomous self-healing without approval gates.
- Do not deploy in production without configuring PostgreSQL and an external immutable audit storage bucket.
What to do today
- Review autonomous agent permissions in your CI/CD pipelines to ensure write capabilities require human verification.
- Inspect the Argus repository to examine the propose_action separation pattern for custom tool-calling agents.
- Implement immutable audit sinks using S3 Object Lock for all autonomous agent execution logs.
What the community says
“Do people want agents taking action without approval on security?”
“What part of this looks solid?? The first sentence: > Argus is a self-hosted, multi-tenant security operations platform in which AI agents analyze evidence but never act on the estate.”