Stop Destructive and Irreversible Agent Actions

To stop AI agent destructive actions, you first have to draw the line that separates them from everything else an agent does. A destructive action is any operation you cannot roll back with a support ticket, a Git revert, or a permissions restore. Once it completes, the state of the system has changed for good, and recovery means a backup, a legal call, or both. Reading a record is not in this class. Dropping a production table is.

The class breaks down like this:

Reversible vs irreversible: the line that sets the control model

Reversible actions can tolerate detection and review. If an agent creates a bad draft or runs an unnecessary query, a false negative costs you an alert investigation and nothing more. Irreversible actions cannot tolerate that latency. A false negative costs a breach or an outage.

The test is simple. If the recovery path involves a backup restore, legal counsel, or a public disclosure, the action needs enforcement. If the recovery path is "undo," detection is enough. That single distinction decides which control model you owe each action, and most programs never draw it explicitly.

Detection pipelines were built around a human analyst who reads an alert, investigates, and responds. That loop assumes minutes are available. Against an agent, they are not. An agent that receives a prompt can list its tools, select a destructive one, and fire it inside one second. By the time a SIEM correlates the event, the table is already gone and you are reading a headstone.

This is ghost chasing in its most literal form. The team sees a log line that says "agent X called tool Y," and they see it after the fact. They cannot say whether the call should have been allowed, and they certainly cannot un-execute it. A record of a deletion is not a control over a deletion.

Human-in-the-loop review still works for reversible workflows, where a delay before approval costs nothing. For irreversible ones, the only control that holds is enforcement in the same execution path as the agent, running at the same speed the agent runs. Anything that sits outside that path is forensics.

Industries where the window is smallest

The exposure concentrates in regulated data holders and infrastructure operators. Financial services carry irreversible transactions. Healthcare carries PHI that cannot be un-exfiltrated. Critical infrastructure carries production changes that take plants offline. SaaS platforms carry customer data whose destruction is someone else's disclosure event. Any environment where a few seconds of agent misbehavior triggers a regulatory obligation belongs at the top of the list, because for them the gap between "alert fired" and "damage done" is the whole ballgame.

Theoretical configuration is what an agent looks like on paper. Effective access is what the agent can actually do inside the third-party app once every token, role, and inherited credential resolves at runtime. The gap between the two is exactly where destructive actions live, and it is the gap a vendor's config page will never show you.

Take a Copilot Studio agent labeled "reporting." A report-only tool sees the agent, sees it wired to Snowflake, and marks it low-risk because its stated purpose is read-only. Here is what that reading misses:

1. The connector was built in maker mode, running on the creator's admin service account rather than the invoker's identity.
2. That service account holds DROP and DELETE privileges on production tables.
3. Any user who can invoke the agent inherits the service account's authority at execution time.
4. A prompt as ordinary as "clean up the old staging tables" is enough to resolve into a destructive SQL call.

Report-only tooling tells you "an agent touched Snowflake." Runtime truth tells you "the agent invoked service account SA_ADMIN to run DROP TABLE customer_archive." The first is a log entry you read later. The second is a specific call, tied to a specific non-human identity and a specific object, that you can block before it lands. Correlating the agent's activity to its effective access, not to its theoretical configuration, is what turns a vague risk score into an enforceable decision.

Runtime enforcement hooks into the AI platform through its native webhooks and APIs. When the agent selects a tool and prepares to invoke it, the enforcement layer intercepts the call, evaluates it against deterministic rules, and returns a decision inside a one-second window. The call reaches the target system only if the decision is allow.

The rules are fixed, which is the entire point. A probabilistic agent cannot talk its way past a deterministic policy. A rule that says "no DROP from any agent using a shared service account" evaluates the same way every time, no matter how the prompt was worded or which model chose the action. That determinism is what lets a machine-speed control keep pace with a machine-speed actor.

Obsidian is not an inline network gateway. It runs an Intel Inside decision-engine model: the platform makes the call, the platform enforces the verdict, and the decision engine supplies the verdict against your policy.

Truth in labeling, because it matters here. Runtime block is live today for Claude and Microsoft Copilot only. For Salesforce Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Amazon Bedrock, Google Vertex, and n8n, Obsidian discovers every agent, maps its effective access, and governs it with risk detection. In-flight enforcement for those platforms is on the roadmap, not available today. Any vendor claiming universal in-flight blocking across every agent platform right now is overstating what exists.

