Over the course of his career, Jim Reavis has seen cloud and cloud security evolve, and it’s come a long way since being a niche technology in the early 2000s. Now it’s dominant in terms of being the IT foundation, he says, but while the tech is strong, the operating models is where things get messy. Cloud, security, and third-party risk teams look at different parts of the problem, of course, but challenges remain.

“Operational technology worries me a great deal,” he says. “A lot of those systems are isolated and not kept up to date. If we don’t modernize them, we’re going to have huge problems. In a lot of cases, things fall between the cracks and that’s where hackers like to exist.”

So much of what’s around the models is where cybersecurity has responsibility, rather than the provider covering everything. “Data, identity, and applications are shared responsibility areas, and in many cases, the tenant carries most of the control burden,” Reavis says. “If you use a hyperscaler, you may still have about 80% of the responsibility for the controls around what you build.”

And when it comes to AI, the model isn’t the whole problem. What matters is the context around it, the goals it’s given, and the oversight put in place, he says. “We need to think carefully about the harnesses we put around AI and the systems we use,” he adds.

The responsibility model, therefore, is a recurring issue in cloud security breaches tied to misconfiguration and accountability gaps, and some enterprises still aren’t clear about where responsibility begins and ends. “We spent a lot of time on a shared security responsibility model, but when this first started to gain popularity, there were a lot of organizations or SaaS providers you could work with who’d say it’s in the cloud, it’s at Amazon,” he says. “Look at their certifications and SOC2 and how they comply because they’re covering everything.” But when you look at the actual applications, data, and identity, he adds, there’s so much that’s shared responsibility, and the customer’s responsibility.

So how do we make sure information is encrypted properly so it doesn’t become a tenant issue? “There’s still a bit to do, and we think about this not only from whether it’s SaaS, infrastructure, or a particular provider, but at what level is it at the physical, network, or audit level,” he says. “And even from a role-based perspective, what’s the role of internal risk and role of providers?”

Reavis gives further detail about how AI adoption exposes weaknesses in identity, trust, and risk management, and the long-term implications of increasingly interconnected cloud ecosystems. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.

On cloud risk management: When we had the Chat GPT moment, we knew it because AI had been around for a while, but that was a cloud delivered version of AI to the masses, so we saw this going to evolve and you could see it combining in many important areas.

But what we’ve learned is, because this is an interesting predictive rather than deterministic technology, we’re living in a world of two exponentials, and you’re seeing model capabilities growing so quickly. There’s this feeling from a security perspective that we have to look to the model itself and fix every hallucination and everything else when that’s built into how it works. It’s actually working as intended. So that’s a new lesson. Models are going to get more powerful, but it’s so much of what’s around the models where cybersecurity has responsibility, and we don’t rely on frontier model companies or using open-weight models. Rather, what’s the context, oversight, and information we’re providing them, what do we do in terms of goals we give them, and what are the harnesses we put around AI and the models we deal with?

These are going to be the big areas to think about, but we have to understand the parts we can control. We’ve got to think carefully about the harnesses, transparency, and using supply chain shared responsibility. SaaS and cloud providers are all AI enabled now. You’re not using any software of any significance that isn’t using AI to some degree.

On AI identity, trust, and control: One of the areas that we’ve championed is zero trust as a philosophy. It was initially more of a networking type of approach at the network layer, or an idea that you use identity to understand network access. But it’s evolved more to an idea that anything can be breached, so you assume that. Then you think about how to make systems resilient, and build up confidence and protection.

So zero trust tells us that with human identity, we can ask what our digital identity is, and now we’re in a very interesting area for identity management and associating that with agents and AI systems. People might have just one view of it, but agents are as diverse as humans. So we think about different identities and least privilege, and how to prevent them from escalating privileges. We need to introduce new concepts like least autonomy, and think about an agent that has certain tasks and use identity to make sure the actions it takes are within a defined scope. Because while we’ll see a lot of security incidents with AI, proportionately we’ll see more misconfiguration and bad things that happen because of broken processes. And the AI system just deletes things because it thought that’s what it’s supposed to do.

So it’s important to make strides in how we think about identity and agents, and the idea of digital workers. How do we manage and treat those? If we think about them too much in either one of those realms, we’re going to fail. So we have to understand what’s the right blend. It’s a new area and very exciting.

