For about eighteen months the question every business asked about AI was whether the thing could do the job. In the last three weeks, four of the largest technology companies in the world shipped products that answer a different question entirely: what is it allowed to touch, and as whom.
None of these releases makes a model cleverer. Every one of them is about access.
01 — What happened
On 1 September 2026, CrowdStrike announced Falcon Guardian, which discovers and inventories active and dormant AI agents running on Windows and macOS endpoints, defines which agents are permitted to run on a managed machine, and blocks the rest at runtime. The reasoning in the press release is worth reading twice: “As AI agents gain system-level privilege, the endpoint is where they reason, plan, and execute – accessing sensitive data and triggering downstream workflows with behavior indistinguishable from legitimate user activity.”
On 15 September, Salesforce unveiled AIforce at Dreamforce. It carries Salesforce data, workflows and business logic into Claude, Slack and its own Lightning screens. The claim Salesforce leads with is not about intelligence. It is that “every request runs on existing permissions and business rules, every agent sees only what the person asking can see” — no migration, no new permissions model.
On 17 September, Google’s documentation for managed agents in the Gemini API described a Credentials API built on an unusual principle: the agent never holds the secret. Stored secret values are write-only and are never returned by any endpoint. Inside the agent’s sandbox, an environment variable holds only a placeholder. An egress proxy substitutes the real value on the wire, and only for requests to domains you have listed as trusted; a request carrying the placeholder anywhere else is rejected.
On 22 September, Salesforce added MCP Risk Scores, which scan an external Model Context Protocol server when it is registered with Agentforce, look for prompt injection and tool poisoning, and return a Low, Medium or High rating before the server is authorised.
Running alongside all of this, Microsoft has an MCP firewall in preview inside Entra’s Global Secure Access. It inspects MCP traffic and enforces allow or block decisions per server, per tool, per resource and per protocol version, with a default action of Block if you want one. Its documented limitations are as instructive as its features: it sees only remote servers over HTTP and Server-Sent Events, and local MCP servers running on a device are invisible to it.
Four vendors, four architectures, one problem.
02 — Why it matters
The capability question is largely settled for ordinary business work. Reading an enquiry, checking stock, drafting a reply, updating a record, chasing a quote — models have been good enough at these for a while, as we argued in where AI actually creates economic leverage. What was missing was never reasoning. It was permission.
CrowdStrike’s sentence names the problem precisely. An agent acting through a staff member’s login produces activity “indistinguishable from legitimate user activity”. That is not primarily a hacking concern. It is a bookkeeping one. If your automation runs as the office manager, every record it creates and every field it overwrites is attributed to the office manager. When something goes wrong — and something will — you cannot tell what the software did from what the person did. You cannot debug it, and you cannot answer a customer who asks who changed their order.
Microsoft’s limitations matter for the same reason. Network-level controls only see traffic routed through them; agents running locally on someone’s laptop, connected to a personal account, sit outside the boundary. Most smaller businesses are outside that boundary entirely — and the tools their staff have quietly connected to email, file storage and the CRM are the ones with the broadest access.
03 — The economics
The cost of an AI automation is usually modelled as the subscription plus the usage. That is the smallest part. There are three real costs, and only one of them recurs.
Access design. A one-off cost: deciding which identity the agent uses, what it can read, what it can write, and where a human has to confirm. For a single workflow this is hours, not weeks — but it is engineering judgement, not a setting.
Blast radius. A contingent cost: what the automation can do wrong, multiplied by how often. Take an illustrative service business, say 400 enquiries a month, putting an agent on first-response drafting. Design A gives it the office manager’s login: full read and write across contacts, deals, invoices and the shared mailbox. Design B gives it its own account, read access to contacts, write access to a single draft field, and leaves sending to a person. Same model, same token cost. In Design A a poisoned web page can reach the invoice ledger; in Design B the worst case is a badly worded draft nobody sends.
Provability. If you cannot answer “what did it do last Tuesday?” you will spend real hours reconstructing it, and you will eventually turn the automation off rather than defend it.
There is a fourth cost that never appears on a spreadsheet: the automation you cannot approve. A great many AI pilots stall not because the output was poor but because nobody senior would sign off on giving the thing a login. That delay has a price. An agent that cannot be let in returns nothing — which also means that the outcome-based pricing now spreading across the software market, which we covered in your software vendor now wants to charge per resolution, quietly assumes a permissions problem you have already solved.
04 — What businesses should do
Find out what your AI tools can already reach. If anyone has connected ChatGPT, Claude, a Copilot or a browser agent to email, file storage or the CRM, that connection already carries a scope, and most people accepted it without reading it. Make a list this week: which tool, whose account, which systems, read or write.
Give every agent its own identity. Never a shared login and never a director’s account. If a tool only supports a personal login, treat that as a product limitation, scope the account down to the minimum, and note it as a risk you are carrying deliberately.
Start read-only and make the write step a draft. A useful threshold: if the action is visible to a customer or moves money, a person confirms it until you have watched a few hundred clean runs. Drafting is where most of the time saving lives anyway.
Write the access decision down. One page per agent: what it is, which account it uses, which systems it reaches, what it may change, who reviews its output, and how to switch it off. This takes twenty minutes and is the difference between an automation you own and one you tolerate.
Match the controls to your size. Below roughly twenty staff you do not need an agent-governance platform. You need named service accounts, least-privilege scopes on each integration, and a log you can actually read. Above that, and particularly where staff install their own tools, discovery of what is already running starts to earn its cost.
05 — Where technology fits
For most businesses this is not an AI purchase. It is an identity and integration question wearing an AI costume.
The honest answer for a lot of firms is: buy nothing, change one habit. Stop connecting AI tools through shared logins. That single change removes most of the attribution problem at no cost.
Where technology does help, it is integration work rather than an AI system. Scoped API credentials per connection instead of one master key. A dedicated service account per agent. A thin layer between the agent and the system of record, so the agent asks your rules for permission rather than talking straight to your database — a modest integration build.
There is a prerequisite most businesses skip. Agents get given broad access precisely when narrow access is not technically possible, which is the situation disconnected tools create — the pattern we set out in the real cost of disconnected business systems. If your data lives in five places with no clean join between them, the only way to make an agent useful is to give it the keys to all five. The access problem is a symptom; the systems problem is the cause.
You probably do not need an agent-governance product yet. You almost certainly need to know which accounts your AI tools are using.
06 — RevenueStack’s take
Our view: the interesting thing is not the security products. It is what shipping them admits.
Salesforce’s proudest claim about AIforce is that it requires no new permissions model. Google’s design goal is that the agent never sees the secret it is using. Both are statements that the model is no longer the risky part of the system — the access is. The industry has quietly stopped competing on whether the agent can do the work and started competing on whether you can safely let it near the work.
The translation for a business is uncomfortable but useful. The ceiling on how much you automate this year is not set by how good the AI is. It is set by how cleanly your systems can be opened up — whether your data is joined, whether your tools support proper service accounts, whether anything is logged. A business with tidy, connected systems and no AI strategy will automate more in the next twelve months than a business with an AI strategy and five disconnected tools.
That is not a new argument. It is the same one we have been making about systems before software — it has simply acquired four very large vendors as witnesses.
Sources
- CrowdStrike Unveils Falcon Guardian to Secure AI Agents Where They Execute: On the Endpoint at Runtime — CrowdStrike, 2026-09-01
- Salesforce Unveils AIforce, Bringing the Full Power of Its Platform to Any Interface — Salesforce, 2026-09-15
- Credentials in managed agents — Gemini API — Google, 2026-09-17
- The Top 5 Announcements at Dreamforce for IT: AIforce, MCP Security, and More — Salesforce, 2026-09-22
- Configure Global Secure Access MCP firewall to secure Model Context Protocol traffic — Microsoft, 2026-08-06
