Proposal-first remediation: autonomy you can approve

Why auto-containment backfires

Automated response is usually wired to detection: when a rule of a certain kind fires with high severity, isolate the host, block the address or disable the account. On paper this closes the gap between detection and action. In practice it inherits every weakness of the detection that triggers it.

A large share of what looks suspicious in endpoint and network telemetry is ordinary operations. A database engine deleting old backup files through a command shell looks like destructive activity. A software update writing many files in a second looks like a dropper. An administrator using remote management tools looks like lateral movement. When teams review the containment actions their automation proposed, they commonly find that most of them would have landed on legitimate work.

The cost is asymmetric. Missing an attack for a few minutes while a person reviews a proposal is rarely what decides an incident. Isolating a production database, locking out a finance team at quarter end or blocking a partner’s gateway can cause an outage that is larger than the threat, and it erodes trust in automation for years.

What goes wrong underneath

Looking at failed automatic responses, the same patterns recur. Actions are triggered by a single alert rather than by a confirmed story. Severity alone is treated as a reason to act. Rule names that match a known attack tool are trusted even when the context shows a sanctioned use. Repeated, routine behaviour that has happened every night for months is not recognised as routine. And the target of the action is sometimes not even resolved precisely, so the action is aimed at a category rather than at a specific host or account.

None of these are problems of the response tooling. They are problems of judgement upstream of it. That is why the fix is not only better playbooks but a different contract between the system that decides and the system that acts.

Separating the decider from the actor

A useful design principle is that the component that reaches conclusions should never be the component that changes systems. The analytics, models and correlation logic produce proposals. A separate, narrow response layer is the only place that can execute, and it does so only for approved actions, through standard contracts: input, pre-checks, dry run, execution, post-verification, rollback and audit.

This separation has practical benefits. Credentials with write access live in one small, auditable place. Every action, whoever or whatever proposed it, follows the same path. And integrations with firewalls, EDR, identity providers and email systems can be built once, tested with mocks, and enabled one action class at a time.

Growing autonomy safely

Proposal-first does not mean manual forever. It means autonomy is earned, action by action:

• Start in observe mode: record what would have been proposed and compare it with what the team actually did.
• Enable the lowest-risk, most reversible actions first, such as time-limited blocks of clearly external addresses.
• Begin each newly enabled action class with a small, capped trial before widening it.
• Keep protected lists of systems and accounts that are never acted on automatically.
• Make every enabled action easy to switch off and every executed action easy to undo.
• Report plainly whether an action was applied, failed or was refused.

How ApexAI approaches it

ApexAI Drawbridge is ApexAI’s proposal-first remediation capability. Today it prepares response proposals with evidence, preconditions, expected effect and rollback in observe mode, so your team can judge what it would have done. Proposals are built from confirmed stories rather than single alerts, and routine operations such as backups and known authorised scanners are recognised. Executing approved actions through your existing EDR, firewall and identity tools is in development, off by default and enabled per action class only by your decision, with every step audited.

Questions