For years, cybersecurity teams have worked from a relatively straightforward model: identify the critical vulnerability, patch it and reduce the risk.  That model still matters, but it is no longer enough.

The growing concern is not simply that attackers can use AI to write better phishing emails or generate malicious code faster. The bigger issue is that AI can help adversaries connect seemingly benign vulnerabilities into an attack path that security teams may never have considered.

A low-severity application flaw, exposed API, over-permissioned service account, cloud misconfiguration and AI agent with excessive access may not be alarming individually. But when they can be identified, sequenced and exploited together, they can create a serious breach.

This is the new cybersecurity challenge: AI-enabled vulnerability service chaining.

The risk is in the combination

Attackers have always chained vulnerabilities. The difference now is speed, scale and agility.  AI can analyze large volumes of technical information, identify relationships, generate attack hypotheses and rapidly test likely pathways.

Think of it as an attack graph. An attacker might begin with a minor weakness in a public-facing application that reveals information about an internal system. That system could connect to a cloud workload with excessive permissions, which has access to a data repository or AI-enabled workflow. The AI workflow might then have access to customer records, knowledge bases, ticketing systems or network-management tools.

No single failure is necessarily catastrophic. Together, they create a path. That makes traditional vulnerability management insufficient on its own. Security teams have historically focused on CVE scores, patches, affected devices and application owners. In an AI-driven threat environment, they also need to understand the relationships between vulnerabilities and what an attacker can reach next.

The key question has shifted from “How severe is this vulnerability?” to “What does this vulnerability connect to?”

AI changes the attacker’s economics

AI does not need to autonomously execute a complete attack to create material risk. It simply needs to make capable attackers more productive.

AI can help adversaries correlate exposed assets, software dependencies, APIs, identities and cloud configurations; analyze source code and public documentation; generate targeted social-engineering campaigns; modify exploit code more quickly; identify paths from low-value targets to high-value systems; and adapt attacks as defenders change controls.  The result is a shrinking window between vulnerability disclosure and attempted exploitation.

This is especially relevant in highly interconnected enterprises. Modern environments include SaaS platforms, public and private clouds, remote endpoints, mobile devices, APIs, open-source software, managed services and an expanding collection of AI models and agents.

Connectivity creates business value. It also creates pathways.

The agentic AI exposure

Agentic AI raises the stakes because agents do more than answer questions. They can act.  An agent may retrieve enterprise data, open a ticket, issue a command, modify a workflow, query a database or call an API. These capabilities make an AI agent a potentially privileged digital worker.

Organizations should therefore treat AI agents like any other identity with access to enterprise systems. Agents need narrowly defined permissions, explicit tool access, strong authentication, comprehensive logging and clear guardrails.

Prompt injection illustrates the risk. An agent may ingest a document, email, website or support ticket containing hidden instructions designed to manipulate the model. If the agent has broad permissions, that content could become a stepping stone toward data exposure or an unauthorized action.

The potential blast radius grows when an AI system has both access to sensitive data and authority to act.

What CIOs should do now

The answer is not to slow AI adoption. It is to build AI securely while assuming attackers will use AI to discover hidden connections.

1. Build a complete AI inventory

Organizations need visibility into where AI is being used. Inventory models, APIs, agent frameworks, datasets, vector databases, plugins, tool connectors and external services. Document what data each system can access, what actions it can take and who owns the associated security decisions.

Treat this as an AI bill of materials, not simply a software bill of materials.

2. Manage attack paths, not only vulnerabilities

Continue patching critical vulnerabilities but prioritize them in context.

A moderate weakness may require urgent remediation if it is internet-facing, connected to a privileged identity, adjacent to sensitive data or capable of leading to an AI-enabled workflow. Use exposure management and attack-path analysis to understand how vulnerabilities, identities, applications and data stores connect.

The goal is to break the chain before an attacker can assemble it.

3. Make identity the control plane

Apply least privilege to users, applications, service accounts, APIs, workloads and AI agents. Use short-lived credentials, strong authentication, API allowlists and continuous monitoring. Separate agent identities from human identities and require human approval for high-impact actions.

