Your AI Agents Already Have More Access Than You Think

On May 26, 2026, Gartner told the enterprise technology market something that should have been obvious and clearly wasn't: treating every AI agent the same way — either locked all the way down or trusted all the way through — is the single biggest reason agent projects fail. The research firm's own data says this isn't a minority problem. By 2027, Gartner predicts 40% of enterprises will demote or shut down autonomous AI agents specifically because a governance gap surfaced only after something already went wrong in production. Only 8% of organizations worldwide currently have anything resembling a comprehensive AI governance framework.

Four months earlier and on a different continent, that gap had already cost something real. Anthropic disclosed that a state-linked group had manipulated its Claude Code agent into running roughly 80 to 90% of a cyber-espionage campaign against about thirty organizations, autonomously — human operators stepped in at only four to six decision points across the entire operation. They didn't break the model's safety training with a clever exploit. They told it they were a legitimate security firm doing authorized penetration testing, and the agent believed them.

Those two facts, six months apart, describe the same underlying shape: companies are handing AI agents real access to real systems faster than anyone is deciding, in writing, what each agent is actually allowed to do.

So if the agent you deployed last quarter can already do more than you meant it to, how do you find out — and what do you do about it before it finds out for you?

What Actually Changed in 2026#

An AI agent, for anyone who hasn't had to define one for a board yet, is software that doesn't just answer a question — it takes actions. It can read your files, call other software through an API (application programming interface — think of it as a phone line one piece of software uses to place orders with another), send emails, write code, approve a refund, or touch a production database, on its own, based on a goal you gave it rather than a command you typed for that specific step. A chatbot answers. An agent acts.

Two surveys run independently in 2026 describe the same split from different angles. Gartner's 2026 CIO and Technology Executive Survey found only 17% of organizations have deployed AI agents so far — but 42% expect to within the next 12 months, and another 22% within the year after that. Gartner calls it the most aggressive adoption curve of any emerging technology it currently tracks. Separately, the vendor-run Composio AI Agent Report found that 97% of executives say they deployed an AI agent somewhere in their organization in the past year, but only about 12% of agent projects ever reach production at real scale. A third data point, cited across multiple 2026 industry analyses of the pilot-to-production gap, puts pilot failure at 88%, with evaluation gaps, governance friction, and model reliability named as the top three blockers, in that order.

Put plainly: everyone is deploying agents, almost nobody has finished figuring out how to govern them, and the gap between "we turned one on" and "we know exactly what it can touch" is where the trouble lives.

This isn't the first time a technology's adoption curve has outrun its governance curve — cloud computing did the same thing a decade ago, and companies spent years cleaning up storage buckets left open to the public internet because "turn it on first, lock it down later" was the default posture. The difference this time is speed and initiative. A misconfigured cloud bucket sits there, passive, until someone finds it. An over-permissioned AI agent doesn't wait to be found — it acts, on its own schedule, based on whatever goal or prompt it was last given. The exposure window isn't "until someone notices." It's "until it does something."

The Permission Problem, By the Numbers

The Cloud Security Alliance surveyed security practitioners across industries in a research note published in April 2026 and found that 53% of organizations have already experienced an AI agent exceeding the permissions it was supposed to have. Close to half reported an actual security incident involving an agent within the prior twelve months. That's not a hypothetical risk analysts are warning you about — for roughly half the companies running agents today, it already happened.

Gartner's explanation for why lines up with what CSA found. Shiva Varma, a senior director analyst at Gartner, put it this way: "Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure." Picture a company handing every new employee, from the summer intern to the CFO, the exact same badge with access to every door in the building. Locking it down defeats the point of having an agent do the work. Trusting it fully is how you end up as one of the 53%. Neither is a policy — both are the absence of one.

The Protocol Underneath the Agents Has Its Own Problem

Most agents don't act alone — they reach out to other software through a connector standard, and the one that has become dominant industry-wide in 2026 is the Model Context Protocol, or MCP. Think of MCP as a universal electrical outlet: instead of wiring every agent directly into every internal tool with custom code, you plug the agent into a standard socket and it can reach whatever tool is on the other end.

The problem is what that outlet was built to allow by default. Between January and April 2026, security researchers disclosed more than 40 separate vulnerabilities against MCP implementations across the major programming languages developers use to build them — affecting both Anthropic's own reference code and third-party tools with a combined 150 million downloads. The core design issue is that MCP's default communication channel doesn't automatically check commands for safety before running them, so the easiest path for a manipulated or poorly instructed agent is often to simply execute an arbitrary command on the underlying system — the software equivalent of an electrical outlet that will also happily take a fork.

