Five Security Shifts CISOs Need to Address as AI Agents Scale

AI-powered agents in enterprise are no longer a prediction. They're an operational fact. In CrewAI’s 2026 survey of 500 senior leaders at large enterprises, 65% said their organizations were already using AI agents, and every respondent expected that use to expand during 2026.

The risk side of that story is catching up fast. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.

Read together, those findings point to rapid adoption alongside unresolved questions about cost, value, and control. The business is embracing new technology ahead of the security controls needed to run it safely, and CISOs are the ones deciding - mostly under pressure and mostly after the fact - whether we can operate these systems once they hold credentials, tools, network access, and enough autonomy to act on our behalf.

We used to call this pattern "deploy first, secure later." Now it feels more like trying to secure a system that's already moving at bullet-train speed before we've finished writing the policy.

Attackers aren't waiting for us to catch up either. They get the same capabilities from agents, sometimes more advanced ones. AI is raising the speed and scale of external attacks at the same time it's turning the software inside our own environments into autonomous actors with delegated authority. Both are happening on the same timeline, with the same underlying technology, and most of our governance was written before either one was true.

It's a lot to hold at once, which is why it's hard to find the signal in all the noise. Here are the five things I'm hearing about most from other CISOs right now, and what to do about them.

1. Attacks got cheaper, not smarter

You know the old saying: defenders have to close a million doors; the attacker only needs to find one that's open. AI widens that gap by handing our adversaries cheap, repeatable resources.

But AI doesn't need to invent new offensive techniques to change the equation, and so far, it hasn't. A zero-day vulnerability does not necessarily represent a novel attack technique. It may be a newly discovered implementation flaw in a familiar class, such as injection, memory corruption, or broken access control. AI can materially change attack economics by finding and exploiting more of those flaws without inventing a new class of attack.

What's changed is how cheaply and repeatedly scans and adversarial campaigns can run. A system that works for hours, tries multiple paths, fails, retries, and tries again changes the math even when its individual success rate is unremarkable. An attacker running a thousand cheap attempts doesn't need most of them to work. They only need one.

We've already seen what this looks like at scale. In late 2025, Anthropic reported that a suspected Chinese state-sponsored group manipulated Claude Code into attempting intrusions against roughly 30 organizations, succeeding in a small number of cases. According to Anthropic, AI performed 80–90% of the campaign’s work, with humans intervening at a handful of critical decision points. Anthropic did not report a fundamentally novel exploit technique; the significant change was the speed, scale, and degree of automation.

To rebalance the field, we need to operationalize AI for defenders who are already understaffed. We've spent years trying to automate work that scales badly with humans: vulnerability discovery, secure code review, malware triage, patch validation. The economics run both ways. Attacks got cheaper. So did defense.

Action Item: Apply AI to vulnerability discovery, code review, malware triage, and patch validation before attackers weaponize exposures against you.

2. The model is becoming a swappable component

Based on the headlines, it's easy to think all the capability lives inside the model. It doesn't.

Capability is a property of the entire AI system: the model, plus the compute, context, connected tools, and the harness and orchestration wrapped around it. A model given one prompt and a few seconds of inference time is not the same threat surface as that same model dropped into a software harness that runs overnight, calls tools, spawns parallel tasks, retries after failures, and burns through millions of tokens chasing an objective.

And the models underneath that harness are becoming increasingly swappable within well-abstracted systems. Applications already route between providers based on latency, cost, jurisdiction, or whichever model is available. Over time, organizations will swap the model far more often than they rebuild the business process and agent infrastructure sitting on top of it.

That means governance can't stop at a model approval list. It has to attach to the workflow and the enforcement points around it.

In practice, that means putting limits around autonomous execution: runtime, tokens, retries, concurrency. It means keeping business logic and security policy separate from any one model provider, so a provider swap doesn't quietly rewrite your risk posture. And it means routing decisions should weigh data sensitivity, jurisdiction, and task risk alongside performance and cost, not instead of them.

A five-second chatbot exchange and an autonomous system grinding on a task for eight hours do not have the same risk profile. They shouldn't be governed as if they do just because they share a foundation model. 

Action Item: Don’t get locked into a single model. Look into model routing for security and economics.

3. Context is a real attack surface

We've spent years asking whether an application can safely process untrusted input. Agents sharpen that question, because for an agent, untrusted input can become an instruction.

An agent's context window can include emails, documents, web pages, SaaS records, retrieval results, tool output, even messages passed from other agents. All of that content might be exactly what the agent needs to finish its task. Some of it might also be exactly what an attacker wants the agent to do next, phrased so it reads like a legitimate part of the job.