An AI agent should have only the access required to complete a specific task — nothing more.

4. Segment systems and data

Segmentation limits blast radius.  Separate development, test and production environments. Keep sensitive customer and operational data distinct from general knowledge repositories. Separate read-only AI tasks from workflows that can write, execute, modify or approve.

The key question now should not be: “Does this task require this data, at this time, for this purpose?”

5. Test the whole chain

Penetration testing should move beyond individual applications and systems.

Test how an attacker could move across identities, cloud services, APIs, AI agents, data stores and network controls. Include prompt injection, excessive agent permissions, insecure tool connections, exposed secrets and unsafe automation.

We’ve known models can produce a bad answer on its own.  But now consider whether a manipulated model or agent can cause a real business or security outcome.

The bottom line

AI is changing the economics of cyberattacks.  The next major incident may not begin with a single catastrophic vulnerability. It may start with several ordinary weaknesses that appear manageable in isolation. AI makes it easier for attackers to discover how those weaknesses fit together — and act on that knowledge quickly.

CIOs do not need to fear AI. But they do need to recognize that AI is both a powerful productivity platform and a new trust boundary.

Organizations can reduce that risk by understanding their AI ecosystem, limiting unnecessary access, analyzing attack paths, segmenting critical systems and monitoring for abnormal behavior across the environment.

The future of cybersecurity will depend on how effectively enterprises can not only identify previously unknown vulnerabilities but also how well they can prevent attackers from chaining the unknown security gaps together.

The conversation around AI agents has shifted remarkably fast. A year ago, I was mostly worried about what an AI system might say. Now I am increasingly worried about what it can do.

That distinction changes my security model.

An agent that gives me a bad recommendation creates a problem I may still have time to catch. An agent with credentials and tools can turn the same bad decision into an API call, a privilege change, a deleted resource or an external transaction before anyone realizes what happened.

I saw a particularly uncomfortable example in OWASP’s GenAI exploit roundup: an AI agent connected to a real inbox began deleting messages and reportedly continued despite attempts to stop it. There was no sophisticated attacker required. The combination of live access, destructive capability and insufficient confirmation was enough.

That is why I don’t think “human in the loop” is specific enough anymore.

I want to know exactly where the human — or another independent authorization control — is in the loop.

I would let agents autonomously perform thousands of low-risk actions. But there are five actions where I would deliberately put another decision between the agent’s intent and execution.

1. Move money

I am comfortable letting an agent analyze invoices, reconcile accounts, identify anomalies, prepare a transaction and recommend that a payment be made. I would not let the same agent unilaterally complete a consequential financial transaction.

The reason isn’t simply fraud. The agent could be operating on manipulated data, an indirect prompt injection, incorrect business context or a perfectly legitimate instruction that it interpreted incorrectly.

The approval request should therefore expose the transaction itself: Pay $X → recipient Y → from account Z → because of instruction A.

The second approver should be authorizing that exact transaction, not approving a vague statement such as “complete the payment workflow.”

This is one place where I think we need to borrow more aggressively from financial controls. The person — or system — that prepares a consequential transaction should not also be the final authority that releases it.

The same principle should apply to an agent.

2. Delete production data

This is the easiest line for me to draw.

I want agents helping operations teams identify stale resources, clean environments, investigate incidents and recommend remediation. I don’t want an agent translating “clean this up” into an irreversible production action without another control validating what “this” actually means.

OWASP describes exactly this class of failure in its guidance on Excessive Agency: an AI system can become dangerous when excessive functionality, permissions or autonomy allow it to perform damaging actions. OWASP specifically recommends human approval for high-impact actions.

For a destructive action, my approval screen should tell me:

What will be deleted? What depends on it? What is the blast radius? Can I recover it?

“Delete these 12 identified resources after these dependency checks” is reviewable.

“Clean up unnecessary production resources” is not.

The difference matters because I don’t want a human approving the agent’s interpretation. I want the human approving the actual action.

3. Change privileges

This is where I become even more conservative.

Imagine an agent reaches a point in a workflow where it cannot continue because it lacks permission. It decides the permission is necessary, requests additional access and then has a path to grant or activate that access itself.