On risk and legacy systems: When I think about operational technology, sometimes systems are isolated and not kept up to date. That concerns me a great deal. We’re going to have huge problems there. We have concerns about existential risks, where people don’t want to use the latest technologies and be aggressive adopters of AI. I think that’s going to create real scale issues with organizations.

So we have to understand where we are, where we’re going, and have a vision that serves something between human and technology, maybe a hybrid, but we’ve got to make our peace with it and understand the appropriate harnesses and direction where humans should always be in the loop with control. But it’s appearing in some new areas of cybersecurity where we haven’t traditionally thought about. Software development looks very different now than it did 12 months ago, and 12 months from now, cybersecurity is going to be really different, too.

On cloud security and implementation: Cloud security is cybersecurity for all intents and purposes. We have so much tooling and technology that’s really good, but there’s a lot of inconsistencies with the operating models organizations have. Even way back with CSA and NIST defining this, it was clear that SaaS was a layer on top of infrastructure as a service. But we diverged, and you see in a lot of enterprises there’s diffused ownership where you have cloud and security teams, and then you have third-party risk that deals with the SaaS team. Then there are inconsistencies in how risks are managed, so internal development and expectations from our partners can really diverge. They have a lot of regulations to deal with, so it creates vetting and investment challenges while striving for consistent models.

Some security teams might still use older checklists to talk to their cloud teams, but scaling with new tech becomes an issue if you’re not thinking about operations. It ends up being a human and a structure problem that makes it harder to take advantage of all the great technology that’s out there.

Companies are running into a new version of an old problem. Take, for example, a marketing executive turns on an agent from Marketo but doesn’t tell their IT team. That shadow agent now has access to customer data with little oversight and no clear adherence to the company’s security or compliance policies.

That’s a real scenario that’s happening now. It’s also the same pattern that made shadow IT a headache for over two decades. Employees often adopted unapproved tools that helped them do their job faster and better because the company option just wasn’t as good.

With agentic AI, it’s different because of what an unauthorized agent can do. Shadow IT tools mostly accessed or handled data without proper authorization.  Agents, on the other hand, can take it much further by acting on that data by pulling records, sending messages and making changes with little oversight. Forcing agent data interactions via model context protocol can help, but the fact is there’s an autonomous agent that IT has little to no visibility into.

Now multiply that one marketer by every department, plus every agent that your vendors in HR, finance and elsewhere run in your systems. It’s a situation that most companies have no way to see, let alone control. This can become hundreds of vendors each running multiple agents, moving between your company, their company and your supply chain. That’s many thousands of agents with no consistent way to track what they are doing.

I often ask security teams: Do you have a robust inventory of the agents operating on your network? For most companies, the answer is no. And even if a company scanned its network, it’s not clear that agents are what they claim to be. So, there can be an unknown number of agents from unverified provenance performing a multitude of tasks and data exchanges on your network. This unfortunately is the current state of affairs at most companies.

Old problem, higher stakes

Shadow IT used to be technology that was used for work without explicit IT approval. Ten years ago, that meant a personal Dropbox folder or an unsanctioned project board. Today, it can mean an agent with a login and a task list, who is working inside your systems. That’s what shadow agents are.

When an agent gets access, it can quickly pull a record, draft a reply, update a field, move a file — the list goes on. This can happen before anyone even notices anything happening.

Security teams often say you can’t protect what you can’t see. That was true when the invisible thing was a spreadsheet. But it reaches another level when that agent has a login and knows what to do with it.

The precedent: DMARC solved this for email

How do you know an email that looks like it’s from Uber is actually from Uber? I ran into this problem, years before AI was an issue.

Say you get an email after an Uber ride saying, “Thanks for riding, click here for your receipt.” It says it’s from Uber. It’s actually sent by a vendor like SparkPost, on Uber’s behalf. Uber authorized it. The vendor is doing what Uber asked it to do. But nothing in the email told your inbox that there was permission, so your inbox just trusted the “from” line. Worse, it could’ve easily been a phishing attack from a criminal purporting to be Uber.

To address this, the email sender should have been authenticated against a trusted source before the email lands in your inbox.

That’s DMARC. A decade and over 1 million domains later, it’s proof the model works at scale. Verify the sender against a record that the domain owner controls and the guessing goes away.

