Recommendations & remediation

The other pages in this section explain how Argus decides something is wrong. This one explains how it decides what to do about it, and what happens when you let it act.

If you want the screen-by-screen version instead, see Recommendations and Remediation. This page is the engine underneath both.

A recommendation is derived, never authored

You cannot create a recommendation, and you cannot close one by hand. Both follow from the same design decision: a recommendation is a statement about current posture, not a task someone filed. If it were a task, it could outlive the condition that justified it, and a backlog full of already-fixed items is worse than no backlog at all.

So the lifecycle is driven from the finding end:

signal  ──►  template matches  ──►  instance for THIS subject  ──►  condition clears  ──►  resolved
(scan,       (a rule in the         (a bucket, a role)             (next scan)          (automatic)
 IAM          recommendation
 analysis)    registry)

Every recommendation traces back to a template in a single registry, identified as REC-<DOMAIN>-<NNN>. A template carries the problem framing and the fix framing together - the risk factor it describes and the actions that address it - deliberately as one object, so an identity’s listed risk factors and its listed recommendations cannot drift apart into two different stories about the same finding.

A template also declares which subject types it applies to. Most are about datastores; the IAM templates are about identities. A recommendation never attaches to a subject its template does not cover, which is why you will not see an identity fix hanging off a bucket.

Why they group by fix, not by resource

One recommendation row is one kind of fix, with a count of affected subjects behind it.

This is a deliberate inversion of how findings are usually presented. Forty findings that all say “enable encryption on this bucket” describe forty tickets. One recommendation that says “enable encryption”, covering forty buckets, describes a single afternoon with a single workflow. The grouping is what turns a list into a plan, and it is also what makes automation tractable: a fix that applies to forty subjects is worth wiring once.

What makes an action automatable

Each action on a template falls into one of three categories, and the category is derived at runtime from what the platform can actually execute - never stored on the template:

Category	Meaning
Remediable	A supported platform action can perform this fix
Manual	A genuine fix step, but nothing on the platform can perform it - do it by hand
Advisory	Ongoing guidance or verification, not a discrete fix at all

Deriving rather than storing matters. When support for a new action type ships, every existing template whose action matches it is promoted to remediable automatically. Nothing has to be re-labelled, and no template can claim an automated fix the platform cannot actually run - the common failure mode of a static capability list that drifts away from the code behind it.

Advisory actions are why some recommendations have no Run button and never will. “Review these grants quarterly” is real advice and a real recommendation; it is not something a machine performs.

Remediation versus mitigation

A workflow’s steps are classified by what they do to the underlying problem:

• Remediation removes the cause. Encrypting an unencrypted bucket means the bucket is now encrypted.
• Mitigation reduces exposure without removing the cause. Quarantining a public bucket behind a restrictive policy leaves the data as sensitive as it was; it just stops the bleeding.

A workflow that mixes both is labelled Mixed. The distinction is surfaced rather than smoothed over because it changes what “done” means: a mitigated finding is contained, not fixed, and an auditor will ask which one you did.

Safety is layered, and the defaults are conservative

Automated change to a customer’s cloud is the highest-consequence thing Argus does, so the controls compound rather than replace each other: run mode, an approval gate, dry-run by default, halt-on- failure, and a cap on resources per run. The per-control detail lives in the Remediation walkthrough.

Two properties are worth understanding at the engine level:

Capability is checked at dispatch, not at design time. You can build and enable a workflow whose actions the deployed agent has no permission to perform. That is intentional - design should not be blocked on a permission you are about to grant - so the check happens when a run is actually dispatched, against the agent that would perform it. A workflow is not a promise that the fix will work; the dispatch gate is.

A fix Argus cannot perform is still worth naming. Manual and advisory actions are shown with the same weight as automatable ones. Hiding them would make the product look more capable and leave the customer less secure, which is the wrong trade in a security tool.

Closing the loop

This is the part that is easy to get wrong, so it is worth being precise about.

A single template is commonly asserted by several independent sources at once: an encryption recommendation can be raised by an encryption alert, by a policy violation, and by a compliance control, all for the same bucket. If any one of those producers were allowed to resolve the recommendation, it could mark the finding handled while the other two still assert it - a silent false close on a live problem.

So producers can only ever assert. A single reconciler owns resolution, and it resolves a recommendation only when no remaining source asserts it. Completing a remediation run does not itself close anything: the run changes the cloud, the next scan observes the changed cloud, and the recommendation resolves because the condition genuinely cleared.

The practical consequence is the one users notice first: you cannot close a recommendation yourself, and a fix you applied outside Argus will still close it. Both are the same property. The system is reporting what it can currently observe, not tracking what anyone claims to have done.

Where to go next

• Recommendations walkthrough - the page, the drawer, the statuses
• Remediation walkthrough - workflows, runs, approvals, rollback
• Risk engine - where the severity on a recommendation comes from
• Compliance mapping & scoring - how controls raise recommendations