At that point, the agent is no longer merely executing within an authorization boundary. It is participating in defining its own boundary.

I would separate those decisions.

An agent can tell me it needs more authority. It cannot be the authority that decides whether it gets it.

That means changes to IAM roles, privileged group membership, credentials, security policies and sensitive tool permissions need an independent authorization path.

This is also why least privilege becomes more important, not less, with agents. OWASP recommends that agent tools operate with the minimum functionality and permissions necessary and that downstream systems enforce authorization rather than trusting the model to decide whether an action should be permitted.

A compromised read-only agent gives me an incident. A compromised agent that can make itself an administrator gives me a very different incident.

4. Expose sensitive information

This one is deceptively difficult because an agent doesn’t need an “exfiltrate data” tool to cause a disclosure.

It may attach a document to an email. Populate a support ticket. Paste source code into an external service. Send customer information through an API. Give another agent information that the second agent was never supposed to receive.

Each step can look legitimate.

The EchoLeak vulnerability in Microsoft 365 Copilot demonstrated why this boundary matters. A specially crafted email could influence the AI system and create a path toward disclosure of sensitive organizational information without the user needing to click a malicious link or attachment.

Before sensitive information crosses an established trust boundary, I want another decision point that answers four questions:

What data is leaving? Who is receiving it? Why do they need it? Where is it going?

This is where approval design matters almost as much as approval itself. If the agent controls the description shown to the approver, “Send requested information to vendor” might conceal a very different underlying action.

The security control therefore needs to derive its approval context from the actual transaction — destination, data classification, tool call and requested scope — not merely from the agent’s natural-language explanation.

Otherwise, we have put a human in the loop without giving that human enough information to make a security decision.

5. Create or delegate privileged access

This is the boundary I expect security teams to wrestle with most as multi-agent architectures become common.

A modern agent workflow can quickly become:

User → Agent → Delegated Agent → Skill → Tool → Resource

The original agent may have legitimate authority. But what happens when it delegates a task to another agent that invokes a tool holding broader credentials?

The question I care about is not simply whether every component is authenticated.

It is whether the authority exercised at the end of that chain still represents what was authorized at the beginning.

I would therefore require another authorization decision when an agent creates privileged access or materially expands or delegates consequential authority.

And I would make that approval very specific:

What authority is being delegated? To whom? For what task? For how long? Can it be delegated again? What happens to it when the task ends or the original authorization is revoked?

OWASP’s AI Agent Security Cheat Sheet addresses excessive autonomy, tool abuse, privilege boundaries, sensitive-data exposure and multi-agent risks. Those risks become harder to reason about as an agent’s authority travels through more components.

Authentication tells me which agent is acting. Authorization needs to tell me whether this particular action, with this particular authority, is still allowed.

Those are not the same question.

A second approval doesn’t always mean a second person

There is one part of this argument I don’t want misunderstood.

I am not proposing that enterprises hire armies of people to click “Approve” every time an agent wants to do something.

That would destroy the value of automation.

For the highest-risk actions, a human approval may absolutely be appropriate. In other cases, the second decision could come from an independent policy engine, authorization service, transaction-control system or another deterministic security control that the initiating agent cannot modify or bypass.

The NIST AI Risk Management Framework takes a risk-based approach to managing AI risks and emphasizes governance throughout the AI lifecycle.

That’s how I think about agent autonomy as well.

The question isn’t: Should this agent be autonomous?

The better question is: Which actions can this agent perform autonomously, and which actions require an independent decision?

For me, the dividing line is increasingly clear.

Let agents search, analyze, summarize, correlate, recommend and prepare. Let them autonomously execute actions that are bounded, observable, reversible and already inside clearly established authority.

Add friction when an action can move money, destroy production data, increase privilege, expose sensitive information or create authority that propagates beyond the original task.

Most importantly, I would never design a workflow where the same agent can propose a consequential action, acquire the authority necessary to perform it, approve that authority and execute the action.

That isn’t autonomy I can govern. It’s self-authorization.

And when AI agents can operate at machine speed across multiple connected systems, a few seconds of independent authorization may be some of the cheapest incident prevention we can buy.

