.png)
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. 19 resources across 3 accounts: a production database, a document store holding customer records, and 17 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 isn’t a vision or a future roadmap, it’s the product today. The workflows are already built in and available now.
One agent, orchestrating the whole remediation
Everything below is done by a single agent. 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. The agent presents the remediation plan, then waits for your consent before taking action.
The agent works through 6 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.
1. 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.
2. 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.
3. Prioritize by severity and business impact
19 affected resources are not 19 equal jobs.
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.
4. 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.
5. 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.
6. 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.
Agent versus agent
One more thing is coming, and it changes the arithmetic. The attacks are being automated too: reconnaissance, credential abuse, lateral movement and encryption, at machine speed and machine scale. An intrusion that executes in minutes cannot be answered by a recovery that takes a night of human archaeology. When the adversary is an agent, the defense has to be one as well; a human-paced response to a machine-paced attack is a loss with extra steps.
That is not an argument for taking the human out. It is an argument for making the human the only slow thing left. Everything before the decision collapses to seconds, because it has to: the scoping, the ordering, the classification, the clean point, the plan. The decision stays yours. It just arrives with everything you need to make it.
