Who should own agent security and operations? Part one: Five org structures

Agents went from rogue pilots to essential workers in the space of two years, and for organizations who are at the forefront of this change, there was no playbook to follow, and no obvious answer to questions around who owns agent security and operations. Everybody was improvising, and several different ownership structures have emerged.

This series puts together insights gathered across dozens of the world's most forward-thinking organizations when it comes to operationalizing AI. We hope sharing these observations will help security and IT leaders who are looking for guidance as they navigate these uncharted waters.

Why this has become so contentious

The clearest finding across our conversations over the last year is that ownership of agent security and operations is mostly inherited rather than designed. Security leaders describe being 'voluntold' or taking the reins because nobody else would.

Where a structure does exist, its most common form is not a security-led function or a Chief AI Officer, but a cross-functional AI committee, council or 'center of excellence' that holds the decision, with security sitting beside it rather than above it. These bodies are chaired by legal, risk or the business about as often as by technology, and their authority varies widely.

The mandate to adopt agents usually arrives top-down and funded, from a CEO, a new CTO or the board, while the mandate to control them arrives bottom-up and unbudgeted.

This usually means fragmentation: each team touches one piece of agent control, and the whole falls through the gaps. Approvals are granted by category rather than reviewed agent by agent. IT runs discovery tooling but no team 'owns' the inventory it produces. The SOC fields the runtime alerts. Cost is usually pushed back to the business units running the agents. And nobody yet owns the question of whether the agents are any good or when they should be retired, even as estates fill with abandoned agents.

Why "security and operations"?

Agents are no longer isolated pilot programs - agents are already doing work the business depends on, and the job is no longer simply oversight of a risk, it's how to run something productive, and run it well. In other words, who should own the risk is a question about control, but who should own the operations is a question about output, cost, reliability and improvement.

Security is asked to reason about the behavior of non-deterministic software, to vet the tools and external servers an agent is allowed to call, and to investigate incidents that look nothing like a compromised endpoint. IT finds itself issuing and governing identities for software that already outnumbers its human users. Data, finance and legal each inherit an agent-shaped version of their own discipline.

Naming an owner is therefore less about reassigning an old responsibility than about deciding who absorbs a new and growing body of work that nobody was resourced for.

On the surface, security and operations are different crafts. Security spans identity and access, assurance and audit, detection and response, and the adversarial instinct for what could go wrong, all of it pointed at whether an agent should be allowed to act. Operations is concerned with whether the work is getting done and what it costs. Security owns whether an agent may act; agent operations owns whether it is acting well and what it is costing. Those are different questions needing different judgment, but they are answered from the same evidence, because what an agent actually did is the raw material for both. That shared substrate is why the two keep arriving in the same conversation, and why the question of who owns them is one question rather than two.

The practical question, then, is what shape the owning team takes, and here are five possible answers to that:

The five shapes - who owns agent security and operations?

Shape	Where it sits	Good at:	Things that might get missed
1. Security absorbs it	Inside the security organization	Risk, evidence, incident response, audit	The 'value' piece - what work are agents actually doing, how important is it, and where does security need to be balanced with business benefits
2. A function inside IT and platform	A small team within IT, alongside identity and endpoint	Inventory, provisioning, standards, lifecycle	Behavioral risk, and the in-depth risk investigation / triage that security expects
3. A standalone AI function under a head of AI or CAIO	A dedicated AI team with its own leader and reporting line	Speed, visibility, cross-functional authority	Durability; it depends on an executive sponsor
4. The platform engineering model	A platform team, agents treated as production workloads	Reliability, cost discipline, operational rigor	Non-engineering agents and business-built workflows
5. No function at all: we all own it	Responsibility distributed to every team that uses agents	Adoption speed, local judgment, low overhead	Anything that requires a view across the whole estate

Shape one: security absorbs it

CEOCISOCIOAgent securityAgent operations Purple is agent security, whether an agent may act. Orange is agent operations, whether it is acting well and what it costs.