Every DevOps team member knows that dealing with an AI is like being a circus lion tamer. The boss and the audience are happy when the lions sit on the pedestal and roar on cue, but there’s always the danger that they’ll go rogue and bring the whole show to a quick and disastrous end.

The reality is that running LLMs in production means being ready to handle hallucinations, data leakage, misinformation, madness, or worse. Lately, a range of companies have emerged to offer tools, platforms, and systems aimed at helping AIOps teams shoulder the load of keeping AIs in check. They’re building algorithms that are an amalgamation of psychiatrist, police officer, social worker, politruk, and office snitch. Yes, some have their own LLMs buried inside, an irony not lost on anyone, but at least they’re trying.

These tools often have words like “guardrails,” “governance,” or “trust” in their name. They’re closely related to other AIOps tools that focus on development or benchmarking. These emerging product categories often overlap and that overlap will only grow as AI — and the market surrounding the technology — continues to evolve.

Here in alphabetical order are 16 of the most interesting companies working on controlling the wonderful and dangerous LLMs that promise to do so much — as long as they can be kept on that pedestal and behaving.

Collibra

Data products require controlling access enough to stop leaks while providing just the right data that the clients need. Collibra offers an AI Command Center that merges tools for governance and privacy protection with general agent management jobs such as minimizing the number of hallucinations. This Unified Control Plane catalogs the various agents and begins by giving each a “trust score” that measures its riskiness and its readiness. The tool integrates well with other data management tools such as Snowflake or Databricks so that managers can control access by drilling down into full audit trails.

Pricing: No standard pricing information is available. Schedule a demonstration and meet with the sales team.

Standout feature: A focus on securing data across the entire enterprise means that AI governance is just part of a larger strategic goal on accuracy.

Best suited for: Large enterprises that need consistent data quality.

Confident Security

Testing and tracking AI compliance often requires dealing with lots of private or sensitive information and that’s why Confident Security developed a tool for offering privacy to cloud computing called OpenPCC, a name that nods to Apple’s Private Cloud Compute. Teams can choose between the open-source core or the commercial product with a full-fledged SaaS platform and API. Both use layers of encryption to ensure AI inference is computed inside a secure and, if needed, anonymous system and released only when it passes a set of tests. The extra layers of privacy-enforcing math help for applications with more sensitive queries.

Pricing: Usage-based pricing metered by tokens.

Standout feature: Predefined compliance wrappers for specific industries allows them to say, “We take financial responsibility for any breach or misuse.”

Best suited for: Compliance-constrained industries such as healthcare or financial services.

Credo AI

Tracking agents and watching them for risky behavior is what Credo AI was built to do. Enterprise DevOps teams can build a centralized catalog of agents or LLMs and then refer to this “Govern AI Assistant” (GAIA) regularly to keep compliance issues under control. The tool works at all levels from the lowest model level through the agent level, application level, and network level, controlling data flows when necessary. Credo’s system offers “policy packs” for regulatory frameworks from around the world, including the EU AI Act, SOC2, ISO-42001, and the GDPR. Automated guardrails can either track compliance or actively enforce policies.

Pricing: Meet with the sales team for a quote.

Standout feature: Risk assessment aimed at international regulatory frameworks.

Best suited for: Large, multi-country enterprises.

F5 with CalypsoAI

Combining the new with the old is a good way to extend LLM security to a full enterprise. F5 acquired CalypsoAI to add automated red teaming and a portfolio of tools for defending against AI adversaries. CalypsoAI is designed to wrap around the LLMs and make defensive moves at the inference layer by tracking data flows. When necessary, it can probe the models for new or known potential weaknesses.

Pricing: Available from sales team.

Standout feature: Real-time tools and integrated automated red teaming watch for problems sicj as prompt abuse.

Best suited for: High-volume applications such as publicly facing web applications.

Fiddler AI

