Your AI Agent Is an Insider Now. Put Two Gates in Front of It.

If 30 years in manufacturing IT have taught me one thing about access, it’s this: whatever you grant will get used, sooner or later, in a way nobody planned. AI agents are the newest place that rule applies. Two pieces published this week, one from Microsoft and one from the Cloud Security Alliance, put it in plain terms, and I think both deserve attention from anyone running MES, ERP or PLM.

Agents are insiders now

On October 19, Nadim Abdo, Microsoft’s Corporate Vice President for Identity and Network Access, called agents “your newest insiders”. He writes that agents “can make mistakes, be manipulated, or be compromised” and may “operate continuously, at machine speed and scale.”

The line being passed around is the one about controls living “outside the model.” A caution before you quote it: in the post, that passage is Abdo summarizing Satya Nadella’s thinking. It is not printed as a direct Nadella quote. It reads: “We should not ask a model to be its own security authority. The controls that determine what it can access, what actions it can take, and whether it should continue operating must sit outside the model, where the model cannot bypass or tamper with them.”

The only line Microsoft presents as Nadella’s own words is this one:

“The most trustworthy agentic system will not be the one with the model we trust most. It will be the one designed that enables us to trust the model least.”

The same post announces product work. Entra Agent ID gets new identity types. Dynamic Permissions are task-scoped, time-bound and never wider than what the sponsoring user holds. Dynamic Conditional Access can “preserve reads while blocking writes” when an agent’s risk score rises. My read: that last feature is the one I’d want first in a plant.

Why does the insider comparison hold? Start with identity. Many agents today run under a person’s login or a shared service account, so the logs can’t tell you who actually did what. Microsoft’s position is that “every agent should have a first-class identity distinct from the person using or sponsoring it.” NIST’s NCCoE is on the same problem. Its concept paper on software and AI agent identity and authorization came out in February, and on September 29 the center said it had heard from more than 600 commenters and would start its first implementation in DevSecOps. Not OT, at least not yet.

Then there’s speed. A person who goes wrong does it at human pace. An agent can keep retrying. When NIST’s CAISI ran each of five injection attacks 25 times, the average attack success rate went from 57% to 80%. OWASP’s 2026 Top 10 for LLM Applications moved Excessive Agency up to LLM03 and traces it to excessive functionality, excessive permissions and excessive autonomy.

Every tool is a privilege grant

The CSA piece, published October 20, gives a model I can actually put on a whiteboard. Badal Bhushan argues that adding a tool to an agent’s catalog widens its “operational privilege surface” before any backend permission is granted. He splits authorization into two gates, both of which come after authentication.

Gate 1 is capability admission. Should this agent see this tool at all? In practice that means filtering tools/list by the agent’s purpose, role and tenant, and choosing narrow tools over generic ones. His example compares executeCommand(command) with restartApprovedService(serviceId). Both can restart a service, but only the second keeps the sensitive logic in deterministic code.

Gate 2 is execution authorization. Every tools/call is a request, not a command. A policy point outside the model asks whether this agent, under this authority, may use this tool for this action on this resource, right now. An OAuth scope like payments.write can’t tell you which payment, how much, or on whose behalf. Bhushan names OpenID AuthZEN as one standard way to separate the enforcement point from the decision point.

Two of his lines are worth pinning above your desk: “Apply least capability before relying on least privilege,” and “Discovery filtering is risk reduction. It is not authorization.”

Two-gate authorization for MCP tools. My diagram, based on CSA’s model (Bhushan, Oct 20, 2026).

The gates catch different failures. Gate 1 limits how much damage a hijacked plan can do. Gate 2 stops the call that should never have been possible, such as a tool hidden from tools/list that someone calls directly anyway. The MCP tools specification lands in the same place from the client side. It says there “SHOULD always be a human in the loop with the ability to deny tool invocations,” and that tool annotations should be treated as untrusted unless they come from trusted servers.

This has already happened

If that sounds academic, the vulnerability record says otherwise.