This is where most regulated organizations sit today. Security owns risk, and it has the mandate to say no. Orgs taking this shape generally have strong evidence / investigative ability: security function knows how to build an audit trail, run an investigation and answer a regulator.

But security is built around things going wrong, so its reflex when an agent behaves unexpectedly is to contain it, and containment stops the work. No one in that reporting line is accountable for whether the agents are producing anything, what they cost, or whether a team quietly dropped an agent because it was no good, so those questions go unasked until a finance review forces them.

Another distinction here: we find security teams and SOC / Incident Response teams often have different reporting lines; the SOC being a separate team that only gets involved for a very specific workstream and use case.

Verdict: A sound default for financial services, healthcare and other regulated organizations where audit evidence is important, but one that already strains because their agents are carrying revenue-generating work today and nobody in this reporting line is accountable for how well it goes.

Shape two: set up by IT team, security does runtime

CEOCISOCIOAgent securityAgent operations Two reporting lines, joined only by a working relationship. This is the seam where each team assumes the other is watching.

We also see this setup pretty regularly: a small team sitting within IT, next to identity, endpoint and SaaS management, treating agents as a new class of asset to inventory, provision and retire. Its appeal is familiarity: the organization already knows how to run this kind of team, the budget line exists, and nobody needs convincing that a new discipline is warranted. It fits the parts of the problem that look like lifecycle management, which is work IT has done for two decades under other names.

The limit shows up in depth rather than breadth. Knowing what an agent can access is a configuration question, and IT handles configuration well; understanding how it behaves when it runs is closer to detection engineering, so an IT-housed function needs security alongside it. Where that partnership is formalized, this shape holds. Where it's assumed, there's a risk the two teams find out during an incident that each thought the other was watching.

Verdict: Potentially the most effective set up, as long as ownership lines are clearly established between the two functions. More on this in part two.

Shape three: a standalone AI function under a head of AI or CAIO

CEOCISOCIOHead of AI or CAIOAgent securityAgent operations The two jobs sit as far apart as the org chart allows, each with its own line to the top.

The argument for this shape is that agentic operations are too consequential to be a sub-function of anything. If agents are going to carry a material share of the work, the people who understand how they run, how to measure them and how to improve them suddenly become some of the most important in the business.

This shape is rare and most likely a transitional arrangement rather than an end state, and it follows the arc of the Chief Digital Officer: prominent while the capability is novel and the board wants a name attached to it, then absorbed back into platform and IT once running agents is ordinary work. We'd expect that reporting line to be at its most common in 2027/28 and decline afterward. Gartner's projection that by 2028 a third of enterprise software applications will include agentic AI, with 15% of day-to-day operations completed autonomously, is roughly the point at which this stops being novel enough to need its own executive.

Verdict: The right structure for an organization making a deliberate, board-level bet on agents over the next eighteen months. Becomes an opportunity for the CISO to work with the Head of AI to shape business decisions given agent operations is a priority.

Shape four: the platform engineering model

CEOCISOCTOAgent securityPlatform engineeringAgent operations Agent operations sits a level deeper, run as a production discipline. Anything built outside the pipeline never reaches it.

Here's the wild card: agents are treated as production workloads rather than as a new category of risk, so they get service levels, on-call rotations, runbooks, deployment pipelines, cost budgets and post-incident reviews.

The thinking here is that an agent in production has more in common with a service than with a document or an endpoint: it runs unattended, fails quietly, and degrades as its dependencies change, so whether it is working is a matter of observed behavior rather than declared configuration. And engineering teams have spent 10, 20 years building exactly that practice.

What it misses is everything outside engineering's field of view. The agent a finance analyst assembled in a SaaS tool, the workflow a marketing team built on a platform nobody in engineering administers, the browser agent an employee adopted on their own account: none of these arrive through a deployment pipeline, so potentially none of them show up. Run this shape well for your engineered agents and you can still be carrying a large estate you have never seen, which is the gap a first real inventory exposes.