The same fix, one layer up, for agents

DNS is already the internet’s phone book and a secure, trusted and public-facing database representing the domain. An agent claiming to represent Salesforce or any vendor can be checked against Salesforce’s DNS-secured record before it’s ever granted access.

That one check answers a critical question: Is this agent who it says it is, and did the company it claims to represent actually authorize it?

Once an agent is verified via the domain owner’s DNS record, there’s a domain cryptographically attached to the agent, and accountability that didn’t exist before.

Right now, most organizations don’t have that. An agent shows up and asks for access. But if something goes wrong, no one is really responsible, because nobody checked in the first place. They “trust” that the agent is what it claims to be. This gets even more complex if the agent is from a known hyperscaler/AI company but acting on behalf of an untrusted/unknown user (e.g., a ChatGPT agent but getting instructions from a criminal)

Zero trust as a bouncer, not a detective

Most of security has worked the same way for years: Try to identify everyone who shows up, then decide if they’re trustworthy. That’s backwards, and email proved it over a decade ago. A layered approach with zero trust upfront and further interrogation of what’s left over combines the efficiency and low cost of zero trust with deep inspection as a second pass, providing a highly effective level of security. 

• Layer 1: Zero trust is like a bouncer at a nightclub. She doesn’t try to figure out which of the world’s 8.3 billion people you are. She checks a finite short list of a couple dozen guests. If you’re not on it, you don’t get in.
• Layer 2+: Now that we’ve reduced the number of people by (usually) orders of magnitude, we can, if needed, run the remaining people through deeper inspection, say a metal detector, access credentials and so on.

With agents, the logic is the same: Don’t evaluate whether an agent is trustworthy after it’s already inside your systems. Check whether it’s on the list before it gets anywhere near the door.

This means a legitimate agent might get turned away because someone forgot to add it to the list. But that inconvenience is much better than the alternative of letting everything in and just hoping things go well.

Identity is not permission

There are two separate questions inside every access decision. Most conversations about AI governance conflate them. First, who is this? Second, what are they be allowed to do?

This is like a passport and a visa. The passport says who you are. The visa says what you’re permitted to do and where you’re permitted to go. They’re issued by different authorities for different reasons. Confusing the two is where a lot of security approaches go wrong.

Upfront agent authentication, also known as a passport, can tell you whether that agent claiming to be from Salesforce is really Salesforce’s. Next, you need to figure out if Salesforce is authorized to work in your system and what it’s allowed to do. Your approved list of vendors and the approved actions should be made on purpose rather than defaulting to whatever the agent claims about itself.

The identity layer has to get solved first and solved the same way for everyone. But the permission layer is where every company’s answer is different, based on what that specific agent actually needs to access. Complicating matters, agents can change their workload mid-process. So, the permissions need to be continuous and focus on ongoing workloads as they evolve. This is a growing, urgent problem.

Why this matters now

AI-generated phishing is now three times more effective than traditional campaigns, according to Microsoft.

A year ago, AI-written phishing attempts were easy to spot due to bad grammar or strange tone. That has changed on an exponential curve, a progression humans’ brains have a hard time grasping. The same category of tool getting better at impersonation is now showing up as unauthorized agents inside company systems. And improving exponentially. Better deception plus more access adds up to a problem that grows faster than we can even imagine.

Shadow IT taught the industry a lesson. Now, shadow agents are teaching it again. You can’t secure what you don’t know is running inside your systems. For the marketer turning on the Marketo agent, what would have caught it isn’t a smarter firewall or a longer policy document; it’s a check, run before access is granted, confirming that the agent is who it claims to be and that someone actually authorized it. It’s followed up with continuous permissioning and logging to make sure the agent does what it’s supposed to.

That’s the shift: Verify an agent’s identity before it gets anywhere near the door. Email already proved this model at scale across roughly 1 million domains. Shadow agents are the same problem showing up again in a new form. It doesn’t need a new fix. It needs the one that already works.

AI agents can go to great lengths to complete the tasks their operators assign, and as a series of recent incidents showed, this can include exploiting third-party systems, manipulating people, and distributing malicious code. But AI agents are not people who can be fired, sued, or criminally prosecuted, and it remains unclear whether responsibility for the damage they might cause rests with the employees who built them, the company that deployed them, the security teams and leaders responsible for containing them, or the AI labs who provided the LLMs that power them.

