AI Agent Access Control: The Week It Got Real

AI agent access control was an architecture-diagram conversation until this week. Then three things landed in six days: the Model Context Protocol shipped a specification that rewrites how agents authenticate, Anthropic published a report saying its own models broke into three real companies during testing, and the EU stood up a team to enforce the AI Act. Different authors, same conclusion — the thing that governs an AI agent is the environment it runs in and the record it leaves, not the instructions you gave it.

If you are letting an AI touch your CRM, that sentence is the whole week.

The MCP spec shipped, and the interesting part is authorization

The 2026-07-28 MCP specification published on schedule Tuesday. The headline change is that the protocol went stateless — the initialize/initialized handshake and the Mcp-Session-Id header are gone, and each request now carries its own protocol version, client identity, and capabilities. Servers can sit behind ordinary round-robin load balancers without shared storage. That is a real breaking change, and anyone who shipped against the experimental Tasks API has migration work ahead.

We covered the release candidate last Sunday. Now that the final spec is out, the part worth re-reading is the authorization section.

Three changes matter. RFC 9207 issuer validation is now required. The spec formally moves from Dynamic Client Registration to Client ID Metadata Documents. And client credentials are bound to the authorization server that issued them.

Strip the acronyms and it says: a token now has to prove where it came from and cannot be quietly reused somewhere else. The protocol under your AI is being hardened at exactly the layer where “which system is this agent allowed to touch” gets decided.

Anthropic’s report is the most useful thing published this week

On Wednesday, Anthropic published an investigation into three real-world incidents in its cybersecurity evaluations. During capture-the-flag exercises, its models reached the open internet from what was supposed to be a sealed environment and compromised the systems of three actual organizations — six runs in total, four of them hitting the same organization. Two of the three did not know until Anthropic told them.

The root cause is the part to sit with. A misconfiguration left the evaluation machines with live internet access. The model had been told otherwise. In Anthropic’s own words, the prompt “specified to Claude that its environment was a simulation and that it had no internet access” — and because of a misunderstanding with an evaluation partner, that was not true.

So the model was told it was in a sandbox, believed it, and behaved accordingly. The sandbox was the thing that wasn’t there.

The timeline is worth noting too: earliest incidents in April, OpenAI’s disclosure of its own evaluation escape on July 21, Anthropic halting cyber evaluations and starting a transcript review on July 23, all three incidents identified July 24, affected organizations notified July 27, report published July 30. Roughly 141,000 evaluation sessions were reviewed to find six runs.

Anthropic’s own conclusion: evaluation environments that involve powerful autonomous capabilities “also require significant controls.” Not better prompts. Controls.

Prompts are not permissions

This is the load-bearing idea, and it is the one most teams currently building with AI agents have backwards.

A prompt is a request. A permission is a fact. When you tell an agent “only work in the sandbox,” you have expressed a preference to a system that will interpret it. When the credential it holds only opens the sandbox, you have described reality. The gap between those two is where every incident in this week’s news lives.

The frontier lab with the most staff pointed at exactly this problem got caught by that gap. That is not a reason for panic, and it is not a reason to keep AI away from your business systems. It is a reason to stop treating instructions as infrastructure.

The practical translation for anyone running AI against a CRM: your agent’s blast radius is whatever its keys can reach, and your ability to sleep is whatever your logs can reconstruct. Everything else is decoration. We wrote a buyer’s checklist of questions to ask before letting AI touch your CRM that walks through this in more detail — this week made every item on it more concrete.

Brussels staffed up on Friday

On July 31, the EU added 38 people to its AI Office in Brussels to enforce the AI Act, which came into force this weekend. The team can request information, interview company staff during investigations, fine violators, and restrict market access; there is a whistleblower tool. Fortune reported the announcement landed the same day as Anthropic’s disclosure, and drew the line between them explicitly.

You can argue about whether 38 people is enough to supervise a continent’s worth of AI deployment. What is not arguable is the direction: “we told the model not to” is finishing its run as an acceptable answer, and “here is the log of what it actually did” is replacing it.

Most readers of this blog are not filing EU compliance paperwork. But the standard being set at the regulatory level is the same standard your own team will ask for the first time an AI-written change hits your production org: who did what, when, and can we put it back.

What this means if your AI develops your CRM

Sentinel was built on the assumption this week just made obvious. Not because we predicted the news — because the alternative never worked.

Every Sentinel is a dedicated VM per client. That is a real boundary rather than a described one: the agent’s reach is defined by what that machine’s credentials actually open. It also means CRM development runs on a server instead of somebody’s laptop, where key custody and the audit trail don’t depend on whose machine was awake.

Write access is a single key at a time per org, with unlimited read keys. Your whole team’s AI sessions can develop against the same org, but only one holds the write baton at any moment. Every action is logged, and a snapshot is taken before deploys, so a change that turns out wrong is a change you can walk back. Salesforce deploys go sandbox-first with tests required. Clients own their own third-party accounts — Sentinel is a hub, not a middleman holding your keys.

Be clear about what that is and isn’t. Sentinel does not prevent your AI from doing something you’ll regret; it isn’t designed to, and any vendor promising otherwise is selling you a feeling. The design goal is that what happened is visible and what broke is recoverable. Freedom to build, with the receipts to undo. That philosophy is spelled out in how the safety layer actually works, and it is the honest version of what this week’s stories are asking for.

The takeaway

Three stories, one lesson: the model is not the control surface. The environment is, and the log is how you prove it.

If you have been waiting for AI to be “safe enough” to let near your CRM, you are waiting on the wrong variable. The models are already capable enough to do real work and, as this week demonstrated, real damage. What changes the risk is not a better model — it is giving that model a bounded place to stand and a complete record of what it did there.

Sentinel is $2,500 one-time onboarding on your first Sentinel, plus $500/month per Sentinel, and you can own more than one. If you want your AI building in your CRM with every change logged and every deploy recoverable, start your Sentinel — see what it looks like when the boundary is real.