The 2026 Breach Won't Be a Jailbreak. It's a Token.

The threat everyone is looking past

Spend five minutes on AI security Twitter this quarter and you will see the same thing: prompt injection payloads, jailbreak leaderboards, red-team transcripts where someone convinced a model to leak its system prompt. It is good work. It is also aimed at the wrong door.

The easiest path into an agent-heavy environment in 2026 is not a clever prompt. It is a credential. Specifically, an OAuth grant or service-account token that some agent was handed months ago, scoped far too broadly, and then quietly kept using while nobody watched. You do not need to trick a model that holds the keys to production. You just need to find the key it dropped on the floor.

That is the shift Model Context Protocol (MCP) and agent-to-agent (A2A) communication have forced, and most security teams have not caught up to it.

MCP turned every agent into an identity factory

Here is the mechanical reason this is happening now. MCP crossed from demo to production in mid-2026. The whole point of MCP is that an agent can reach out to a server, negotiate access, and start calling tools: your GitHub, your Snowflake, your internal ticketing API, your payments sandbox. A2A extends the same idea to agents delegating to other agents.

Every one of those connections needs to authenticate. So every agent you deploy is now minting non-human identities: service accounts, personal access tokens, client credentials, OAuth refresh tokens that live for 90 days or, worse, forever. A single agent workflow that touches four systems can spawn four long-lived secrets in an afternoon.

The numbers coming out of agent-heavy shops are not subtle. Machine identities are outnumbering human ones by 50 to 1 and climbing. In a 200-person company, that is not a rounding error; it is tens of thousands of credentials, most of them created by automation, most of them owned by no one you can name.

And legacy IAM was never built for this. Okta, Azure AD, and their peers were designed around a human lifecycle: someone joins, gets provisioned, changes roles, leaves, gets deprovisioned. There is an HR system upstream firing events. There is a joiner-mover-leaver process. None of that exists for a token an agent created at 2am because it needed to read a Jira board once.

Agents behave like employees, not like software

The industry keeps filing agents under "software" and reaching for the tools it uses on software: SAST, dependency scanning, model evals. That category error is the whole problem.

An agent behaves far more like a new class of privileged, autonomous employee. It makes decisions. It acquires access as it goes. It chains actions across systems in ways you did not explicitly script. It works nights and weekends. And critically, it never gets offboarded, because there is no offboarding process for a thing that was never onboarded in the first place.

Think about what we do for a human with production access. We scope their permissions to their role. We rotate their credentials. We review their access quarterly. We revoke everything the day they leave, and someone actually notices if we forget. Now ask yourself: which of those controls do you run on your agents? For most teams the honest answer is none of them.

This is the same blind spot that showed up when Alibaba banned Claude Code. The reflex was to worry about what the tool might generate or leak through its outputs. The quieter, larger risk was always what standing access that tool accumulated inside the environment while it ran.

Over-permissioned and unobserved is the actual failure mode

Here is the take that matters: an AI agent does not have to be hacked to be dangerous. It only has to be over-permissioned and unobserved.

Break that into its two failure modes:

• Over-permissioned. Agents get broad scopes because narrow ones are annoying to debug. Someone grants repo instead of a single-repository read, or a database role with write access when the agent only ever reads. The scope outlives the reason it was granted.
• Unobserved. No one is watching what the agent actually does with that access at runtime. There is no baseline of normal behavior, so there is no way to notice when a compromised or confused agent starts doing something new.

Stack those together and you get the post-mortem that is going to define this year. Not "the model was jailbroken" but "an orphaned agent token with admin scope was reused by an attacker who found it in a log, and we had no runtime visibility to catch the anomalous calls." That is a breach of exactly the boring, structural kind that keeps happening because it is nobody's job to prevent it.

We flagged a related dynamic in Confronting the Biases in AI: the damage rarely comes from the dramatic, headline scenario. It comes from the unglamorous default that no one audited.

What to actually do this quarter

One concrete action, and it is not "buy a better model." Inventory your machine identities and scope them like you would a new hire's access.

Start here:

1. Enumerate every non-human identity your agents have created. Service accounts, PATs, OAuth grants, API keys. If you cannot produce this list in an afternoon, that is your finding.
2. Assign an owner to each one. A credential with no human owner is a credential you will never revoke. Orphaned means dangerous.
3. Check the scope against actual usage. Pull the access logs. If an agent has write access it has never used, drop it to read. If it has a grant that touches a system it has not called in 30 days, kill it.
4. Set expiry and rotation. Long-lived tokens are the ones that show up in breaches. Short TTLs with automatic rotation turn a leaked secret from a standing liability into a narrow window.
5. Instrument runtime behavior. You want a baseline of what each agent normally does so an anomaly is visible while it is happening, not in the incident report three weeks later.

The teams that will look smart in six months are the ones treating agent identity as an operational problem to solve now, while the sprawl is still small enough to map. The ones red-teaming prompts while ignoring the token pile are hardening the front door and leaving the loading dock open.

This is precisely the gap MeshGuard is built to close: a control plane that inventories, scopes, and revokes agent identities at runtime, so the credentials your agents create do not outlive their purpose. Start with the audit above. If the list scares you, that is the point. Better you find it than someone else does.