Verdict: Great for engineering-led organizations, particularly technology and SaaS businesses, provided something else is made accountable for the agents that never pass through a deployment pipeline.

Shape five: no function at all

Executive teamCISOFinanceMarketingEngineeringAgent securityAgent operationsAgent operationsAgent operations Agent security keeps a reporting line. Agent operations happens separately in each team, and nothing joins it up.

In this model, security and operations are not looked at as a 'function' at all, because agentic work will inevitably dissolve into everyone's job the way spreadsheets and search did. Asking who owns agent operations in 2030 would then sound like asking who owns email operations: a small team keeps the plumbing running, but the actual practice belongs to whoever is doing the work.

The more agents become integral to a functioning business, the more this starts to look like the most likely end state.

The reason it might not land in practice, at least today, is that practice and accountability are very different things. Practice will distribute, almost certainly; but accountability for the estate as a whole cannot, because no single team can answer the questions that matter from where it sits. Questions like:

• How many agents are running?
• Which hold access they no longer need?
• Where the same work is being done three times?
• Which failures are being quietly absorbed?

Those need a view across the whole, and a view across the whole needs someone whose job it is to hold it.

Verdict: An accurate description of where practice is heading, but a poor one for where accountability should sit.

Where ownership sits today

We looked across over 60 organizations that have come to us for help answering the ownership question, and classified them as close as we could to the five shapes above. Some fit more naturally into these descriptions than others, and some organizations are hybrids that split detection from remediation (see part 2). But generally, we see a pretty even spread across the five shapes:

Shape	Number of organizations (lower bound)	How it shows up
Security absorbs it	About 12	Mostly by default, not design: a security leader is assigned the work or volunteers because nobody else will. Often limited to risk, with adoption owned elsewhere
A function inside IT	About 7	IT owns the tooling and monitoring because it already owns endpoints and licenses; security advises
A standalone AI function	About 10	A head of AI, innovation director or AI enablement team reports directly into the CEO, security remains very involved
Platform engineering	About 7	The CTO or chief architect owns the agents engineering builds, and security looks at the edge
No function at all	About 10	Agents in every department, with nobody able to count them

Which shape are you today?

Most organizations have drifted into one of these without deciding on it, so the more useful exercise is working out which one you are before working out which one you want. Six questions that will probably get you there:

1. When a new agent is proposed, who can approve it without consulting anyone else? If the answer is a security leader, you are in shape one. If it's a more general IT function, shape two. If a CTO figure, shape three.
2. Who gets the bill? Follow the token spend to whoever is accountable for it in a budget review, and you have usually found the real owner regardless of the org chart.
3. If an agent stopped working tomorrow, how long before anyone noticed, and who would notice first? A platform-engineering shape answers this in minutes. A distributed shape often answers it in weeks, via a complaint.
4. Can anyone produce a current list of every agent running in the business, including the ones nobody deployed through a pipeline? If that list exists and is trusted, you have a central function whether or not it has a name.
5. When an agent behaves unexpectedly, is the first instinct to contain it or to understand it? Containment suggests security ownership; investigation of the work itself suggests an operations owner.
6. Who is accountable for an agent getting better over time? This is the question that most often has no answer at all, and the gap it reveals is the strongest argument for a named function.

If the answers point at different teams, that is not a failure of the exercise. It is a map of where the handoffs are unowned, and those seams are where most of the real problems live.

Part two in this series looks more granularly at the day-to-day tasks involved with setting up, managing, and securing agents, and which functions have started to assume responsibility for them.

References

1. Gartner, cited in Geordie positioning material: by 2028, 33% of enterprise software applications will include agentic AI, with 15% of day-to-day operations completed autonomously. Gartner also predicts 40% of agentic AI projects will face cancellation due to unmanaged risks.