Skip to content

Architecture

Argus uses a split control-plane / data-plane design. Your data is processed where it already lives and never leaves; only structured findings cross the boundary. This is the design that lets Argus pass a strict data-residency review.

Control plane (hosted by Argus). Authentication, dashboards, RBAC, the audit log, alerting, policy evaluation, compliance mapping, and the job queue. It holds findings and metadata about your environment. It never holds your data, and it never holds a credential that could reach it.

Data plane (your cloud). The Argus agent, running as a container inside your own account. It discovers datastores and identities, samples and classifies content in place, and reports back.

ARGUS CONTROL PLANE dashboards, alerts, policies, compliance, job queue
^
| outbound HTTPS from the agent, findings only
|
YOUR CLOUD ACCOUNT
Argus Agent --(read-only)--> S3 / RDS / DynamoDB / Redshift / Azure
--(read-only)--> IAM
Your data stays here. Only counts, classifications, and metadata leave.

For a visual version of this - plus a detailed in-account footprint of everything the agent deploys and reads - see Reference architecture.

Every exchange is initiated by the agent, outbound over HTTPS. It polls for work, claims a job, heartbeats while running it, and posts results. The control plane never opens a connection to your environment and has no address for it.

That single property is what produces the guarantees below. It is not a firewall configuration you have to get right; it is the shape of the system.

Guarantee Why it holds
No inbound ports Nothing ever connects to the agent. The managed templates create an egress-only security group with zero inbound rules
No credential of yours leaves The agent uses its own instance profile or task role at runtime, inside your account. Argus never receives an IAM principal
No role Argus can assume Every role’s trust policy names an AWS service in your account, never an Argus principal. There is no cross-account trust
Insights, not data Only counts, classifications, and resource metadata are reported. Never the sensitive values themselves

If the agent stops, discovery and scanning stop. Nothing else in your account is affected, and nothing is left holding access.

Outbound, from the agent:

  • Which datastores and identities exist, and their configuration metadata such as region, size, encryption state, and public-access state.
  • Counts and classifications: how many findings of which data type, with confidence figures. Not the matched values.
  • Job status, progress, and errors.

Inbound, to the agent, in the response to its own poll:

  • Jobs to run, and its runtime configuration.

Nothing else. This is why an Argus export can be attached to a ticket safely: even the reports carry counts and metadata only.

  1. You, or a schedule, create a job on the control plane: a discovery or a scan.
  2. The job sits pending until an agent polls and claims it.
  3. The agent runs it locally, heartbeating so the platform knows it is alive.
  4. It posts results; the control plane classifies, scores, evaluates policies and compliance, and raises alerts.
  5. A job that is abandoned mid-run, or left unclaimed with no healthy agent, is reaped and marked failed with a reason rather than hanging.

You can watch all of this on the Jobs tab of Agents.

Deploy one agent per cloud account you want scanned. Agents can also run as a baseline pool that is always on plus a burst pool that scales up under load and recedes afterwards, which is what the Fargate path’s autoscaling provides.

Because agents pull work, adding one needs no control-plane configuration: it enrolls, starts polling, and begins claiming jobs.

Two separate credential types, deliberately:

  • An enrollment token belongs to a cloud account and is exchanged once, at first boot, for the agent’s own API key. It is rotatable.
  • An agent API key is per-agent and used from then on. Rotating it issues a new key while the old one stays valid for a grace window, so rotation is not an outage.

Detail in Credentials: Bootstrap vs Manual.

Every record belongs to exactly one tenant, scoped at the data layer rather than filtered in the UI. There is no cross-tenant view in the product. See Tenants & RBAC.