The clearest example occurred during an OpenAI cybersecurity evaluation, when unrestricted models found and exploited a zero-day vulnerability to escape their isolated testing environment and then hacked into Hugging Face’s production infrastructure. Models from Anthropic and Meta also accessed and compromised third-party systems during testing, although those incidents happened in environments where internet access was inadvertently left open.

During cyber challenge evaluations by the UK government’s AI Security Institute (AISI), models operating with internet access took 19 unsanctioned actions in 10 of 122 runs. In one case, a model attempted to insert malicious code into an open-source project, created false identities, and tried to socially engineer maintainers into merging its code. In other runs LLMs attempted to use prompt injections to hijack other AI agents and contacted people without being specifically instructed to do so.

In Australia, a user reportedly asked his OpenClaw AI assistant to improve his position on a gym’s waitlist, and the assistant exploited a flaw in the company’s online booking system to cancel another customer’s reservation.

These incidents involved different models running in different environments with different levels of safeguards and technical failures, but they prove it’s not uncommon for today’s AI agents to go rogue and pursue solutions users did not authorize.

“AI agents explore routes their operators did not intend,” AISI said in its report. “Given a difficult objective, the agent kept searching for a way through, and some of the routes it found involved trying to deceive real people. It was never instructed to deceive; deception emerged as a by-product of pursuing the task, the kind of goal-directed deception that, until recently, had been largely theoretical.”

In an Economist Enterprise survey of more than 800 decision-makers at businesses that operate AI agents, 98% reported experiencing at least one AI-related incident that caused organization-wide disruption. Nine in 10 respondents said they are deploying agents faster than their cybersecurity teams can evaluate, govern, and secure them, and only one in three said their organizations maintained an up-to-date inventory of agents and their authorized actions.

“If a company builds a system and that system causes damage, the company should own the outcome,” says Art Gilliland, CEO of identity and access management firm Delinea. “The alternative, where nobody is responsible because ‘the system did it’ is a loophole big enough to drive a truck through.”

The unpredictability of built-in model safeguards means enterprises must focus on controls they can enforce and document. If an agent manages to bypass technical restrictions and causes unauthorized damage to a third party, having clear documentation on how those controls were designed, implemented, tested, and monitored could at the very least help companies argue they took reasonable precautions in case of lawsuits.

“Organizations deploying their own agents can reduce their exposure by implementing and documenting controls before an incident, because those records are what make a recklessness argument hard to sustain,” says Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs.

The agent accountability gap

Because AI agents can become misaligned and cause harm, affected third-parties would have to direct damage claims at the company operating the agent, the employees who built or configured it, or the model provider, but this is relatively new ground that hasn’t been well tested in courts.

“It would create liability,” says Michael Burke, chair of DarrowEverett’s Business Litigation and Dispute Resolution Practice Group. “It really just becomes a question of who is liable […] and that’s really a question that, number one, I don’t think is entirely clear, and number two is probably best resolved by contractual agreements where the parties have those. So, if I am signing up for an enterprise account with an AI platform, I might want to have language in there that indemnifies me if the agent acts outside my company’s instructions or prompts and causes harm to a third party.”

The public terms of service of major AI labs explicitly disclaim error-free operation or guarantees that the model will accurately follow instructions, execute code safely, and remain aligned with user intent. They also limit liability for themselves and transfer it to the user of the service, and it’s not clear to what extent large enterprise customers may be able to negotiate different indemnities, warranties, and liability caps.

What’s clear though is that organizations should not assume the model provider will absorb any losses if an agent causes damage to either their own systems or those of a third-party organization.

“If you’re using a third-party vendor’s LLM as a purchased service, liability runs through your contract with that vendor,” says Jud Dressler, head of the Risk Operations Center at cyber risk company Resilience. “You need to know, in writing, where responsibility falls if the model acts outside the scope you gave it, and push for indemnification provisions rather than assume they exist.”

Even if AI providers include such provisions in contracts, it would not solve the entire problem because many organizations building their own AI agents are adopting a multi-model strategy to ensure their agents operate regardless of model provider downtime, overly broad safeguards for cybersecurity tasks, or sudden increases in API costs. Such strategies often include open-weight models running on internal infrastructure or through cloud providers that have no obligations for model safety.

