Remediation

Remediation is where Argus stops describing problems and changes your cloud. Everything on this page is built around that: the defaults are cautious, the gates are explicit, and the actions that write are separated from the actions that only look.

Four tabs: Workflows (the fixes you define), Runs (what happened), Templates (starting points), and Legacy (review) for pre-existing remediation records kept for reference.

Remediation is off until two separate gates are open

A fix runs only when the tenant has remediation execution enabled and you hold remediation:execute. Both, independently. The tenant switch is deliberate: it lets you deploy Argus in read-only mode, get value from discovery and compliance, and enable writes later once you trust it.

There is also a third gate outside the product: the agent’s role needs the ArgusRemediationWrite IAM statement. Omit that statement and remediation cannot execute or roll back, while everything else works normally. See IAM permissions.

Workflows

A workflow is a named fix: what it targets, what triggers it, the steps it performs, and the safety controls around it.

Statuses are Draft, Enabled, and Disabled. Only Enabled workflows are ever candidates to run, including for the run affordance on a recommendation.

Run modes

Mode	Behaviour
Manual	Only ever runs when a person runs it
Semi-auto	Triggers can queue it, but it still passes through the approval gate
Auto	Fires on its trigger and executes without approval. Admin only

Auto forces the approval requirement off, and the toggle is frozen while Auto is selected, because an auto workflow that waited for approval would not be automatic. That is why the mode is restricted to admins and carries an explicit warning in the builder: it is the one configuration where Argus changes your cloud with no human in the loop.

Semi-auto is usually what people actually want from “automation”: the system notices and prepares the fix, a person says go.

Triggers

Manual, Alert, Policy violation, Scheduled, or Recommendation. A trigger only decides when a workflow is offered or queued; it never bypasses the safety controls below.

Steps and actions

Steps are chosen from a fixed action set, bound to the target type:

S3 actions (datastore)	IAM actions (identity)
Block Public Access	Disable Access Key
Enable Encryption (SSE-S3, AES-256)	Remove IAM Policy
Enable Versioning	Enforce MFA
Restrict Bucket Policy (strip public Allow statements)

Each step can have rollback enabled individually, which is on by default.

Remediation versus mitigation

Every workflow carries a class, and you never set it. It is derived from the actions in its steps:

Class	Meaning
Remediation	Every step fixes the root cause
Mitigation	Every step applies a compensating control; the finding persists
Mixed	Both kinds of step

Enforce MFA is the mitigation case: it denies non-MFA actions, which contains the risk, but the user still has no MFA. Deriving the class from the steps rather than letting an author label it means a workflow cannot claim to fix something it only contains, and it is why a mitigation-classed run leaves its recommendation Mitigated rather than Resolved. See Recommendations.

Safety controls

Four of them, and the defaults are the conservative choice:

Control	Default	What it does
Require approval	On	A run waits in Pending approval until someone approves it. Not applicable to Auto
Default to dry-run	On	Users must opt into a live run each time
Halt batch on failure		When one execution fails, cancel the remaining pending ones in that batch
Max resources per run	10	Caps batch size to prevent a runaway operation

Halt-on-failure is the one people skip and later wish they had. If a fix fails on the first bucket because of something environmental, it will usually fail on the next ninety too, and halting turns one incident into one failure instead of ninety.

Max resources per run is the blast-radius cap. A wide-scoped workflow with a low cap is a safer combination than a narrow scope with an unlimited one, because the scope is what you intended and the cap is what protects you when the intention was wrong.

Running a workflow

The run modal lists the targets, lets you select which to include, respects the batch cap, and defaults to the workflow’s dry-run setting. Going live requires an extra confirmation step, and the button turns red.

A dry run tells you what would change without changing it. Run one first, read the result, then promote it.

Runs

Executions, with their full status lifecycle:

Status	Meaning
Pending approval	Waiting on a human
Approved	Cleared, about to be claimed
Awaiting agent	Queued, no agent has picked it up
Running	In progress
Verifying	Applied, confirming the result
Completed	Done
Failed	Did not complete
Cancelled / Rejected	Never executed
Rolled back	Reversed
Rollback failed	Reversal did not complete. Needs manual attention

The Verifying step is why remediation and detection agree afterwards: Argus confirms the change landed rather than assuming the API call succeeding meant the posture changed.

Actions on a run

Action	Available when
Approve / Reject	Pending approval
Run live	A dry run completed, within 24 hours
Re-run	A forward run that failed, rolled back, or failed to roll back
Rollback	A completed, live, non-rollback run, inside its rollback window

Three deliberate limits here, each of which will look like a missing feature until you know why:

There is no Cancel button, and that is not an oversight

Once approved, an agent claims the job almost immediately, so the cancellable window is about a second. A run that is already executing has no abort channel: half-cancelling a cloud API call would leave your resource in a state neither you nor Argus could describe.

So the recovery path for “I should not have run that” is Rollback, not cancel. That is an honest reversal with a verifiable result, rather than a stop button that might or might not have caught it in time.

Promoting a dry run to live expires after 24 hours

A successful dry run can be promoted with Run live for one day. After that the option disappears, because the dry run’s findings describe the cloud as it was then. State drifts: buckets change, policies are edited, resources are deleted. A day-old plan applied blind is exactly how automation causes an incident.

If the window has closed, run a fresh dry run. It costs a minute and it is describing reality.

Re-run is only offered on forward runs that actually executed and ended badly. It is deliberately not offered on rollbacks (re-running one would re-apply the fix you just reversed) or on cancelled and rejected runs (those never executed, so re-trigger from the workflow instead).

Rollback is capped by a rollback window stored on the execution, for the same drift reason as dry-run promotion: a reversal computed against long-gone state is not a reversal.

Every action is available from the row menu, a bulk selection, and the drawer footer, from one shared definition, so no surface can offer a set another one does not.

The execution drawer

Carries the target, the workflow, the steps with their individual outcomes, and an activity timeline including the evidence captured at each stage. That timeline is your audit answer for “who changed this, when, with what result”, and it is worth reading after a failure before re-running: the step that failed usually says why.

Templates

Starter workflows for the common fixes, so you are editing something sensible rather than starting from an empty step list. Creating from a template gives you a draft, with the same safety defaults, and nothing runs until you enable it.

Templates map to the standard fixes: block public access on S3, enable encryption, harden a bucket, handle a stale access key, reduce an over-privileged identity, enforce MFA.

A workflow that works

1. Start from a template where one fits.
2. Keep Require approval and Default to dry-run on, and set a Max resources per run you would be comfortable explaining after a bad day.
3. Turn on Halt batch on failure.
4. Leave it Manual or Semi-auto until you have watched it succeed several times. Reserve Auto for fixes that are genuinely safe and genuinely urgent.
5. Always dry run first, read the result, then Run live within the 24-hour window.
6. After a live run, check the execution reached Completed through Verifying, not just that it dispatched.