Scanning and installing patches

Patching in AegisOne is a three-part loop: scan to establish position, install to close gaps, and inventory to retain the evidence. Each part is driven from the console or the API against a specific endpoint.

A scan asks the endpoint what it is missing and returns the result into the per-endpoint patch inventory. Scan before you install, even when you are confident about what is missing. Patch state changes without your involvement — users install updates, other tools intervene, machines that were offline for a fortnight come back substantially different — and installing against a stale picture is how you end up applying something twice or missing something entirely.

# Scan a single endpoint
curl -X POST https://<your-console-host>/api/agent/<endpoint_id>/patch/scan \
  -H "Authorization: Bearer $AEGISONE_TOKEN"

# Review the resulting position
curl https://<your-console-host>/api/patches?endpoint_id=<endpoint_id> \
  -H "Authorization: Bearer $AEGISONE_TOKEN"

Installation is dispatched to the endpoint and recorded in the action log with the operator identity attached. Uninstall is available for the cases where a patch turns out to be the cause rather than the cure.

curl -X POST https://<your-console-host>/api/agent/<endpoint_id>/patch/install \
  -H "Authorization: Bearer $AEGISONE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"patch_ids":["<patch_id>"]}'

Sequence your rollouts. Patch a small representative group first, leave enough time for a problem to surface, then widen. The right length of that gap is however long it takes your users to notice something is wrong and tell you, which is usually one working day and never the twenty minutes it is tempting to allow.

Patch inventory persists after installation, and that persistence is what makes the compliance story work. When an auditor asks whether a particular update was applied across the estate and when, the answer comes from retained inventory rather than from someone reconstructing it from change tickets.

One boundary to plan around: AegisOne does not schedule patch waves for you. There is no automation scheduler in the product. Patch operations are initiated on demand from the console or driven from the API by something on your side that owns the schedule.