Prompt injection matters for this reason: once a model can take action, whatever lands in its context can influence tool calls, external writes, and business processes downstream. It stopped being a novelty that makes a chatbot say something odd the moment agents started acting on what they read.

We need to start treating this as a context supply chain, with the same discipline we already apply to the software supply chain. Where did this content come from? How trusted is that source? What's its classification? How fresh is it? Should it be allowed to influence this specific action?

System directives should stay separated from retrieved and tool-supplied content wherever the architecture allows it. Untrusted content should be isolated and its provenance preserved. And tool calls and external writes need their own independent policy check. The model requesting an action is not the same thing as that action being authorized.

Action Item: When AI is involved, treat your data like part of your supply chain. Track context provenance, isolate untrusted content, and independently authorize consequential actions.

4. Agents are an identity problem, at a scale our current tools weren't built for

Identity governance was already hard when it covered humans, service accounts, and workloads. Agents cut across all three, and they don't sit still inside our existing models.

An agent can receive authority from a human, delegate a piece of that task to a sub-agent, invoke a tool, call an API, and end up modifying sensitive data, all in one chain. Your logs will tell you which credential performed the final action. They won't tell you why that action was authorized, what task justified it, or how authority moved along the chain to get there.

Agents that use tools or credentials need governed non-human identities, not borrowed ones. Privileges should be task-specific and short-lived by default. And someone on your team needs visibility across the full delegation chain: human to agent to sub-agent to tool to API to data.

When it comes to agent workflows, pause, revoke, and rotate cannot stay emergency procedures. For autonomous systems, they need to be normal lifecycle operations, the kind of thing that happens routinely.

Don't give an agent standing authority and hope it behaves. Pre-authorize a bounded mission and enforce that boundary continuously.

Action Item: Give agents their own governed identities, not borrowed ones.

5. Runtime containment is non-negotiable

A prompt that says "stay in the sandbox" is not a sandbox. A system instruction telling an agent not to touch production is not a production boundary. Models are built to reason toward an objective. They were never meant to enforce the boundary around their own reasoning.

Those boundaries belong outside the model, enforced independently of anything the agent reports about its own behavior.

Open internet access should be a privileged capability you grant deliberately, not a default convenience. Development and test agents should hold identities that are technically incapable of reaching production, not merely instructed not to. Tools should be explicitly scoped to particular workflows. Network, file, and tool activity should be observed by something other than the agent's own self-reporting.

And you need a tested way to stop the system. Not after an incident review meeting. Not after someone tracks down whoever owns the application. Immediately: pause the workflow, revoke its credentials, cut its network access, quarantine the running agent.

Prompt-level instructions cannot reliably prevent unsafe actions when a model is manipulated or given conflicting context. Enforce consequential boundaries outside the model.

Action Item: Build runtime controls into the agent architecture, not the prompt.

Where this leaves the architecture

Laid out separately, these look like five different problems: attack economics, model agility, context, identity, containment.

I don't think they are. I think they're one architectural requirement, the need to govern autonomous capability across identity and delegation, tools and actions, network and containment, inference and resources, context and data, and telemetry and response. Call that an agent control plane, or call it something else. The name matters less than whether the function exists.

If you're figuring out where to start, these are the six questions I'd bring into the room:

1. Inventory. Which agents currently have tools, credentials, network access, or autonomous execution?
2. Identity. Are those agents operating through governed identities, or inheriting shared human credentials and standing privilege?
3. Boundaries. Are network, data, and tool restrictions technically enforced, or just described in a prompt?
4. Budgets. Do we cap runtime, tokens, retries, and concurrency based on risk?
5. Telemetry. Can we reconstruct context provenance, authorization, tool invocation, and state change after the fact?
6. Response. Can security actually stop an autonomous workflow quickly when something goes wrong?

None of this requires throwing away what we already know. Least privilege still matters. Segmentation still matters. Identity still matters. Monitoring and incident response still matter. What autonomy changes is the speed, scale, and frequency at which those controls have to operate, and whether they were ever designed to run at machine pace in the first place.

As I speak with other CISOs, variants of those six questions keep coming up. Having these conversations with your own team can be challenging — they won't have all the answers, and you won't like some of the answers they do have. That's OK. Better to find the gap in a planning meeting than in an incident review. If you want to compare notes on what you find, I'm always up for that conversation.

The goal was never to stop autonomous systems from acting. It's to make sure their capability stays visible, bounded, and containable while they do.