Antares
All insights
Security Leadership & vCISOSeptember 9, 2026·8 min read

What a vCISO Actually Does When Agentic AI Shows Up

The gap isn't the technology. It's the lack of ownership. A vCISO folds agentic AI into the governance structures the organization already has.

The gap isn't the technology. It's the lack of ownership.

Most organizations are adopting agentic AI the way they adopted SaaS fifteen years ago: department by department, ad hoc, and driven by utility rather than policy. IT approves a tool. Sales starts using an agent for outbound outreach. Operations automates a workflow that touches financial data. Marketing connects an agent to the CRM.

None of it goes through the same scrutiny a new vendor, a new integration, or a new privileged user would receive.

The result is a familiar pattern: a distributed, unmanaged risk surface that doesn't appear on anyone's risk register until something goes wrong. The individual tools might be secure. The cumulative effect is not.

This is not a technology gap. It is a governance gap. And it is exactly the kind of problem a vCISO is built to solve.

The vCISO Angle: Not a New Discipline

There is a temptation, when a new category of technology arrives, to invent a new discipline around it. "AI governance" becomes its own initiative, with its own committee, its own framework, and its own reporting line. It gets bolted onto the security program like a separate wing on a building.

A vCISO doesn't do that.

The vCISO's role is to recognize that agentic AI is a new category of actor—one that can read, decide, and act—but it is not a new category of risk. It is the same risk the organization already manages: unauthorized access, excessive privilege, vendor dependency, operational failure, and insider threat. The agents are just faster, more autonomous, and less likely to exercise the contextual judgment a human would apply between actions.

The work, then, isn't to create a parallel AI governance program. It's to fold agentic AI into the governance structures that already exist: the risk register, the vendor review process, the authorization workflow, and the leadership reporting cadence.

The question isn't whether your organization has an AI governance program. The question is whether your existing governance program knows that agents are now making decisions inside it.

What This Looks Like in Practice

Here is what a vCISO actually does when agentic AI shows up in the business. This is not a theoretical framework. It is the operational checklist.

1. Find the agents

Most organizations cannot answer a simple question: "Which AI agents are currently deployed, and what are they authorized to touch?"

The first task is inventory. This is not a technology discovery exercise. It's a conversation with department heads, a review of procurement records, an audit of API integrations, and a look at what credentials are being used to access what systems.

The deliverable is simple: a list of every agent, what it does, who owns it, and what it connects to.

This is the most basic step in any risk management process. Yet it is often skipped when AI adoption happens outside the traditional technology procurement process.

2. Understand what they can touch

Once the agents are found, the next question is scope. What permissions does each agent have? What data can it read? What systems can it write to? Can it send email, move money, change configurations, or approve transactions?

This is a permissions review, but with a difference. A human user with broad permissions operates within organizational and contextual boundaries, and ideally exercises judgment about what they should and shouldn't do. An agent has no such intuition. It has its instructions, its controls, and its access.

An agent that can read customer data and send email is not a low-risk tool. It is a high-consequence actor.

3. Classify by consequence, not by department

The natural instinct is to classify AI agents by who uses them: "Marketing AI," "Finance AI," "IT AI." That's the wrong axis.

The right axis is consequence. What happens if this agent gets it wrong? What happens if it is compromised? What happens if it acts on bad data or misinterprets an instruction?

An agent that drafts internal summaries is a low-consequence actor. An agent that moves money, touches customer data, or changes security configurations is a high-consequence actor. The level of scrutiny should follow the consequence, not the department name.

This is the same logic used for third-party risk: a vendor that processes payments gets more scrutiny than one that provides office supplies. The actor is different. The logic is identical.

4. Define decision rights before something goes wrong

The most important governance question for any agent is simple: "What can this agent decide on its own, and what requires a human?"

This should be defined before the agent goes live, not discovered after an incident. It should be documented, reviewed, and attached to the agent's authorization record.

A vCISO drives this conversation. For each agent, the team must answer:

  • What is the agent authorized to do autonomously?
  • What is it authorized to recommend but not execute?
  • What is it explicitly forbidden from doing?
  • Who is accountable when the agent acts?

This is where authorization, decision rights, and accountability converge. It is the same logic as role-based access control, applied to a non-human actor. And it connects directly to the authorization piece: if an agent's decision rights aren't defined, it doesn't get approved.

5. Test agent failure

Security teams run tabletop exercises for ransomware, for insider threat, for supply chain compromise. They simulate what happens when a system fails, and they walk through the response.

Agents should be part of those exercises.

What happens when an agent misreads a prompt and sends a customer the wrong data? What happens when an agent is compromised and used to exfiltrate information? What happens when two agents interact in an unexpected way?

These are not hypothetical scenarios. They are operational realities. And they need to be tested the same way any other failure mode gets tested.

The vCISO doesn't need to run these exercises personally. They need to make sure agent failure scenarios are included in the existing exercise calendar, not treated as a separate "AI risk" conversation.

6. Manage third-party and model risk

Every agent is built on something: a foundation model, a third-party platform, a set of APIs, a data pipeline. Each of those is a dependency.

The vCISO's role is to make sure that dependency is reviewed the way any other third-party access would be reviewed. What data leaves the organization? What does the vendor's security posture look like? What happens if the model changes or the vendor goes away?

This is vendor risk management, applied to the AI supply chain. It isn't new. It's just that most organizations haven't applied it here yet.

7. Report through existing governance

The final piece is reporting. Agentic AI should not have its own separate reporting track. It should be embedded in the standard risk update that already goes to leadership.

That means the risk register includes agents. The remediation list includes agent-related findings. The quarterly business review includes a section on AI risk that looks exactly like the section on third-party risk or access management.

The vCISO's value here is not creating a new report. It's making sure the existing report reflects the new reality.

The Through-Line

A vCISO's value in the age of agentic AI isn't knowing more about AI than anyone else in the room. It's refusing to let a new category of actor skip the governance process everything else already has to go through.

The organizations that get this right won't be the ones with the most sophisticated AI frameworks. They'll be the ones whose existing governance simply expanded to include the new actors. The vCISO makes that happen.

A Final Thought

Agentic AI is forcing a fundamental shift in how we think about system access. In the past, we managed what systems could do. Then we managed what users could do. Now we have to manage what agents can decide to do.

It's not a different problem. It's the same governance problem with a faster, more autonomous actor. And the organizations that treat it that way—that apply the governance they already have rather than inventing new governance from scratch—will be the ones that move forward with confidence, not fear.

About the author
Branden Rowe, Founder and Managing Director of Antares Security

Branden Rowe

Founder & Managing Director, Antares Security

Branden Rowe is the Founder and Managing Director of Antares Security, a cybersecurity advisory practice focused on helping organizations make better security, risk, and governance decisions. His work spans security leadership, cyber risk, governance, and operational security across regulated and complex enterprise environments.

Need a senior advisory perspective on your security program?

A 30–45 minute advisory call covers operating context, current posture, and the decisions forcing the work. If a fit exists, we propose scope.