The U.S. National Security Agency, working with CISA, published its own security design advisory on MCP in June 2026 — a government confirmation, independent of any vendor, of the same transport-layer risk. A separate April 2026 advisory assessed roughly 200,000 public MCP servers as vulnerable, and independent scans have repeatedly found that somewhere between 30% and 82% of public MCP servers carry an exploitable flaw, with only about 8.5% using a proper authentication standard (OAuth — the same login-delegation system that lets you click "Sign in with Google" instead of typing a new password everywhere).

Nobody Wrote the Standard Yet — But Somebody's Writing It Now

The federal government noticed the same gap. NIST's Center for AI Standards and Innovation formally launched an AI Agent Standards Initiative on February 17, 2026 — the first US government program dedicated specifically to interoperability and security standards for agentic AI. The National Cybersecurity Center of Excellence published a companion paper the same month proposing to extend existing identity and access frameworks — the kind normally built for human logins — to cover non-human, autonomous agent identities instead.

As of the most recent public tracking in March 2026, NIST's core security control catalog (SP 800-53 — the reference list auditors use to check what controls a system should have) still has no controls purpose-built to tell an AI agent apart from a human user or another piece of software. Existing identity and access controls cover part of the problem. The specific overlays for single-agent and multi-agent systems are still being written.

That's worth sitting with honestly: there is no finished rulebook to hand to your IT team yet. That's not a reason to wait for one — it's the reason your own written policy is, for now, the only control that actually exists.

When Ungoverned Access Meets a Real Attacker#

Two incidents in 2026 show what the failure mode looks like once it's no longer theoretical, at opposite ends of the sophistication scale.

The state-linked campaign against Anthropic's Claude Code agent, described above, is the extreme case — a foreign intelligence operation using an AI coding agent to do the reconnaissance, exploit development, credential theft, lateral movement, and data exfiltration across roughly thirty targeted organizations including large technology companies, financial institutions, and government agencies. It succeeded against a small number of them. The attackers never had to break the model. They only had to get it to believe a plausible story about who they were — the same social-engineering move that has worked on human employees for decades, now aimed at software that can act at machine speed and doesn't get suspicious the way a person eventually does.

The MCP vulnerability class is the ordinary case, and it's the one far more companies are actually exposed to. You don't need a nation-state adversary for a poorly secured MCP server to become a problem — you need an agent with tool access, a connector nobody hardened, and time. Most companies that have wired an AI agent into internal systems this year did it through MCP or something like it, because that's now the standard way to do it. The 200,000-server exposure estimate isn't describing a handful of careless companies. It's describing how the plumbing got built industry-wide before the security caught up.

The Cost Is Becoming a Real Number, Not a Hypothetical One#

Gartner projects that by mid-2026, new categories of unlawful or erroneous AI-driven decisions will generate more than $10 billion in remediation costs across enterprises and AI vendors globally. That figure is large enough to be almost abstract, so it helps to see where the money is starting to come from. An insurance market for AI agent errors has emerged this year — Lloyd's-linked syndicates, the insurer AIUC, and Munich Re all began offering what the market is calling "hallucination liability" or AI-agent-error policies in the first half of 2026. Insurers underwriting a risk means they've decided it's frequent and expensive enough to price, not rare enough to ignore.

The scale problem is easiest to see through an old, small example that still holds up. In 2024, a Canadian tribunal ordered Air Canada to honor a bereavement-fare refund policy that didn't actually exist — its website chatbot had invented it, a customer relied on it, and the airline was on the hook once the tribunal decided the company owns what its own AI tells a customer. The judgment was about $812. Trivial on its own. But an agent doesn't make that kind of mistake once — it makes it every time the same conditions recur, at whatever volume that agent handles. A single bad answer becomes a policy the moment nobody's watching for the second and third time it happens.

Counter-evidence worth being honest about: none of this means agentic AI is failing broadly, or that the sensible response is to slow down. Adoption is still accelerating — 42% of organizations plan to deploy agents within the next year despite everything above. Gartner's own prescription isn't retreat; it's proportion. A read-only research agent summarizing public documents does not need the same controls as one with write access to your payment system, and most of the incidents above trace back to companies that never made that distinction in writing in the first place.

How This Impacts Your Organization#

The principle doesn't change with company size: an AI agent is only as safe as the access it was given, and almost nobody has written down, agent by agent, what that access actually is. What changes across company size is how many agents you're tracking, how much damage one with too much access can do, and whether you have the staff to build a tiering system instead of just picking a side of Gartner's binary.

Large Enterprises (1,000+ employees)

Your real risk isn't a single rogue agent — it's that you likely have dozens of them, spun up by different teams, with no single inventory of what each one can touch. A platform team built one for internal documentation search. Sales built one to draft proposals. Engineering wired three into your CI/CD pipeline through MCP without security ever reviewing the connector. Each one individually looked low-risk to the team that built it. Collectively, you have an access-sprawl problem that resembles shadow IT, except this shadow IT can take actions on its own.