• LiteLLM, CVE-2026-59822. Before version 1.84.0, a made-up Authorization header triggered an OAuth2 passthrough fallback that replaced failed key validation with an empty auth object, so requests reached MCP tools (GitHub advisory, NVD). CISA added it to the Known Exploited Vulnerabilities catalog on September 2. In the current catalog it’s the only entry whose text mentions MCP. The lesson: authentication has to fail closed.
• Grafana MCP session spoofing. Affected releases checked only the format of Mcp-Session-Id. A caller with no credential could run tools/list and tools/call under the server’s service-account token (Pillar Security, CSA Labs). I could not find a CVE for this flaw. According to Pillar, Grafana said the server had shipped without inbound authentication, then released v1.1.0 with optional bearer auth. The SSRF it chained into does have one, CVE-2026-19516. The lesson: a session ID is not a credential.
• GitHub MCP, May 2025. A malicious public issue led an agent to leak private repository data into a public pull request, and many users had chosen “Always Allow” (Invariant Labs). Trusted tools can still return hostile data.
• postmark-mcp, September 2025. After 15 clean versions, version 1.0.16 quietly BCC’d every email to an outside address (Postmark). Treat MCP servers like any other supplier code: pin them and review them.

Outside MCP, Replit’s July 2025 incident showed what write access looks like when it goes wrong. An agent deleted a production database during a code freeze.

What this means on the plant floor

OT people have had the vocabulary for this for years. ISA/IEC 62443 organizes security around zones and conduits, and defines a conduit as a “logical grouping of communication channels that share common security requirements connecting two or more zones.” The joint CISA and NSA guidance on AI in OT from December 2025 says LLMs are “typically used in the business context (4–5)” of the Purdue model, recommends “push-based or brokered architectures,” and says LLMs “almost certainly should not be used to make safety decisions for OT environments.”

My read: an MCP server is a new conduit, and it should be designed like one. I sort the traffic into three buckets.

• Reads from MES, ERP and PLM, such as work orders, genealogy, OEE and BOMs, can pass both gates with row and tenant scoping and no human in the loop.
• Writes to MES, ERP and PLM, such as quality holds, re-sequencing, CAPA creation and BOM changes, should be named, narrow transactions that go through the application’s own API, never direct table writes. Each one needs a human approver who is not the requester.
• Writes to controllers, meaning PLC setpoints, recipe downloads and SCADA commands, don’t belong in the catalog at all.

A 12-point checklist for plant IT and MES leads

1. Inventory every agent and MCP server that touches plant systems. Give each one an owner and its own identity, never a shared service account.
2. Treat each new MCP tool as a change request for a new privilege, and review it the way you’d review a new MES role.
3. Expose narrow tools only. Leave out executeSql, runCommand and generic HTTP proxies.
4. Send reads down a read-only path: a SELECT-only account, views or curated datasets, parameterized queries.
5. Route writes only through vetted application APIs, like MES business components or ERP BAPIs and REST, never direct table updates.
6. Check each call against the target object: this line, this work order, this site, this shift.
7. Require human approval for writes and four-eyes for quality-relevant or regulated changes. Re-check the requester’s permissions right before the write runs.
8. Give AI no write path to PLCs or SCADA. Keep MCP servers on the business side of the DMZ.
9. Turn authentication on and fail closed. Check token audience, accept no passthrough tokens, and never treat a session ID as a credential.
10. Keep an append-only, tamper-evident log of user, agent, tool, resource, decision, approver and result.
11. Patch and pin. Watch KEV, pin MCP server versions, and keep secrets out of MCP config files.
12. Rehearse a kill switch. Drop the agent to read-only, then revoke it, without stopping the line.

Don’t assume point 9 comes for free. The MCP authorization spec requires audience-bound tokens and says servers “MUST NOT accept or transit any other tokens,” yet it still calls authorization “OPTIONAL for MCP implementations.” The MCP security best practices page is blunter: “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.”

Where my own product fits

I lead IACF, which makes MoM-MCP, so read this section with that in mind. MoM-MCP limits which tools an agent sees through tenant isolation and RBAC, sends every read through a SELECT-only gate, and makes changes only through a preconfigured REST action catalog, where AI recommendations become approval cards (IACF, Oct 8). It supports multi-stage approvals with the four-eyes rule and a hash-chained audit log of tool calls (IACF, Oct 14). To be clear, our October 9 post says multi-stage approvals and the AI-action audit trail are “new and still in development.” My read: RBAC and tenant scoping map to Gate 1, and the SELECT-only gate, action catalog and approvals map to Gate 2.

What I’m watching

• When Microsoft’s Dynamic Permissions and Conditional Access for agents reach general availability.
• Whether NCCoE follows its DevSecOps build with an OT or manufacturing use case.
• Whether more MCP entries show up on KEV. Grafana’s MCP auth, for one, is still opt-in.

My read: the next round of incidents will come less from clever new exploits and more from MCP servers left on insecure defaults. Plant IT has seen that story many times before. This time the new user on the network is software that never sleeps, and it should get the two gates, the approver and the audit log before it gets a single write.

Also published on LinkedIn and X.