All features Active Defense

From detection to a guarded, one-click response

Turn a real finding into a scoped action — disable a compromised Microsoft 365 account, for example — with one difference that matters: every change is operator-approved, fully audited, and reversible. Nothing fires on its own.

Get started See the platform
8guardrail guarantees
0actions without approval
100%audit-logged & reversible
active-defense · action 1
ACTDisable compromised M365 accountAWAITING
PRERead-only preview capturedDONE
APROperator approvalPENDING
RVTReversible · rollback readyREADY
Detection to response

Close the loop — without leaving the console

When a finding warrants action, you don't jump into a separate admin portal and hope you undid it correctly. You propose the action, review a read-only preview, approve it, and execute — all inside SBCMSP. The M365 action runs server-side, with no endpoint agent to deploy.

Propose & preview

Proposing an action runs a read-only preview first — it resolves the exact target, runs per-action safety checks, and captures the before-state for rollback. Nothing is changed at this step, and an action that fails preview never gets created.

Approve, then execute

A separate, audited approval by an owner or admin is required before anything can run. Execution only proceeds from an approved action — never straight from a proposal — so a human is always the last step before a change.

Verify & reverse

After a change, the engine re-reads the provider to confirm it actually took effect. Every reversible action carries a rollback reference — one call restores the prior state and re-verifies it, so a wrong call is never a dead end.

The guardrail spine

Guardrails first — every action runs through the same engine

The safety spine was built before any capability was plugged into it. No action that changes a customer's environment can bypass it — and every new capability we ever add has to pass through these same checks.

Allow-list only

Only action types explicitly registered in the engine can ever run. Anything unrecognized is rejected the moment it's proposed — there is no generic "run arbitrary command" path.

Read-only preview first

Nothing can be approved or executed until a mandatory preview has read the target and captured its current state. The preview fails fast, so a bad target never becomes a pending change.

Human approval required

A strict state machine — proposed, approved, executing, succeeded — gates every step with an optimistic lock. Execution runs only from an approved state, and a lost race is refused rather than double-executed.

Scoped to role & tenant

Every route is owner/admin-only — technician, analyst and read-only viewer roles are blocked — and gated to the Command tier. Each action is bound to a connection your account owns; an action id from another tenant simply resolves to "not found".

Refuses dangerous targets

Each action carries its own safety checks. The M365 action refuses to disable any account holding a privileged directory role — and refuses if it cannot confirm the account is non-privileged. Privileged accounts are handled manually, out of band.

No consent, no change

If the connected app lacks write permission, the engine catches the refusal, records the reason, and returns the action to "approved" having mutated nothing. A missing scope blocks the change — it never leaves things half-done.

Full audit trail

Who approved what, when — and the outcome

Every transition in an action's life is written to the account audit log — proposed, approved, rejected, executed, blocked, failed, and rolled back. Nothing changes silently, and the record shows exactly who signed off and what happened next.

  • Every state change logged, end to end
  • Approver and timestamp on every action
  • A blocked or failed attempt is recorded too
  • Rollbacks re-verify and are logged as their own event
See the full platform
account_audit_log · action #a3f9
remediation_proposed10:41
remediation_approved10:43
remediation_executed10:43
remediation_rolled_backlater
approved_by · owner · reversible ✓
Available now · Command tier

What it can do today — a deliberately short list

We would rather ship one action we can fully stand behind than a long menu we can't. The catalog is intentionally conservative: every capability is a single registered action that must pass the same preview, approval, execution, verification and rollback contract.

Disable a compromised M365 / Entra account

Set a stale or rogue Microsoft 365 / Entra user to disabled, server-side, in a connected tenant. It's reversible, refuses privileged accounts, and needs no endpoint agent. This is the live action today.

Conservative by design

Adding a capability isn't a code sprawl — it's one registry entry with its own preview, execute, verify and rollback steps, wired into the same spine. Nothing ships that can't be previewed, approved, and reversed.

On the roadmap, same contract

Further actions — disabling a stale cloud identity, revoking a risky app grant, forcing a credential reset — are planned to follow the exact same approve-then-verify guardrail. They are on the roadmap, not live yet, and we'll say so until they are.

In plain terms

What Active Defense will not do

Response tooling earns trust by being clear about its limits. Here is what this feature deliberately will never do.

No autonomous action

Nothing runs on its own. There is no unattended or auto-execute mode — a human approves every single change before it happens, without exception.

No hack-back, ever

Actions only touch your own connected tenants — like a user in your Microsoft 365. It never reaches out to probe, counter-attack, or retaliate against anyone. This is defense, not offense.

Nothing without approval

No unapproved action runs, no unregistered action type is allowed, and if the write permission is missing it blocks and changes nothing. When in doubt, the guardrail refuses to act.

Response, with a human in the loop

Turn detection into a scoped, reversible action — approved by you, audited end to end, and never fired on its own.