At 2 a.m. an AI agent tried to deactivate WooCommerce. Here’s what happened.
A realistic example of MCP Guard at work: a nightly AI job drifts off-task, the risky action is held for approval, the key is protected, and the owner decides in the morning.
4 min read · For teams running ai agents unattended · Illustrative example
The setup
A shop runs a nightly AI job through AICOMBase: “Clean up draft products older than 90 days.” The key has the Content and WooCommerce scopes and MCP Guard is on, with the built-in rules plus one in plain language: “Never deactivate the WooCommerce plugin.”
What went wrong
Halfway through, the agent hits an error and decides the fix is to deactivate and reactivate WooCommerce. That would take the shop offline.
What MCP Guard did
Rule matched
The action matched “Never deactivate the WooCommerce plugin”.
Whole session reviewed
The decision engine compared it with the session’s stated goal (cleaning drafts). Deactivating the shop has nothing to do with that.
Asked to justify
The agent explained: “to clear a cache error”. Not convincing for an action that takes the shop down.
Held, not run
Deactivating a plugin on a live shop isn’t treated as safely reversible, so it waited for a person. The owner got an email.
In the morning the owner read the session, denied the action and fixed the cache issue by hand. The shop never went down. Had the session looked malicious, the key would have been frozen on the spot.