Agentic AI
,
Artificial Intelligence & Machine Learning
,
Next-Generation Technologies & Secure Development
Why Better AI Models Alone Can’t Establish Reliability in Autonomous Security
Naresh Agarwal
•
November 3, 2026
Image: Shutterstock
Enterprises are using artificial intelligence across security operations to investigate alerts, identify vulnerabilities, prioritize risks and recommend what to do next. But there’s a big difference between asking AI for a recommendation and allowing it to act autonomously on that recommendation.See Also: 28.3% of CVEs Exploited Within 24 Hours — Can Your Bank Keep Up?
Most organizations are still cautious about making that leap. A 2026 Cloud Security Alliance survey found that only 13% of organizations are operating fully autonomous agentic AI models. More commonly, agents work independently on lower-risk tasks while humans make higher-risk decisions.
It’s tempting to put this down to a lack of trust in AI. But security teams have never trusted technology simply because it works most of the time – as there’s always a chance it may not. Trust comes from understanding how a system behaves and being able to see what happens when something goes wrong.
That becomes harder when AI moves from generating an answer to taking an action. Keeping a person in the approval loop is therefore not necessarily a sign of hesitation. Often, organizations simply do not have enough evidence to be comfortable handing over the decision entirely.
The Model Is Only One Part of the System
A lot of effort has gone into making models safer and more reliable: reducing hallucinations, improving reasoning and understanding why a model produced a particular answer. All of that matters.
But once AI starts taking actions, understanding the model alone isn’t enough. You also need to know what it can access, what it is allowed to do and what happens when it acts. Most organizations are still building that visibility. Deloitte found that only 21% of enterprises surveyed had mature governance in place for agentic AI, including controls around independent actions, monitoring and audit trails.
The same model can power an agent that identifies a vulnerability in a code repository or one that goes further and changes the code itself. Those are very different security propositions.
Much of that difference lies in the architecture around the model: its connections to other systems, available tools and credentials, blast radius of system access, memory and the rules that govern when an agent can act independently.
Security teams already apply this thinking to people, applications and infrastructure. AI introduces a new participant into that environment, and it needs to be accounted for with the same discipline.
Cost Is a Signal on How AI Is Behaving
Understanding how AI behaves in production also brings cost into the picture.
AI usage can vary significantly. A workflow that normally makes a handful of model calls may suddenly make hundreds. An agent may get stuck repeating the same task, use a more expensive model than needed or continue operating long after it should have stopped.
The immediate symptom may be higher spend, but the underlying problem is operational: Something is behaving differently from what was intended.
Cost therefore becomes useful beyond budgeting. Changes in consumption can help uncover inefficient workflows, runaway processes and other unexpected behavior that may otherwise be difficult to spot.
Security and FinOps teams still have different responsibilities, but AI gives them more reason to look at some of the same operational signals. Together, those signals provide a better picture of how AI is actually behaving in production.
That history also becomes important when deciding how much responsibility an AI system should be given.
Autonomy Comes Gradually
There’s a tendency to think of human approval as something we will eventually engineer away. But it is still unclear whether that is the most useful way to look at it.
If an AI system identifies a vulnerability and suggests a fix, it makes sense for an engineer to review it. If the system performs reliably over time, the organization may become comfortable allowing it to handle certain lower-risk cases autonomously.
Additional autonomy should come after the evidence, not before it.
This is how we already approach automation in other sensitive systems. Start with a limited scope, observe the results, understand where things go wrong and gradually increase what the system can handle independently.
There will also be decisions where human approval continues to make sense. Prioritizing a security finding carries a very different consequence from changing production code or revoking access to a critical system. Autonomy doesn’t need to be uniform across every task.
Building Confidence Through Evidence
AI models will continue to improve, but capability alone will not solve the trust problem.
For security teams, much of the discipline is familiar: Understand what is operating in the environment, put appropriate controls around it and retain enough evidence to investigate when something does not behave as intended.
What AI changes is the nature of the system being governed. We are moving from software that largely follows predefined instructions to systems that can interpret a situation, choose a course of action and execute it.
Organizations don’t need AI to be perfectly predictable before putting it to work. They do need to understand where it performs reliably, where it fails and where the consequences still warrant human judgement.
As that evidence builds, the boundaries can evolve. Some actions can happen automatically, while others will continue to need approval. That is a much more practical path to autonomy than asking organizations to trust AI before they have seen enough of how it behaves.
——————————————————-
Click Here For The Original Source.
