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.
The two halves
Section titled “The two halves”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.
The agent pulls; nothing pushes to it
Section titled “The agent pulls; nothing pushes to it”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.
What actually crosses the boundary
Section titled “What actually crosses the boundary”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.
How work flows
Section titled “How work flows”- You, or a schedule, create a job on the control plane: a discovery or a scan.
- The job sits pending until an agent polls and claims it.
- The agent runs it locally, heartbeating so the platform knows it is alive.
- It posts results; the control plane classifies, scores, evaluates policies and compliance, and raises alerts.
- 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.
Scaling and multiple accounts
Section titled “Scaling and multiple accounts”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.
Credentials
Section titled “Credentials”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.
Tenancy
Section titled “Tenancy”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.
- What gets created in your account - the exact resource list per deployment path.
- IAM permissions - every permission the agent asks for, and why.
- Core concepts at a glance - the vocabulary in one screen.