You Can Hire a CISO and Still Have No One Who Owns the Agent

A number from Deloitte's 2026 work has been sitting with me. Forty-nine percent of organizations now have a CISO, up from 31% in 2023. On its own that reads like progress. Put it next to the second number and the picture changes: only 11% of those same leaders still count legal, compliance, and risk among their top priorities. Meanwhile 80% of automation leaders plan to speed up their AI-agent investment, and only 21% say their agentic AI governance is mature.

Read those together and you get the shape of the problem. More companies have the title. Fewer of the people holding it have the authority or the mandate that the title implies. And into that gap, everyone is pushing autonomous agents that plan, call tools, and act.

I have watched this pattern from the operator's seat, running security operations inside large enterprises and before that spending years where the accountability for a decision was never abstract. The failure here is not technical. It is a question nobody answered out loud: when this agent does something wrong, whose name is on it?

A title is not an authority

Hiring a CISO tells the board the box is checked. It does not tell you who can stop a deployment, who owns the data an agent touches, or who signs off when that agent is allowed to act without a human in the loop. In most orgs those three powers live in three different places. Security owns the identity. A data or privacy function owns the records. A product or automation leader owns the action. The CISO is named, but the authority is split four ways across the C-suite, and every one of those hands is on the agent.

That is fine when an AI feature returns an answer for a person to check. It breaks the moment the system acts on its own. An agent does not wait for the quarterly governance review. It provisions, queries, sends, and deletes at machine speed. The 11% number is the tell. When legal, compliance, and risk fall off the CISO's priority list, the connective work that turns a title into an accountable decision falls with it.

Three named owners for every agent

The fix is not another framework and it is not a bigger title. It is assigning three named owners to every agent you run, before it runs. Not roles. Not committees. People, by name, who can be asked a direct question and give a direct answer.

• Identity owner. Who is this agent, and what is it allowed to be? This person owns the agent's credential, its registration, and its lifecycle. When the agent's token shows up authenticating to a resource it has never touched, this is the person who gets the alert and decides whether that is expected.
• Data owner. What classes of data can this agent read and write? This person owns the blast radius on the data side. If the agent can reach PHI, regulated financial records, or anything under a contractual obligation, this owner set that boundary and can defend it.
• Action-class owner. What is this agent allowed to do without a human, and where does it have to stop? Read-only is one class. Write to a staging system is another. Send to a customer, move money, or change production is a class that should require a named human in the loop. This owner set those tiers and owns the stop control.

Three names, one agent. If you cannot fill all three for an agent you are running, you do not have a governance gap. You have an ungoverned agent, and you found out by trying to name its owners.

The RACI a vendor can steal this week

Here is the one-slide version, because the point of this is that you use it, not admire it. Build a table. One row per agent. Columns:

| Agent | Identity owner | Data classes + owner | Action tier + owner | Human-in-loop trigger | Stop control | |---|---|---|---|---|---|

Fill it in for every agent in production and every agent someone is about to ship. The rows you cannot complete are your real exposure, ranked. The value is not the artifact. It is who goes quiet when you ask them to sign their row.

This maps cleanly onto Section 10 of the AI Governance Toolkit, our free template set, which already carries agent identity and registration, tool and action authorization by blast radius, tested stop controls, and decision-trace logging grounded in the NIST AI RMF and the OWASP Agentic Security Initiative. The RACI above is the first page you fill in before you touch the rest of it.

Visibility first, then owners, then policy

The sequence matters, and most programs run it backward. They write the policy first, which assumes you already know what agents exist. In practice you do not. Employees are spinning up agents in Claude Code, Cursor, and Codex that touch production data, and none of it appears in a procurement record because nobody procured it.

So the order is: visibility, then named owners, then policy. Find what is running. Assign the three owners to each one. Only then does policy language have something real to bind to. Run it the other way and you get a document that governs agents you cannot see, owned by no one, enforced by a title that four people share.

The CISO number going up is good. But a title is a promise, not an authority. The organizations that come out of this well are not the ones that hired fastest. They are the ones that can put three names next to every agent and have all three answer when asked.

If you are standing up this layer and want a second set of eyes on the owner map before your agents outrun it, that is the conversation CarbeneAI is built for.