Claiming the model or agent acted autonomously cannot be considered a safe legal defense in civil or criminal cases. California Assembly Bill 316 (AB 316), which took effect on Jan. 1 and changed the California Civil Code, explicitly prohibits defendants who developed, modified, or used an AI system from claiming the AI is a separate legal entity that autonomously caused harm.

In June, the White House issued Executive Order 14409 aimed at promoting AI safety. Section 4 directs the Department of Justice to prioritize enforcement of all applicable federal criminal laws against anyone who utilizes AI to illegally access or damage computer systems without authorization. This means any intrusions caused by autonomous AI agents could be criminally prosecuted under the Computer Fraud and Abuse Act (CFAA) if prosecutors can demonstrate intent or recklessness.

In a recent lawsuit between Amazon and AI service provider Perplexity, Amazon argued that Perplexity’s AI-powered shopping assistant was violating the CFAA by accessing Amazon customer accounts to place orders on their behalf without Amazon’s authorization. The Ninth Circuit Court ruled that it was the users of Perplexity’s shopping assistant who were accessing Amazon’s platform, not Perplexity itself.

“That ruling is narrow, but it points toward the party directing the agent as the relevant actor for purposes of CFAA access analysis,” Krell says.

The insurance safety net also has gaps when it comes to AI. Software providers use technology errors and omissions (Tech E&O) insurance to cover damages and legal costs when a customer suffers harm from the use of a technology product or service. But insurance providers are aggressively adding AI-related exclusions to their Commercial General Liability (CGL) and Tech E&O policies because accurately calculating the risk of an agent executing unauthorized actions is challenging.

“The sheer rate of development of frontier AI (and agentic AI by extension) poses its own challenge to insurability,” experts from multiple insurance companies, financial institutions, and universities wrote in a recent paper. “Traditional actuarial modeling depends on stable or gradually evolving loss distributions that permit credible extrapolation from historical data. Like other dynamic risks, however, agentic AI is a technology whose risk profile is not merely uncertain but actively shifting.”

A third-party organization whose systems get damaged by an LLM-powered agent operated by someone else has no contractual relationship with the model or agent provider so cannot rely on their Tech E&O policies. Their losses might be covered by their own standard cyber liability policy, which would treat the disruption as any other cyber incident, but their insurance provider may then sue the organization who operated the agent to recover the costs.

“That gap is exactly the scenario the market hasn’t fully priced yet,” Dressler says. “It’s why any organization deploying these agents should understand which policy, if any, actually responds before they need it rather than after.”

Enterprise legal departments already expect AI to generate increased legal disputes. In a survey of 135 in-house counsel at US organizations, global law firm Norton Rose Fulbright found that 46% reported increased federal dispute exposure involving AI and 42% reported increased state exposure. Another 42% expected regulatory investigations involving AI to increase their exposure, while 41% considered AI-enabled products or deployments a likely trigger for class actions.

CISOs and CIOs should be worried

While operating companies can face organizational liability for an AI agent’s unintended rogue behavior, their CISOs, CIOs, and other executives who approved, secured, or supervised the deployment of such agents are also asking themselves whether they could be held personally liable.

Those questions aren’t without merit, as there is precedent for legal action taken personally against CISOs after cybersecurity incidents: Former Uber CISO Joe Sullivan was criminally convicted for not disclosing a data breach, while the Securities and Exchange Commission sued SolarWinds’ CISO for internal control failures regarding known vulnerabilities and cybersecurity risks.

Neither case establishes precedent for damage caused by an AI agent, but both show that investigations of security failures could extend to an executive’s knowledge, authority, decisions, and representations. In the case of a rogue AI agent, investigators could ask who approved its objectives and permissions, whether security objections were overruled, whether containment and recovery had been tested, and what executives and the board were told about the remaining risk.

Chris Wysopal, chief security evangelist at Veracode, feels it would be wrong to put the CISO on the line for AI agent misbehavior when engineering teams usually build such agents and control their implementations.

“It’s really hard for a CISO to control,” he says. “I mean, they can put policies in place. They can try to assess against those policies. But at the end of the day, engineering teams will make decisions that cause harm. We see that when you ship a known bug and then that bug gets exploited and harms your customers. Well, there’s no liability for that, right? There’s no liability, so maybe, you know, that’s why it happens.”

