Remediation & Blocks

Slim.io doesn’t stop at discovering sensitive data — it can act on it. When a finding matches an enforced policy, Slim.io can alert, tokenize, mask, quarantine, or block access to the exposed resource automatically. Every action is recorded with a signed receipt, governed by controls you own, and — for reversible and destructive actions — captured as a Last-Known-Good snapshot so it can be undone.

This page explains the remediation lifecycle and the three tenant-level controls you configure in the Customer Dashboard (/dash/): the rollback window, the remediation policy (safety-class deny-list), and receipt co-signing.

The remediation lifecycle


Finding (scan or drift event)
  → Policy selects a remediation action
    → Safety-class check (your remediation policy / deny-list)
      → Optional co-signing (Tier-3, if you require it)
        → Action executes  →  signed receipt
          → Last-Known-Good snapshot captured (reversible/destructive actions)
            → Undo available for the length of your rollback window

Detect — a scan or drift event produces a finding that matches an enforced policy.
Decide — the policy selects an action: alert, tokenize, mask, quarantine, or block.
Authorize — the action’s safety class is checked against your remediation policy. If you’ve denied that class, the action does not run.
Co-sign (optional) — if you’ve enabled receipt co-signing, high-assurance receipts are co-signed against your endpoint before the action is finalized.
Act — Slim.io executes the action and writes a cryptographically signed receipt to the audit log.
Snapshot — for reversible and destructive actions, a Last-Known-Good (LKG) snapshot is captured first.
Undo — within your rollback window, the action can be reversed and the snapshot restored.

Blocks

A block is a remediation that isolates a resource — cutting off access to data that is exposed or out of policy — rather than transforming it in place. Blocks are reversible: each one captures a Last-Known-Good snapshot, so lifting a block restores the resource to its prior state.

You can review and lift active blocks from Settings → Blocks in the Customer Dashboard. Lifting a block (“undo”) is available for the duration of your rollback window.

If a block’s rollback window has already elapsed, or you need help reversing one, Slim.io support can assist. Reach out through your normal support channel — blocks are never permanent without your awareness.

Safety classes

Every remediation action is tagged with a safety class that describes how impactful and how reversible it is. Safety classes are what the remediation policy (deny-list) operates on — they let you forbid a whole category of automated action in one place.

Safety class	What it means	Examples
`read_only`	No change to your data	Inspect, classify, generate a finding
`reversible`	A change that can be fully undone from a Last-Known-Good snapshot	Tokenize, mask, quarantine, block
`destructive`	A change that may not be fully reversible	Delete, purge
`infrastructure`	Changes to infrastructure or connector configuration	Reserved
`governance`	Changes to policy or governance state	Reserved
`inline_runtime`	Inline data-plane actions at runtime	Reserved

Enforcement scope today. The remediation policy currently enforces three classes — read_only, reversible, and destructive — because those are the only classes the automated executor produces today. The other three (infrastructure, governance, inline_runtime) are reserved for future remediation types: you can select them now, but they don’t yet gate any automated action. The dashboard labels them accordingly, and the API reports exactly which classes are enforced (see enforceable_safety_classes).

Last-Known-Good & Undo

Before Slim.io makes a reversible or destructive change, it stores a Last-Known-Good (LKG) snapshot of the affected resource. Within your rollback window you can undo the action with one click and Slim.io restores the snapshot. The same window governs how long the underlying snapshot data and the undo capability are retained — after it elapses, both expire and the action becomes permanent.

You choose the length of that window with the rollback window setting below.

Configuring remediation

All three controls live in Settings in the Customer Dashboard and require the Admin role. They reflect Slim.io’s ownership model: you decide what happens in your environment, and Slim.io provides the platform that enforces it.

Who controls what. You own the decisions — which safety classes to deny, whether to require co-signing, how long to retain rollbacks. Slim.io owns the platform — key management, certificate provisioning, and enforcement. Slim.io never decides what happens in your environment.

Rollback window

Settings → Rollback window. Choose how long Last-Known-Good snapshots and the undo capability are retained for your tenant:

Option	Value	Notes
24 hours	`24`	Default
72 hours	`72`
7 days	`168`	Maximum retention

A longer window gives you more time to review and undo automated remediation, at the cost of retaining snapshot data for longer. The window applies to all reversible and destructive actions, including blocks.

Remediation policy

Settings → Remediation policy. Forbid entire safety classes of automated remediation for your tenant. Tick a class to deny it; any remediation whose action falls in a denied class will not run for your tenant.

You have full control over all six classes. The dashboard surfaces strong warnings on the two that carry the most risk:

Denying reversible blocks most automated remediation. Tokenize, mask, quarantine, and block are all reversible actions — denying this class means your data may stay exposed during an incident until you act manually. Denying read_only provides no security benefit and may break inspection.

The deny-list fails open: if Slim.io cannot read your policy for any reason, remediation proceeds as normal rather than being silently blocked. This ensures a configuration error never quietly disables your protection. Every change is written to the audit log (remediation_policy_changed, with the prior and new denied lists).

Receipt co-signing

Settings → Receipt co-signing. For the highest assurance, you can require that remediation receipts be cryptographically co-signed by your own endpoint before they are finalized — so no high-assurance action is considered complete without a signature from infrastructure you control.

Mode	Behavior
`disabled`	No co-signing (default)
`optional`	Receipts are co-signed when your endpoint is reachable
`required`	Receipts must be co-signed; the action is not finalized without it

You set the mode and your co-signing endpoint URL. Slim.io provisions the mutual-TLS (mTLS) certificates that secure the connection — that’s the platform half of the handshake.

Provisioning handshake. You cannot select optional or required until Slim.io has provisioned the mTLS certificates for your tenant. If you try, you’ll see a “co-signing provisioning incomplete” message — contact Slim.io to complete provisioning, then set your mode. Your dashboard shows a platform-provisioned indicator so you always know the current state. (Slim.io never exposes the certificate material itself — only whether provisioning is complete.)