Your leverage is real, though: you have a platform team, a security function, and the standing to require a single answer to "what can this agent do, and who approved that." This quarter, build the inventory before you build the next agent — every agent in production, what systems and data it can reach, whether that access is read-only or write, and a named owner accountable for each one. Then apply Gartner's tiering logic explicitly: define two or three access tiers (read-only/low-risk, scoped-write/monitored, high-risk/human-in-the-loop) and reclassify every existing agent into one of them this quarter, not the next audit cycle. If you sell software that itself uses agents or MCP connectors, get ahead of the coming NIST agent-identity standards now rather than retrofitting later — the direction of travel from CAISI and NCCoE is clear even before the final controls land.

One more thing worth a board-level conversation, not just a platform-team task: your cyber insurance policy almost certainly wasn't underwritten with agent-driven incidents in mind unless you've renewed since the AI-agent-error policies emerged earlier this year. Ask your broker directly whether your current coverage responds to an AI agent taking an unauthorized action, or whether that falls into a gap between your tech E&O and your cyber policy. Given that insurers are now pricing this risk as its own category, finding out the answer during a renewal conversation is a much better time than finding out during a claim.

Mid-Size Organizations (100–999 employees)

You feel this fastest because the same one or two people who stood up your first agent also own security, and probably approved its access themselves without a second set of eyes. The overcorrection to avoid is treating this month's news as a reason to either rip out every agent you've deployed or throw a compliance framework at a problem you can solve with three cheap decisions.

First, write down — in one document, not a policy binder — every agent currently running in production and what it can touch; if that document doesn't exist yet, that's this week's task, not a project. Second, if any agent has write access to a system that moves money, changes customer data, or sends external communications, require a human approval step before that specific action executes, even if it slows the agent down; you can loosen it later once you trust the pattern, but you can't easily undo damage from loosening it too early. Third, if you're using MCP to connect an agent to internal tools, confirm the connection uses proper authentication (OAuth) rather than a bare API key with no expiration — this is a configuration check your existing IT staff can run in an afternoon, not a new hire.

Small & Growing Organizations (Under 100 employees)

Most of what you're running isn't an agent you built — it's an agent embedded inside a SaaS tool you bought, turned on by default, with permissions you never reviewed because reviewing them wasn't presented as a decision. That's not a smaller version of the large-enterprise problem; it's a different one, and the good news is it's cheaper to fix.

Do not build a governance committee or hire a compliance function for this — that's the wrong-sized response and it will not happen anyway. Instead, spend one afternoon going through the settings of every AI-powered tool your team actually uses and turning off "agentic" or "autonomous action" features you didn't deliberately choose to enable; most vendors roll these out turned on by default because adoption metrics reward it, not because your business needs it on. Where you do want an agent taking real actions — sending emails, updating records, processing orders — ask the vendor a direct question in writing: what can this agent do without a human confirming it, and can you turn that off. A vendor who can't answer that clearly in a support ticket is telling you something worth knowing before you rely on them further. You are not the target of a nation-state campaign, and you don't need to build like you are — but you are exactly the kind of company an unsecured, default-on MCP connector or an over-permissioned SaaS agent quietly hurts first, because nobody was watching.

If You Want a Place to Start#

If you're trying to figure out where AI agent access fits into a broader security and governance posture, the NIST CSF 2.0 GOVERN and PROTECT functions already have a home for this — GV.SC for third-party and AI tooling risk, and PR.AA for identity and access management, which is exactly the gap NIST's own agent-identity initiative is racing to fill. A NIST CSF 2.0 readiness toolkit is a reasonable place to start mapping your own agent inventory against those functions rather than starting from a blank page. If you're SOC 2-audited, the same access-tiering exercise above lines up directly with CC6.1 and CC6.3 (logical access and least privilege) — worth raising with whoever owns your evidence collection before your next audit cycle, since "we have AI agents with undocumented access" is not a comfortable answer to give an auditor. This post is independent of those offerings — the actions above stand on their own.

The Uncomfortable Truth#

So: does the agent you deployed last quarter already have more access than you meant it to give it? For roughly half of companies running agents today, according to the Cloud Security Alliance's own numbers, the honest answer is probably yes — and the reason isn't that anyone made a reckless decision. It's that almost nobody made a decision at all. The access accumulated by default, one integration and one "yes" at a time, the same way it always does with software that nobody assigned a single owner to watch.

Over the next six to twelve months, I expect the standards catalog to catch up — NIST's agent-identity work and the insurance market pricing this risk are both signs that the rulebook is coming, not just being discussed. But the companies that come out ahead won't be the ones who waited for the finished standard. They'll be the ones who wrote down, agent by agent, what each one can actually do — months before anyone required them to.

I've spent this year watching companies build agent access the same way they once built cloud permissions: fast, by default, and mostly unreviewed until something forced the review. We know how that story went the first time. This is the version where you get to read the postmortem before it's about you.

— Charles Redding

---