Eon’s agent has built-in remediation workflows that take your incident from start to end: leading the remediation, or working alongside your SOC agent over A2A. Here is what it does between the alert and the business being back, and the one place it deliberately stops.
03:00
At 03:00 on a Tuesday a detection fires. Nineteen resources across three accounts: a production database, a document store holding customer records, and seventeen machines in a build fleet.
Nobody is woken up.
By 03:04 a remediation plan exists. Scoped, ordered, parameterized, and waiting on one approval. The questions that normally cost an incident response team its night are answered before anyone has opened a laptop, not because the agent is clever, but because every one of those questions is a data-joining problem and the agent had the data.
This is not a roadmap section in disguise. The workflows are in the product.
One agent, orchestrating the whole remediation
Everything below is done by a single agent, and it is not a chat box bolted onto a runbook. It reads Eon’s own evidence about your data, trades what it knows with the other agents working the same incident, and drives the remediation from first detection to a verified-clean result. It stops in exactly one place: the approval it cannot grant itself.
The agent works through six tasks, numbered below, from scoping the infection to presenting the plan for approval.
It plans from evidence Eon has already collected. Every backup is examined before it is ever trusted, by independent detectors for anomalous behavior, malware, and ransomware inside the data itself, so each recovery point carries a verdict. Not a pile of snapshots, which is inert, but a timeline the agent can reason over.
01. Establish what is infected, and the blast radius
The agent counts and lists every flagged resource, then states the compromise window per resource as fact, not inference: the last recovery point that scanned clean, the first that didn’t.
It names the affected files, tables and databases, the recovery points involved, and the accounts, regions and policies in scope. Where the evidence supports a mechanism, it names one. Where it doesn’t, it reports what was observed and says so. An agent that invents narrative is worse than no agent, because you will act on the narrative.
02. Determine what is inside the data
Eon classifies the data it protects, so before proposing any order of work the agent knows which of the affected resources hold personal or regulated information. “This database holds patient records” changes the severity of an otherwise identical technical event, and it changes who you are obliged to notify.
03. Prioritize by severity and business impact
Nineteen affected resources are not nineteen equal jobs.
| Resource | Detection | Data | Business impact | Clean point | Order |
|---|---|---|---|---|---|
| Billing database | ransomware | PII | Revenue-critical | Mon 23:00 | 1 |
| Customer document store | ransomware | PII, PHI | Regulated, notifiable | Mon 21:30 | 2 |
| Build agents ×12 | ransomware | none detected | Delivery paused | Mon 23:40 | 3 to 14 |
| Artifact cache ×5 | anomaly | none detected | Rebuildable | Mon 23:40 | 15 to 19 |
Order is derived from detection severity and business impact together, and it arrives with its reasoning attached, not as a queue in whatever sequence the console happened to list.
Notification obligations run from the moment of compromise, not from the moment you finish recovering, so ordering is a risk decision. “This one first, because it holds regulated personal data and its window opened eleven hours ago” is defensible to a regulator, a board or an auditor. “It was at the top of the list” is not.
04. Detect the last clean snapshot, per resource
For every resource the agent resolves the most recent recovery point verified clean inside a window you choose, and states what returning to it costs in elapsed data. Resources with no clean point in that window are reported separately, never quietly swapped for an older one. Accepting more data loss is your decision, not the system’s.
Immediately before execution every selected point is re-checked, because verified clean must never be stale.
05. Resolve the remediation parameters
A recovery point is half a remediation. The other half is where the resource comes back to.
Eon provides a restore template per resource type: target account and region, subnet, machine size, encryption key, tags, naming, and whether the resource comes up running or stopped. Security teams pre-approve these ahead of an incident, and each one is re-validated against the live cloud environment before use. A pinned subnet that no longer exists stops the restore. It does not get guessed around.
The agent pre-selects every parameter from the templates. Where no template exists it doesn’t improvise a destination; it lists the missing parameters in the plan for a human to complete.
06. Present, wait, then restore in bulk
The plan is presented in full: resource, evidence, recovery point, destination, order. Then the agent waits for consent.
It holds no privileges of its own. It acts as the person who asked, bounded by their permissions and recorded like anyone else’s actions, and multi-person approval intercepts it exactly as it intercepts a human. The approval binds the exact request, down to the request body: change one parameter and it is rejected, approve it once and it runs once.
On approval it initiates the bulk restore across every resource in the plan and tracks the jobs. Pending is reported as pending, never as recovered. The incident closes not when jobs finish, but when the recovered resources have been backed up again, scanned again, and come back clean.
Two ways to run: Eon leads, or Eon assists
Eon leads. For a data-borne incident such as ransomware, mass deletion or a corrupted migration, the agent owns the playbook end to end. It draws on Eon’s own malware and ransomware scanning, hunts across snapshot history, plans the six tasks above, and executes them.
Eon assists. When the incident is bigger than the data, the agent connects over the A2A protocol to your SOC agent and your security agents, and contributes the half of the picture only it holds:
- Resource and snapshot inventory: what is protected, and every recovery point that exists for it.
- A verdict per recovery point, over time: when each resource’s data stopped being trustworthy.
- Threat hunting across snapshot history: any indicator they hand it, traced backwards through every snapshot.
- Mass restore: the ability to actually execute, once the group agrees on a point.
This is not integration for its own sake. It fixes the most common way recovery fails.
Monday 23:00 scans clean of ransomware and still holds the attacker’s foothold. Restore to it and you get a resource genuinely free of ransomware that still contains the backdoor, the harvested credential, the scheduled task. Days later you are encrypted again from inside your own recovery.
No single agent can avoid that. Eon knows the last clean point but not when the intrusion began. The SOC agent knows initial access was 02:14 Monday but not which recovery points predate it. The endpoint agent knows which machines the foothold reached and can’t recover anything. In conversation the answer arrives in seconds, and the nineteen resources split: the six the foothold reached go back to Sunday and accept twenty-one more hours of loss, and the thirteen it never touched keep Monday night.
Three agents, each holding one axis of the same incident, converging on a per-resource answer none of them could reach alone. In machine time, before anyone has finished making coffee.
Where this goes
Remediating nineteen resources is not the goal. The application serving customers again is the goal.
What comes next: remediation plans that understand dependency order rather than a flat batch. The connective tissue restored with the workload instead of after it, meaning endpoints, names, connection strings, and the identity a service needs before its neighbors will trust it. Readiness proven by continuous rehearsal rather than asserted at audit.
Eon already inventories the applications and versions running inside what it protects, which is what makes this a trajectory rather than a wish.
The end state is not faster restores. It is that the business keeps operating, the remediation happened underneath it, and a human said yes at exactly one moment.
Finally, making backups useful.