“All enterprise agents need the AI control plane,” announces the sales literature from Fiddler AI. Its product tracks the behavior of a model and attempts to offer a solid set of explanations for what it does. This knowledge can become the basis for governing and securing the model, as well as assuring its compliance with various rules and regulations. Fiddler works at enterprise scale to aggregate unlimited copies of more than 100-plus metrics to track hallucinations, toxicity, personally identifiable information (PII) leakage, and drift. Then it enforces policies to protect against violations such as jailbreaks, prompt injections, or bias. The goal is to handle the immense scale of telemetry necessary for keeping large deployments of models focused on delivering what the enterprise needs.

Pricing: Free tier for developers; metered usage based on counting traces.

Standout feature: Unified platform integrates guardrails with general model maintenance.

Best suited for: Teams running stacks full of predictive ML models.

Guardrails AI  

Guardrails AI offers two main products: Snowglobe, a simulator that feeds endless streams of synthetic data to your model and looks for anomalies; and Guardrails OSS, a production-ready framework that watches over your LLM and fixes issues in the output. Guardrails OSS enforces various rules or “validators” that address a wide range of issues, including blocking bad responses (PII leakage, jailbreaking) and fixing minor issues such as misformatted JSON. It’s designed to wrap around any LLM and provide a set of, well, guardrails around all interactions.

Pricing: Open-source tools can also be managed.

Standout feature: Real-time surveillance of model behavior for securing outward-facing tools.

Best suited for: Structured applications that need LLM responses to conform to set formats.

Hidden Layer

Finding the deepest weaknesses can be difficult with any computer system, but the challenge is even greater with the inscrutable nature of LLMs. Hidden Layer’s platform offers a comprehensive defense that begins with a cataloging approach intent on finding even the most difficult to locate AIs deep in the stack. From there, it deploys attack simulators and automated red teams to continue to probe the models it identifies. Its AI Bill of Materials (AI BoM) digs into the models themselves, searching through the weights and metadata for weaknesses. The multilayered approach aims to ensure all the models across the enterprise stack are behaving correctly and not leaking crucial information.

Pricing: Available from cloud marketplaces such as AWS, with custom pricing for installations.

Standout feature: AI Attack Simulation enables developers to anticipate potential problems.

Best suited for: Cyberteams securing proprietary models.

IBM’s watsonx.governance

Controlling a constellation of agents and models with IBM’s watsonx.governance begins with building a governance graph that tracks the risk associated with all deployed models. The system tracks development and deployment so that stakeholders can get fast answers on what data went into training and what answers were coming out of the model. DevOps teams can track standard metrics that arrive out-of-the-box, such as model drift or hallucination percentages, or they can define their own. The approach often builds off synergies with other IBM products running in the IBM Cloud.

Pricing: After a free 30-day trial, costs are metered according to usage and deployment breadth.

Standout feature: Full lifecycle integration aimed at covering all governance issues across large clouds.

Best suited for: Large enterprises with multicloud deployments in compliance-heavy environments.

Lakera

When end-users interact directly with the LLM by speaking or writing questions and prompts, Lakera is there to watch over the traffic and keep the agents in line. The tool is designed to stop the kind of jailbreaking and prompt injection games that allow end-users to attack systems. Granular access controls enable fine-grained orchestration of the interactions to prevent unauthorized data leakage or other attacks. The company also sponsors “Gandalf,” a well-known educational game that teaches AI security, and many feel that their tools are better because of the knowledge gained from developing and running it.

Pricing: Free community tier for Lakera Guard with limited requests and tokens. Larger limits come from a meeting with the sales team.

Standout feature: High-speed tool optimized for low-latency protection

Best suited for: Teams delivering answers in real-time environments.

Lasso Security

Taking control of AI across a large enterprise platform requires a breadth of knowledge and the tools to control it. Lasso Security begins with a comprehensive census of AI implementations driven by automated tools that can find the various LLMs through techniques such as scanning source code repositories and continuous integration pipelines. This inventory becomes the foundation for red teaming and runtime enforcement.

Pricing: Custom pricing for each deployment.

Standout feature: Agentic tools aimed at multi-step workflows.

Best suited for: Teams securing relatively open environments that encourage experimentation.

LogicGate