The four-layer stack behind an enforceable block

An in-flight block is only as good as the layers underneath it:

1. Inventory. You cannot block what you cannot see. Every agent, every MCP server, every connector gets mapped, including the shadow agents no ticket ever created.
2. Effective access mapping. Know what each agent can actually do inside the app, not what its config claims. A maker-mode connector holding sensitive privileges gets flagged critical on sight.
3. Deterministic runtime rules. Fixed policies, such as no DROP, no org-wide grant, no external push above a set threshold, evaluated on every tool call.
4. In-flight block. The engine returns deny before the call reaches the target system, not after the log arrives.

Strip any layer and what remains is logging. Logging is fine for forensics. It does nothing about irreversibility.

Why sandboxing does not apply to SaaS-native agents

Sandboxing works for agents you build and host yourself. It does not work for the agents most enterprises actually run, because those agents live inside third-party platforms the security team does not administer. You cannot wrap a network sandbox around an agent executing inside Microsoft's tenant. The control that fits this class is runtime authority enforcement: constraining what the agent can invoke, not what network it can reach. It is also why proxy and gateway approaches fall short here. The destructive call never leaves the platform to cross a network boundary a proxy could see.

Frameworks to align your rules to

When you write deterministic rules, anchor them to work the field has already done. OWASP's Top 10 for Agentic risks and its low-code/no-code security guidance both speak directly to account impersonation and excessive data access, which is what maker mode produces. NIST's AI Risk Management Framework, ISO 42001, and MITRE ATLAS give you a vocabulary for the same failure modes. Aligning rules to these lets you show an auditor why a policy exists, not just that it fires.

The reason teams hesitate to turn on enforcement is fear that a block will break the workflow around it. That fear is legitimate, and the answer is surgical remediation: kill the one destructive call, leave everything else running. One control plane deciding per action, so the report the user asked for still runs and only the DROP dies. Fewer fire drills, because the incident never becomes an incident.

When to enforce and when to route for approval

Not every consequential action is machine-speed critical. Between "always allow" and "always block" sits the approval workflow, and it belongs on actions that are heavy but not instantaneous: a purchase order over a threshold, a permission grant to an external user, a deploy during a change freeze. Design them with three constraints. Route to a named human, never a group inbox, because group inboxes die. Default to deny on timeout, never to allow. Log the requesting agent, the invoking user, and the effective access the action would use, because without that last field an approver is guessing.

The decision rule stays clean. If the action is irreversible, enforce it with a deterministic rule and do not wait on a human. If it is reversible and consequential, route it for approval. If it is reversible and routine, log it and move on.

Rollback is a last resort

When a destructive action does get through, rollback is damage control, not strategy. Pull the exact tool call from runtime logs rather than configuration audits. Trace the invoking user and the effective access used, where a maker-mode incident shows a mismatch between who ran the agent and whose credential it spent. Restore from backup for data loss and revoke the service account's session tokens. Then add a deterministic rule blocking that exact pattern before you re-enable the agent. That final step is the one most programs skip, and skipping it is why the same incident recurs.

Common mistakes that break the workflow

• Treating agent inventory as a one-time project. Agents proliferate weekly.
• Trusting platform-native logs as sufficient. They are siloed and need manual correlation before they mean anything.
• Reading an agent's stated scope instead of measuring its effective access.
• Leaving agents in maker mode by default because it was easier during the pilot.
• Blocking with a raw error that crashes the agent and sends the response chain into hallucinated recovery attempts.

A good block is not a crash. It is a clean, structured response the model can read and pass along, something on the order of {"error": "action_not_permitted", "reason": "policy_deny_destructive_sql", "retry": false}. The agent receives a deterministic refusal, relays it to the user, and continues the workflow without the destructive step. Production keeps serving. The report the user actually wanted still runs. Only the DROP call dies.

A bad block returns a raw exception, a timeout, or silence. That confuses the model, which then invents recovery attempts and often retries down a different destructive path. The difference between the two is the difference between a control that operators trust enough to leave on and one they quietly disable after the first false alarm. Enforcement you cannot leave running is not enforcement.

The evidence generates itself in the process. Every allow and every deny is a runtime record tied to the agent, the identity it borrowed, and the object it touched. That is the audit trail you would otherwise assemble by hand after an incident, produced continuously before one.