Deploy the agent - overview

The Argus agent is a single container image that runs inside your environment and does three things:

1. Discovers datastores (S3, RDS, DynamoDB, Redshift, and more) inside the AWS account(s) it has read access to.
2. Samples data from those datastores and runs sensitive-data detection locally, so the actual content never leaves your environment.
3. Reports findings (counts, classifications, risk signals) back to the Argus control plane over outbound HTTPS only.

You deploy the agent once per cloud account you want Argus to scan. There are three deployment shapes, and within each shape there are sub-paths. Pick the combination that fits your environment.

For a diagram of everything the stack creates in your account and what the agent reads, see Reference architecture.

The three shapes

Shape	Best for	What runs where
Cloud (managed)	Single AWS account, one-click setup	Agent on Fargate or EC2; IAM roles, security group, secret, and logs all provisioned by CloudFormation
Cloud (DIY)	You manage your own IaC	Agent on Fargate or EC2 (Terraform) or ECS (task JSON), wired into your stack
Local / single-host	Laptop, on-prem VM, edge, air-gapped	Docker Compose, docker run, or an offline tarball; the agent assumes a role into the target account

Decision tree

Where do you want the agent to run?

|-- Inside the AWS account being scanned, and you want AWS to provision
|   everything in one click via CloudFormation:
|     |-- Production, scales with workload: Cloud (managed) -> Fargate
|     |-- Single host, simpler / cheaper:   Cloud (managed) -> EC2
|
|-- Inside the AWS account being scanned, but you manage the IaC yourself:
|     |-- Terraform, scales with workload:       Cloud (DIY) -> Terraform (Fargate)
|     |-- Terraform, single host:                 Cloud (DIY) -> Terraform (EC2)
|     |-- You already have an ECS cluster:       Cloud (DIY) -> ECS task JSON
|     |-- You just need the IAM policy text:     Cloud (DIY) -> IAM policy
|
|-- Outside AWS (laptop, on-prem VM, edge box) and reach AWS via a role:
      |-- Compose-managed setup:                 Local -> Docker Compose
      |-- Single ad-hoc container:               Local -> docker run
      |-- No internet on the target host:        Local -> Offline tarball

Pick your path

• Cloud managed: Fargate | EC2
• Cloud DIY: Terraform | ECS task JSON | IAM policy
• Local: Docker Compose | docker run | Offline tarball

What gets created in your account

Every resource each path provisions, so you can hand this to a security reviewer before you run anything.

The two properties that matter most

No inbound ports are opened. Both managed templates create an egress-only security group, and neither emits a single inbound rule on a default deploy. The agent is not reachable from the internet or from anywhere else in your VPC. The one exception is opt-in and deliberate: on the EC2 path you can add SSH by supplying both a key pair and an explicit source CIDR. Leave either blank and nothing is opened.

No role is created that Argus can assume. Every role’s trust policy names an AWS service inside your account (ecs-tasks.amazonaws.com, ec2.amazonaws.com, or scheduler.amazonaws.com), never an Argus principal. There is no cross-account trust, no external ID, and no access key. Your credentials never leave your account, and the Argus control plane holds nothing it could use to reach your data on its own.

Cloud (managed): Fargate

One CloudFormation stack, ten resources on the default rolling :stable image (eight when you pin a version):

Resource	What it is
Secrets Manager secret	Holds the enrollment token the task reads at boot
Security group	Egress only: 443 TCP, plus 53 TCP and UDP for DNS. No inbound rules
CloudWatch log group	Agent logs, 14-day retention
ECS cluster
IAM role (task execution)	Used by ECS at launch to pull the image, read the token secret, and write logs. The agent process never assumes it. Carries the AWS-managed AmazonECSTaskExecutionRolePolicy
IAM role (task)	The identity the agent runs under. Carries the discovery policy
ECS task definition
ECS service	Keeps the agent running
EventBridge Scheduler schedule	:stable only. Forces a new service deployment once a week so the agent keeps tracking the rolling release. Not created for pinned deploys
IAM role (scheduler)	:stable only. Assumed by scheduler.amazonaws.com for that weekly refresh; its single permission is ecs:UpdateService on the agent service. Not created for pinned deploys

With autoscaling enabled the stack also creates an IAM policy allowing cloudwatch:PutMetricData scoped to the ArgusDSPM/Agent namespace, and a burst set: a second task definition and service, an Application Auto Scaling target, two scaling policies, and two CloudWatch alarms that watch unclaimed scan backlog.

Cloud (managed): EC2

One CloudFormation stack, six resources:

Resource	What it is
Secrets Manager secret	Holds the enrollment token
IAM role	The discovery policy, plus the AWS-managed AmazonSSMManagedInstanceCore so your operators can reach the host over Session Manager without opening SSH
IAM instance profile	Attaches that role to the instance
Security group	Egress only: 443 TCP. No inbound rules, unless you opt into SSH by supplying both a key pair and a source CIDR
CloudWatch log group	Agent logs, 30-day retention
EC2 instance	Amazon Linux 2, resolved through an SSM AMI lookup so it works in every region. Runs the agent as a container under systemd. On the default :stable image the instance also carries a weekly refresh cron (inside the host, not an extra AWS resource) that re-pulls the image and restarts the agent only when the digest changed

Cloud (DIY)

• Terraform provisions the same shape as the matching managed template, but into your own state rather than a CloudFormation stack you do not control. Its security group is not identical to the CloudFormation one: the EC2 module also permits inbound 8080 from within your VPC for the agent health endpoint, and inbound 22 from the AWS EC2 Instance Connect prefix list. Optional SSH from your own CIDR is off unless you set both enable_ssh_access and allowed_cidr_blocks. The Fargate module opens nothing inbound.
• ECS task JSON creates nothing on its own. You supply the cluster, and you create both IAM roles by hand from IAM permissions.

Local / single-host

Nothing is created in your AWS account. There is no stack, no instance, no security group, and no log group. The agent runs on hardware you already have and reaches AWS by assuming a role you create yourself, using the JSON on the IAM permissions page. That role is the only thing that exists in the account, you author it, and you control its trust policy and its external ID.

Finding and removing it later

Everything Argus provisions carries an argus prefix, by policy and across every resource type: argus-agent-<stack> for the cluster, service, and task family, ArgusAgentTask-<stack>, ArgusAgentExec-<stack>, and ArgusAgentScheduler-<stack> for the roles, argus-agent-<stack>-weekly-refresh for the Fargate refresh schedule, /argus-agent/<stack> for the log group, argus/<stack>/enrollment-token for the secret. That is a deliberate trust property, not cosmetics: aws iam list-roles in your own account should make it obvious at a glance what we put there. The narrow exception is resources whose physical name CloudFormation generates for us, such as the security group.

Because the managed paths are a single stack, deleting the stack removes all of it. See Teardown.

Before you start

Every path shares the same setup: an Argus account, a registered cloud account, a credential, and (for cloud paths) IAM roles. Read Pre-flight first, then pick your path above.

The public IaC repo is the source of truth for the Cloud (managed) templates and the Cloud (DIY) Terraform module. The agent image is ghcr.io/argusdspm/argus-agent:stable (pin to a specific release tag for production).