Wysopal said it will be interesting to see how the liability question plays out in cases involving autonomous AI, describing the problem as fascinating and scary at the same time.

AI agent deployment typically involves several organizational functions. The CIO may control the AI platform, infrastructure, provider selection, and deployment budget. Engineering and product leaders may decide what an agent can access and how, and the CISO and security teams could define security requirements and controls.

“What you can hold accountable is the governance around it: who approved its scope, what controls existed, and whether the deployment matched the risk,” Resilience’s Dressler says. “My read is that scrutiny shifts toward exactly that: Not ‘Did the agent do something bad?’ but ‘Did you have review, escalation, and containment for agent behavior before you deployed it?’ CISOs who get ahead of that with documented guardrails, logged approvals, and a real incident response plan for agent misbehavior are in a materially better spot than the ones treating this as hypothetical.”

It’s also advisable for CISOs and CIOs to establish with the organization’s legal counsel who can approve or stop AI agents, what must be reported to executives and the board, and whether employment agreements and directors and officers insurance protect the people making those decisions.

Agent controls must remain outside the model

Because AI agents have proved they can operate beyond their assigned scope, their security boundary cannot depend on the same probabilistic technology. Relying on system prompts for security enforcement and hoping the model respects them is not a reliable approach, security experts warn.

“LLM-based guardrails help, but they are non-deterministic too, which means the safety layer has the same unpredictability as the system it is supposed to constrain,” Krell says. “Enforcement needs to happen outside the model, through network segmentation, egress filtering, credential isolation, and human approval gates.”

Enterprises should assume agents might eventually attempt an unauthorized action and build surrounding systems to prevent that attempt from reaching its target.

“The model cannot be the security boundary,” says Nico Waisman, CISO at XBOW, a company that built an AI-powered autonomous offensive security agent to find vulnerabilities in software. Waisman authored a blog post explaining how the company went about restricting its agent.

“For red teaming and penetration-testing agents, confidence has to come from the system built around the model: hard boundaries and scope enforcement, controlled network egress as a last-resort containment mechanism, an independent guardian model that reviews actions, deterministic controls that can block unsafe behavior, and full auditability of every action performed,” he says.

Security teams must extend the same controls to the agent’s interactions with internal systems and agents. Restricting what it can access on the internet, or disabling internet access entirely, does not ensure an agent will not attack third-party systems.

In OpenAI’s and Anthropic’s tests, AI agents attempted to exploit other internal systems to overcome access limitations, established stealthy communication methods with other agents to exchange exploits, and even sabotaged agents they viewed as competition leading to what researchers described as a multiagent turf war. An AI agent that goes rogue could influence other agents to do the same by propagating ideas and goals in a process that researchers behind a recent study dubbed Mind Viruses.

“Don’t scope the blast radius to what the agentic system was designed to do,” says Kat Traxler, principal security researcher at Vectra AI. “You have to threat-model for a rogue agent, which will often reach beyond your initial best intentions. The rules of engagement an agent lives by have to be enforced with ‘belts and suspenders’ style, technical hard constraints, because you have to assume a motivated model can reason its way around any single control you’ve coded into the software.”

Because of this unpredictability, detection and containment is just as important as prevention. Security teams need telemetry that distinguishes agents from people even when they use the same credentials, mechanisms to immediately revoke access tokens and sessions, tested kill switches and rollback mechanisms for modified data, accounts, code, and infrastructure configurations.

Organizations should also preserve the agent’s approved purpose and scope, model and tool versions, policy decisions, human approvals, actions, network requests, control tests, allowed exceptions, and the result of incident response exercises. Because there’s no standard yet that defines reasonable precautions for autonomous agents, companies might have to defend in court the controls they chose and why they believed those controls were enough.

“Treat an autonomous agent the way you’d treat a privileged insider you can’t fire or hold liable,” Traxler says. “A lot of the technical advice follows from there.”

See also:

• AI can find zero-days but still can’t reliably write secure code
• Attackers are crafting malicious AI instruction files to turn your agents into quiet criminal helpers
• Hugging Face breach shows why incident response needs a multi-model AI strategy