Updating permissions

Argus has two things to keep current: the agent, which updates itself on stable, and its IAM permissions, which only you can update. This page covers the permissions. For the agent image, see Updating the agent.

Why this needs you

A new agent version can check things the old one did not, and a new check can need a permission your stack does not grant yet. The agent updates itself; its IAM role does not. CloudFormation, Terraform and your own policies change only when someone applies them, so a stack deployed months ago grants what the template granted then.

Until the role is updated, the checks that need the new permissions read Not Verified in Argus. Scans keep running, nothing is lost, and every other check still reads normally.

How Argus tells you

Each agent checks its own role after it starts on a new version. It asks AWS, through iam:SimulatePrincipalPolicy, whether its role allows each action this version needs, and checks the database credential actions against the ARN of each database you gave Argus a credential for. Nothing is called for real, and nothing is changed. One action is not simulated, because the simulator misreports it: s3:ListAllMyBuckets, whose refusal shows up as a failed bucket listing instead. So when nothing is missing, the window says Current: every checked permission is held.

When something is missing:

• Cloud Accounts shows a chip on the account: Missing N, where N is the number of permissions the role lacks. If nothing is missing but a policy on your side blocks some, the chip reads Blocked N instead. Open it for the list, grouped by the checks each permission blocks.
• Administrators get one Agent Permissions Behind notification per account for each new permission set. Re-checking the same set does not notify again.
• A permission denied by a policy on your side, such as a service control policy or a permissions boundary, is listed separately as Blocked by a policy on your side. Updating the stack does not change those: your AWS administrator has to allow them.
• A database ARN that Argus holds a credential for but the role does not grant is listed as Database ARNs not registered, and sends no notification. A template update keeps your parameter values, so add each ARN to the DatabaseCredentialArns parameter when you update the stack (on a hand-built role, to the ArgusDatabaseCredentials statement). Adding or removing a database credential in Argus checks the role again.

Argus reads denials from service control policies only as far as AWS’s policy simulator reports them. If a check reads allowed but a scan is still refused, look for an SCP or a resource control policy.

Update a CloudFormation stack (managed Fargate or EC2)

The button

In Cloud Accounts, open the chip and press Update stack in AWS. It opens the AWS console’s Update stack form for your stack, in its own region, with Replace current template selected and the right template URL filled in. Your existing parameter values are kept, including the enrollment token.

The template URL is the one for your stack’s version. Argus tells v1 and v2 stacks apart from the agent’s role, and never offers a v1 stack the v2 template.

No console access to this account? Press Copy link and instructions and send them to the account owner.

Which template URL

If you update by hand, use the template for the version your stack was created with:

Stack	Created	Template URL
Fargate v1	before 2026-08-21	https://argus-cfn-templates.s3.us-east-1.amazonaws.com/argus-managed-fargate-v1.yml
Fargate v2	from 2026-08-21	https://argus-cfn-templates.s3.us-east-1.amazonaws.com/argus-managed-fargate-v2.yml
EC2 v1	before 2026-08-21	https://argus-cfn-templates.s3.us-east-1.amazonaws.com/argus-managed-ec2-v1.yml
EC2 v2	from 2026-08-21	https://argus-cfn-templates.s3.us-east-1.amazonaws.com/argus-managed-ec2-v2.yml

Not sure which you have? A v2 stack’s roles have the path /argus/; a v1 stack’s roles have the path /.

Never move a v1 stack to the v2 template

v2 gives every role a new path and name, so CloudFormation deletes the agent’s role and creates a new one with a different ARN. See Do not re-point an existing stack at the v2 template.

Use existing template does not pick up new permissions. It re-applies the copy CloudFormation stored with your stack, which is as old as your last update. Choose Replace current template and use the URL above.

Review the change set

Check the change set before you apply. It should modify the agent’s IAM policies and, on older stacks, its security group. With burst autoscaling on, it also lists the ECS services, task definitions, alarms and scaling policies. If a row for a role, instance or instance profile says Replacement: True, cancel and contact support.

On Fargate, task definition rows that say Replacement: Conditional are expected.

Updating an older stack also adds outbound rules for database ports 5432, 3306 and 5439. If Argus scans no databases in this account, set DatabaseEgress to false in the update.

From the AWS CLI

The same update as a change set, keeping every existing parameter value. List each parameter your stack has with UsePreviousValue=true; a parameter the newer template adds, such as DatabaseEgress, takes its default unless you set it.

aws cloudformation describe-stacks --stack-name <stack-name> --region <region> \
  --query 'Stacks[0].Parameters[].ParameterKey' --output text

aws cloudformation create-change-set --region <region> \
  --stack-name <stack-name> --change-set-name argus-permissions \
  --template-url <template URL for your version> \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameters ParameterKey=<Key1>,UsePreviousValue=true ParameterKey=<Key2>,UsePreviousValue=true

aws cloudformation describe-change-set --region <region> \
  --stack-name <stack-name> --change-set-name argus-permissions

aws cloudformation execute-change-set --region <region> \
  --stack-name <stack-name> --change-set-name argus-permissions

What you need in AWS

The person applying the update needs cloudformation:CreateChangeSet, DescribeChangeSet, ExecuteChangeSet and DescribeStacks on the stack, and, unless the stack uses a CloudFormation service role, permission to change the agent’s IAM role policies and its security group’s egress rules.

Terraform (Cloud DIY)

Bump the module ?ref= to the release that adds the permissions and apply. The plan should change only the agent role’s policy.

A role you built yourself

Which mode am I in?

An Argus CloudFormation stack names the agent’s role ArgusAgentTask-<stack> (Fargate), ArgusAgentRole-<stack> (EC2, v2) or <stack>-AgentInstanceRole-<suffix> (EC2, v1). Any other role, including one you named ArgusAgentRole yourself, is hand-built, and the Agent role permissions window shows the missing permissions as a policy in JSON.

Do not edit the policies of a role that an Argus stack created: update the stack instead, as above.

Add one new policy

Your role’s permissions may come from several policies, and Argus cannot know their names, so do not edit an existing one. Create one new policy instead:

1. In the AWS console, go to IAM, Roles and open the role the agent runs as: the task role or instance role you gave the agent when you deployed it.
2. Go to IAM, Policies, Create policy and choose the JSON tab. Paste the policy from the Agent role permissions window, name it and create it. The window suggests a name for the agent version that needs it, such as ArgusAgentPermissions-1.3.0; you can use your own. If a policy with that name already exists, add the statements to it instead.
3. Back on the role, choose Permissions, Add permissions, Attach policies, select the new policy and add it.
4. In Argus, press Re-check. The chip clears once the role grants every missing permission.

The policy holds only what was missing, so each update adds one more policy named for its version; keep the earlier ones.

Each statement keeps the resource scope Argus needs, so do not widen it to * unless that window does. A permission listed under Blocked by a policy on your side is an explicit deny from a service control policy or a permissions boundary; a new policy does not fix it, and your AWS administrator has to allow it.

After the update: Re-check

When the update finishes in AWS, press Re-check in the Agent role permissions window. Otherwise Argus checks again by itself only when the agent next updates, or when you add or remove a database credential. The chip clears when the role grants every permission the check covers; checks that read Not Verified read normally after the next scan.

Re-check needs the Re-check the agent role’s permissions permission, which System Administrators and Security Managers hold.

Partners and MSPs

A partner seat sees the same chip and list for each customer account. The update runs in the customer’s AWS account, so it needs someone with access there: use Copy link and instructions and send them to the account owner.