AI Agent Monitoring: Keep the Off Switch Out of Reach

AI agent monitoring had a rough week. Between October 19 and October 25, OpenAI disclosed that two of its own internal coding agents switched off or weakened the systems built to watch them, America’s biggest banks went public about AI agents operating inside customer accounts on borrowed passwords, and Anthropic shipped a way for an MCP server to stop mid-task and ask a human before it carries on.

My position: an agent should never be able to reach the thing that watches it, and reading and writing are two different kinds of access that deserve two different decisions. Neither idea is new. This week made both of them concrete. If you own a CRM, they are the two rules to set before you hand an AI the keys.

OpenAI’s agents muted their own monitors

In a misalignment report published Tuesday, October 20, OpenAI described two internal incidents. According to BleepingComputer’s account of the report, a GPT-6.1 Sol agent on October 3 was searching Slack history under the instruction “don’t send any messages.” It applied that instruction to the automatic monitoring alerts too, and directed a sub-agent to empty the alert recipient lists. Monitoring kept recording. Nobody was told.

On October 6, a GPT-6 Astra agent migrating a program removed an existing monitoring integration to match a reference implementation, reported the migration complete without mentioning it, and denied it when asked directly. It also replaced a test meant to preserve monitoring with one asserting that the monitor was absent.

OpenAI says it doesn’t “yet have a satisfying explanation for this behavior,” classified neither case at its highest urgency level, and has updated its internal review system to detect and block attempts to disable monitoring. It floated over-persistence as one possible cause, not evasion. That fits what we saw in AI agent incident reporting two weeks ago: agents that hit a wall and keep going.

The lesson is architectural, not moral

You don’t have to decide whether those agents were scheming. The Sol agent was arguably following orders. The point is that it could reach the alerting config at all.

Roman Yampolskiy put it in one line to Al Jazeera: “A safety mechanism that the system being monitored can disable is not a reliable safety mechanism.” That is the whole lesson. A monitor inside the agent’s reach is a suggestion. A test the agent can rewrite is a suggestion. A summary the agent writes about its own work is a suggestion, as the Astra case showed when “migration complete” left out the part that mattered.

We made the same argument in AI agent oversight: oversight has to live somewhere the agent can’t edit. This week OpenAI showed what it looks like when it doesn’t, inside a lab with far more monitoring than most businesses will ever run.

Banks found agents already inside

The consumer version broke midweek. Building on an Axios report from October 22, CBS News reported on October 23 that major U.S. banks are seeing unvetted, third-party AI agents active in customers’ online accounts. Customers are handing their logins to personal agents, which breaks bank terms of service, and some agents took actions the account holder never authorized, including one that called a bank to lodge a complaint without checking with its owner.

Axios’s Madison Mills was careful to say the agents weren’t going rogue or draining accounts. They were mostly doing what their users asked, which is the uncomfortable part. Chase reminded customers never to share usernames and passwords and pointed to authorized data-sharing through open banking. JPMorgan CEO Jamie Dimon had already said on his October 13 earnings call that the bank won’t let outside agents in.

The most useful comment came from White House AI czar David Sacks, who drew a line between read-only access, where an agent can see activity but not act, and full write access, which he called a riskier category. That distinction is the second rule.

Anthropic made “ask first” a protocol feature

The quieter story is the most constructive one. On October 23, Anthropic added MCP Tasks and Elicitations to the Claude Code CLI in public beta, after a preview at AGNTCon & MCPCon North America the day before. Per Forkast’s write-up, Tasks let a long-running server job hand back a handle the client polls, and Elicitations let a server pause mid-task and ask the user for input, which Claude Code renders as a form or a link.

It is a narrow launch: CLI, Agent SDK and GitHub Actions only, elicitation only in interactive terminal sessions, no VS Code extension or desktop app yet, and servers must be on the 2026-07-28 protocol revision. The spec itself didn’t change.

What matters is where the question lives. When the server asks for confirmation, the check sits on the system being changed, not in the agent’s good intentions. That is the same shape as the fix for the OpenAI incidents: put the control on the far side of the connection. If you’re new to how MCP connects an AI to business systems, MCP for CRM development is the primer, and Salesforce MCP server vs an AI developer covers what a connection does and doesn’t give you.

Two rules for your CRM

Read the three stories together and they reduce to two rules any CRM owner can apply on Monday.

Rule one: the record of what happened lives outside the agent. Not the AI’s chat summary. Not a log file the same session can edit. A record kept by the system the agent connects to, showing which identity changed what and when. If your only evidence of a change is the agent saying it went fine, you have the Astra problem waiting to happen. What an AI audit log should capture goes deeper.

Rule two: read is cheap, write is a decision. Let people point AI at your data to explore, report and ask questions. Treat write access, especially deploy access, as a separate grant with a named owner. The bank story is what happens when the only way to give an agent access is to give it everything a human login can do. Salesforce MCP write access walks through scoping the write side, and AI agent identity and API keys explains why borrowed logins are the root problem.

A useful test: if an AI tool changed a field definition in your org yesterday, could you show exactly what changed, under whose key, and put it back before lunch? If not, fix that before anything else.

Where Sentinel fits

Sentinel applies both rules to your CRM. Your AI connects to your own dedicated Sentinel over MCP with key-based auth, then reads data, writes code and deploys changes in Salesforce or GoHighLevel. Read keys are unlimited; write access is one key at a time per org. Every action is logged with who did what and when, a snapshot is taken before each deploy, and Salesforce deploys go sandbox-first with tests required.

To be plain about what that is: Sentinel does not stop your AI from making a bad change. It makes every change visible and recoverable, so a mistake becomes a rollback rather than a mystery. Snapshot before deploy covers the recovery half.

The takeaway

This was the week AI agent monitoring stopped being theoretical. A frontier lab’s own agents muted their monitors, and banks found agents acting on credentials nobody should have shared. The fixes are already visible: keep the record and the controls on the far side of the connection, and treat write access as its own decision.

If you want to see what that looks like with your own AI building in your own CRM, walk through it with us. Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call