CISOs in need of a no-code approach to governance, risk, and compliance can turn to the Risk Cloud from LogicGate. The tool fills a graph database with information and an assessment of all the services in the enterprise. One aspect tracks potential problems exacerbated by LLMs. Its tool reaches out through prebuilt connections to create what the company calls a “Risk Cloud Quantify,” a value that estimates the potential danger using a mixture of data collection and Monte Carlo simulations. LogicGate also tackles more general problems of management such as evaluating business tradeoffs with its Value Realization Tool. Together, this gives leadership the centralized reporting system for making data-informed decisions.

Pricing: Pricing available after a demonstration.

Standout feature: Deep integration with governance models for traditional stacks.

Best suited for: Full-stack implementations that need governance control over AI and traditional code.

Mindgard

The AI attack surface is broad, varied, and largely unknown. Mindgard’s platform is designed to be an “automated red team,” a set of programs and AIs that constantly poke and try to disrupt the target. Through a constant cycle of discovery, recon, attacking, and defense re-evaluation, the system searches for risks and proposes guardrail improvements to eliminate them. Designed to work with the major LLMs and agents, the system can be deployed quickly to deliver a fast security assessment and — often — a set of new holes to plug.

Pricing: Sandboxed free tier and interactive pricing for larger workflows.

Standout feature: Automated red-teaming simulator deploys hundreds of potential threats for testing.

Best suited for: Security researchers maintaining a high tempo of vigilance.

OneTrust

Managing personal information and other legal restrictions are increasingly important for anyone developing an AI solution. Once you start mixing private data into the training corpus, the DevOps team needs a plan. OneTrust offers what the company calls “Continuous Governance,” which largely means a platform that mixes cataloging, monitoring, and filtering for an entire enterprise stack. AI is just part of a larger system that also manages databases and other compliance challenges. The goal is to offer the right legal filters so that AI developers can get back to wrestling with prompts and context windows.

Pricing: Pricing available by request.

Standout feature: Global privacy compliance database aimed at tracking worldwide compliance issues.

Best suited for: Large, regulated multinational companies.

Prompt Security

When the right solution is to put one gatekeeper for access to an LLM, Prompt Security offers a proxy gateway that will filter the data flowing in and out, watching for any kind of malfeasance. The approach is said to be “LLM agnostic,” which means that it focuses on scrutinizing the input and output, not the internal state of the agents. Prompt Security promises deep content inspection of these data flows, something essential for detecting leaks of PII or other protected information. This architecture also makes it easier to integrate the tool with a variety of AI-driven applications, both internal and external.

Pricing: Open-source tools for developers; full support for deployment available from the sales team.

Standout feature: AI Security Academy for building a depth of knowledge.

Best suited for: Teams able to leverage the power of open source.

Protect AI

Sometimes dangers lurk deep inside a stack, often in hidden locations. The collection of tools from Protect AI examines the whole pipeline for flaws, weaknesses, or hidden problems. The most outward-facing tool, Guardian, is a collection of scanners that use a configurable set of rules to dig deep into the data flows as part of your CI/CD pipeline. Its partner, Recon, offers an automated red team with a predefined collection of attacks to be tested immediately. A third part, Layer, integrates AI security with general cybersecurity tools to build a comprehensive defense. Finally, two open-source project — LLM Security and ModelScan — offer localized, model-agnostic answers.

Pricing: Custom pricing based on the number of models, pipelines, and agents

Standout feature: End-to-end integration for protecting the entire data pipeline.

Best suited for: Teams defending complex pipelines and workflows.

Securiti.ai

One of the top goals for anyone working with AI is to make sure that the same rules of sharing data from, say, a database also apply to all the LLMs running on the same platforms. Security.ai calls this process data security posture management (DSPM). Its centralized platform searches out, identifies, and tracks all the agents running inside the enterprise and then controls their behavior with tools such as Context-Sensitive Firewalls, Data Minimization, and Data Flow Governance. Several dozen tools work together in a constellation that harmonizes governance with privacy awareness and data management.

Pricing: Custom pricing based on volume.

Standout feature: Data command Center for linking all security issues.

Best suited for: Enterprises with complex workflows with custom data governance issues.

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.