Who should own agent security and operations? Part 2: The division of labor
Thirteen agent security & operations tasks, and who typically owns them.
Part one of this series mapped out five shapes of org charts that have started forming when it comes to the question of agent security and operations.
Here, we take it a level deeper, and break down the work itself, organized by 13 tasks that running an agent estate commonly demands, who tends to own each one today, and what factors are most useful to take into account.
As with part one, this isn’t a one-size-fits-all. But as a starting point, based on conversations with more than 60 organizations, several of which are Fortune 1000 and consisting of some of the most forward-thinking and agentic-first organizations out there, we’ll summarize agentic security and operations ownership broadly as follows:
Thirteen agent security & operations tasks, and who typically owns them
- Contested or unowned
Let’s break down the factors that determine who owns what. In rough chronological order:
Onboarding: Getting an agent from proposed to live
1. Discovery and inventory
Current owner: Agent Operations, if it exists. Today, mostly IT by default.
The starting point: how do we get a current list of every agent that’s actually running? No single team can produce from where they sit, but this is the foundational question that everything that follows relies on.
‘Agent operations’ as a term may not exist yet in some orgs, some may want to avoid its creation entirely (see part 1). Until then, the question of agent discovery falls to whoever already does it: SaaS and asset management inside IT, or the shadow-IT instinct inside security.
Across the organizations we’ve spoken with, the doing and the owning have come apart. IT and end-user computing teams usually roll out the discovery tooling, because they already run the device management it depends on, but the request for an inventory tends to come from security or an AI committee, and once the list exists nobody quite owns it. In one company, agents were being built in cyber, IT, finance and commercial, and the person we spoke to doubted that even their director of AI had a clear count.
There’s no guarantee how complete any of them can be, and the gap is always the same: the pipeline registry sees the agents that shipped through it and misses every agent a business team assembled in a SaaS tool or an employee adopted on their own account.
What good looks like:
The win here is naming an owner for the list itself, not only for the tooling that compiles it. IT and end-user computing are the right teams to run the collection, since they already manage the devices and the SaaS estate the sensors read from, but the inventory has to belong to someone as a living asset: kept current, reconciled across sources, and answerable for the agents that fall between them.
Where an agent operations function exists, that ownership sits most naturally there, because discovery is the foundation every later task reads from. Where it doesn’t, the pragmatic move is to hand the list to IT asset management, with an agreed refresh cadence.
The important thing is completeness, so good discovery combines the pipeline registry, the endpoint sensor and the SaaS and browser sources, and treats the gaps between them as the main event rather than an afterthought.
2. Intake and approval
🟠 Current owner: unresolved. In most organizations an AI committee or risk function runs the gate, and security holds a veto.
This one is still an open question in a lot of companies. How do you go about putting some sort of gate in front of new agent creation - and (the part most organizations miss) a second gate in front of every significant new capability granted to an agent already approved? And how do you do this in a way that keeps up with the demand across your employee base, without slowing them down?
Agent operations convenes the gate and security holds a veto, but whether it is a security control or an operations one is the question no one has settled.
How to settle this:
The factors that should be taken into account are blast radius, reversibility and regulatory exposure. A read-only productivity agent goes through a fast lane, an agent that can move money or write to a system of record warrants a deeper review.
The organizations that have made this work stopped reviewing agents one at a time a while ago. A large European telecoms provider described the sheer volume of agents waiting for approval as its real problem, and answered it with pre-approved building blocks, while elsewhere AI committees sign off on patterns and risk tiers rather than on individual agents. The gate also tends to sit at the point of sharing rather than creation, so an experiment someone builds for themselves goes unremarked until it’s published to a team or wired into a real business process, and the review opens again when an agent’s reach changes, most often when it moves from reading data to writing it.
So what’s the fastest way to work out whether an agent belongs in a security queue at all? Mostly it comes down to what the agent can reach and whether it can write, which is information an inventory can carry automatically rather than something a builder fills in on a form. Geordie scores each agent’s risk from what it’s connected to and what it actually does, so the fast lane can largely run itself and the review only sees the agents that warrant one.
3. Identity and credential issuance
Current owner: IT / identity.
Agents need identities of their own, usually modeled as non-human or workload identities, and issuing, rotating and vaulting those credentials is work an IAM team has done for service accounts for years.
The pressure on this task, again, is scale, because agents can outnumber human identities quickly, and the tooling built for human joiners and leavers was not sized for that volume or that churn.
In practice, few identity teams have started on this yet. We regularly come across agents running on a person’s own credentials, including a shared team agent that inherited everything its creator could reach, and in one organization the engineering lead was still arguing over whether agents should be service accounts or app registrations. Until that’s settled, an agent’s identity is whatever its builder happened to be signed in as, which makes the next task a good deal harder than it needs to be.
What good looks like:
Every agent should carry its own identity from the first day it runs, modeled as a non-human or workload identity, never a person’s login and never a shared team account. Security owns the standard for what a sound agent identity looks like, meaning scoped, attributable, rotated and vaulted, while the identity team executes against it at the volume agents now arrive in. That’s the same division of labor IAM has run for service accounts for years.
The reason to settle this early is that it is cheap up front and expensive to retrofit: an estate where every agent is already distinguishable by its own credential makes scoping, detection and retirement tractable, while one where identity was left to whoever happened to be signed in makes all three harder than they need to be.
4. Entitlement scoping
Current owner: shared across identity, the data owner and security.
Entitlement scoping is the work of deciding exactly what a given agent is allowed to reach and do, and holding that down to what its job actually requires. An agent runs with whatever access its credentials carry, so if no one narrows that access deliberately it can touch far more than its task needs, and anyone who hijacks it inherits the same reach. Scoping those entitlements is what keeps that reach small enough that a mistake or a compromise stays contained.
What good looks like:
Ownership is shared because no single team holds all the context the decision needs. Identity provisions the access, the owner of the data or system approves what the agent may reach, and security sets the least-privilege policy and the ceiling on blast radius. How many of the three have to sign off on a given agent follows from data sensitivity and blast radius, so an agent reading public reference material clears with far less ceremony than one with write access to a system of record.
Supply chain: The tools, connectors and servers an agent is allowed to call
5. Tool, connector and MCP server vetting
🟠 Current owner: unresolved. Split between security and platform engineering.
This is another unsettled one, but it’s increasingly relevant.
An agent is only as trustworthy as the tools and servers it can call, and those are a supply chain in the security sense: a Model Context Protocol server an agent connects to can carry the same risk as a third-party dependency pulled into a build.
What good looks like:
How this sometimes ends up is with security owning the risk judgment, and platform engineering owning the curated catalog agents draw from, but the field has not settled whether the real control is a vetted internal registry or active assessment of arbitrary external servers. And arguably, a serious program needs both.
Where organizations have made progress, it usually looks like a pre-approved catalog, either a marketplace of MCP servers, connectors and skills that people can request from, or an internal registry that security has already vetted. One manufacturer summed it up well: they told us they don’t want ten people writing MCP connectors for the same service and hosting them on their own machines. Gateways come up a lot here too, though several teams admitted theirs were used far less than they’d hoped, and a gateway only governs the traffic that actually passes through it. Skills are the softest spot of all, since almost nobody checks with the risk team before pulling one from GitHub.
Runtime: What matters once the agent is working unattended
6. Observability and instrumentation
Current owner: whoever runs the instrumentation, which today usually means IT at the endpoint and the AI or platform team at the gateway.
Whoever builds this, everyone else ends up living off it, because cost, reliability and most of threat detection can’t be answered without the record it produces.
In practice, the work splits by where agents run. Instrumentation on laptops and desktops lands with IT and end-user computing, who own the devices and are understandably protective of what gets installed on them, while telemetry from cloud platforms and AI gateways sits with whichever architecture, data or AI team administers those accounts. One data team we spoke to had started pulling every AI platform’s logs into its own pipeline, which is how an analytics function ends up holding the evidence a SOC will one day need. The team that instruments what agents actually do tends to inherit everything that depends on that record, whatever the org chart says, and that’s the best argument for deciding deliberately who it should be.
What good looks like:
Name one owner for the agent telemetry record on purpose, rather than letting it accrete to whichever team built the first pipeline. The natural home is agent operations, or the platform or AI team that administers the gateways, with an explicit mandate to serve security, finance and the business from a single record instead of each standing up its own. Splitting the collection by where agents run is fine as plumbing, with IT on the endpoint and the platform team on the cloud and the gateway, as long as the evidence lands somewhere unified and queryable. The SOC, the cost owner and the reliability owner all end up living off this record, and an estate with five disconnected logging efforts answers none of their questions well.
7. Cost and FinOps
Current owner: increasingly the business units running the agents, with finance holding the line.
Token spend is real money, and it’s usually the first thing about the agentic estate that a budget review notices. Typically, security wants nothing to do with it. We often hear that the cost component sits with an AI governance team or with finance rather than with security, and the direction of travel is chargeback, with business units owning their own consumption and line managers approving spend tiers, so that nobody in IT is left deciding whether a colleague’s agent is worth a hundred dollars a month.
At one software company, monthly agent spend per employee ranged from $2 to $2,000, and three separate teams (engineering program management, business automation and accounting) were each analyzing it on their own, which says a fair amount about how unowned this still is. Platform engineering still sets budgets and guardrails for the agents it runs as production workloads, but for everything else the bill is drifting toward whoever benefits from the work.
What good looks like:
Cost should, and probably will, end up in the business units running the agents, with finance setting the chargeback model and holding the line, and security kept out of it beyond the visibility it needs for everything else. What makes that workable is per-agent attribution: spend tied to the agent that incurred it and the team that benefits, so a line manager can approve a tier without anyone in IT adjudicating whether a colleague’s agent is worth a hundred dollars a month.
But the figure worth managing is cost against output rather than cost on its own, because an agent running at two thousand dollars a month on revenue work is cheap and a fifty-dollar agent nobody uses is not. The teams that manage these two things under the same lens are the ones that get this right.
8. Reliability, quality and improvement
Current owner: agent operations, with the line-of-business owner.
So what about optimization? This is something people are starting to ask for, but the ownership is very cloudy. In this bucket we can put: tracking drift and hallucination, putting a value on what an agent produces, or simply asking, as one technology leader did, whether a given agent is earning its keep or burning money on work an intern could have done. Hardly anyone could name the team that owns this, and a couple were asking their security tooling to provide it, which tells you how keenly the gap is felt.
What good looks like:
Because no team competes for this one, just like everything else, it has to be intentionally assigned rather than left to emerge.
One answer is a three-way split:
- The business owns whether the work is valuable
- Agent operations owns whether it’s reliable and improving
- A data science or analytics function owns how drift and quality are measured, so the judgment rests on evidence rather than someone’s hunch.
The practical starting point is a small set of signals that matter, something like drift, hallucination rate and a rough read on value against cost, each with an owner and a review cadence, and the discipline to resist letting the question default to the security tool simply because it is the system already watching the agent.
9. Threat detection and response
Current owner: security.
Finally, an easy one. The catch here is not about ownership, but dependency: a SOC can only detect prompt injection, data exfiltration, tool misuse or an agent exceeding its intended agency if it can see what the agent did, and that evidence comes from task one, five, and six, which security usually does not own. Behavior-time work belongs with security by the first force, yet security is effectively blind here without the telemetry layer operations builds, so the seam runs straight through its own mandate.
The plumbing, at least, is usually already there. Alerts above a set severity flow into the SOC through the SIEM or a ticket queue much like any other detection, and the harder question is what happens when the analyst who picks one up has never heard of the agent involved and has no idea who built it.
What good looks like:
Since ownership is settled, what good looks like here hinges on quality of integrations. Security owns detection and response, and what makes that ownership real is closing two things: the first is the feed from observability: a SOC can only catch prompt injection, data exfiltration or an agent exceeding its agency if the telemetry reaches it, so the detection owner and the telemetry owner have to be wired together deliberately rather than left to find each other during an incident. The second is legibility, which means every alert arriving with what the agent is, what it can reach and who owns it, pulled from the inventory, so the analyst who picks it up is not starting from a name they have never seen.
10. Runtime guardrails and action-level enforcement
🟠 Current owner: unresolved. Usually split three ways, though rarely between the same three teams.
What good looks like:
This is another unsettled one, and on paper the split looks tidy enough: security owns the policy for what must never happen, platform engineering owns the enforcement point where an action is actually blocked, whether a gateway or a hook inside the agent’s framework, and agent operations owns the human-in-the-loop experience of when someone is asked to approve, and how. In practice the parties change from one organization to the next. We’ve seen policy written by second-line risk and enforced by an AI center of excellence, and elsewhere policy owned by an InfoSec risk team while SecOps runs the tooling and handles the exception tickets.
What the more mature teams share is a sense of pace. They roll enforcement out in rings, monitoring first and then guiding people toward safer behavior before anything is blocked, and they pay close attention to whether a human approval means anything at all, because, as one security lead told us, “if human in the loop is just clicking Enter, it’s not really human in the loop.” Reversibility and blast radius still decide how much of the enforcement has to be inline and human-gated rather than reviewed after the fact.
Lifecycle: Keeping the estate clean as agents age, and responding when one goes wrong
11. Recertification, deprovisioning and retirement
🟠 Current owner: unresolved. IT and identity on paper, but in practice nobody yet.
This is joiner-mover-leaver all over again, applied to agents: revoking access an agent no longer needs, and retiring the ones nobody uses before they turn into standing exposure. You might expect this to sit comfortably with IT, and on paper it does, but hardly anyone we spoke to described an actual process for it, and the scale of the problem is striking. One IT services firm estimated that of roughly 800 agents on its Microsoft estate alone, around 90% had been switched on once to see how they worked and never touched again.
Another organization is trying to cut its agent count by around 500 before the end of the year, and the most common retirement mechanism we heard about was asking the person who built an agent to delete it, which stops working the moment that person leaves the company. Agents are created and abandoned far faster than recertification cycles built for human identities were ever meant to run, which is why this one has moved into the column of tasks we won’t pretend are settled.
What good looks like:
Retirement extends joiner-mover-leaver to agents, and on paper it sits with IT and identity, which is the right home. What makes it actually happen is triggering it rather than leaving it to goodwill. Good retirement runs off the inventory: an agent that has not been used in a set window flags on its own, recertification rides the cycles IAM already runs, and decommissioning lands in a named backlog rather than depending on whoever built the agent remembering to delete it, which stops working the day they leave. The teams making headway treat an idle agent as a standing exposure to clear on a schedule, not a tidy-up to reach eventually.
12. Incident response and forensics
Current owner: security.
This runs like any other incident response, with security leading, and agent operations and the business supplying the context that makes an agent incident legible: what the agent was for, and what normal looked like before it went wrong. Legal and privacy join early when data or regulatory exposure is in play, and data sensitivity is what decides how early that is.
Most of the organizations we spoke to are still answering this one hypothetically, which is no bad thing, because the questions they’re asking are the right ones: how to tell a careless agent from a compromised one, and how to stop every agent at once if it ever comes to that, which one security leader wanted as a single switch for the whole estate. The more practiced teams already route by data type, pulling in risk, compliance and legal as soon as personal or payment data is involved.
What good looks like:
Security leads this as it leads any incident, so the real question is what has to be in place before one happens. Two things decide whether an agent incident is manageable. The first is context, with agent operations and the business supplying what the agent was for and what normal looked like, without which an analyst cannot tell a careless agent from a compromised one. The second is a way to stop it, both for a single agent and, if it comes to that, for the whole estate at once, which more than one security leader told us they wanted as a single switch. Route by data type so that risk, compliance and legal are pulled in the moment personal or regulated data is involved, and write the runbook while the question is still hypothetical rather than during the first real incident.
Assurance: Proving to someone else that the estate is under control
13. Audit evidence, compliance and regulatory reporting
Current owner: GRC, privacy and legal.
This one runs on evidence other people already produce: security and agent operations generate it, and GRC, privacy and legal turn it into something an auditor will accept. In regulated firms it often sits with second-line risk, which writes the policy that a first-line AI team then has to evidence, and at least one large European operator now treats every agent as an AI system in its own right under the EU AI Act. Sector and jurisdiction decide how much weight it carries, and increasingly so do customers, since services firms told us their own clients are writing restrictions on AI use into contracts, while in parts of Europe, works councils have a say before any monitoring of employees’ agents goes ahead.
What good looks like:
GRC, privacy and legal own the output, and what good looks like is them consuming evidence the rest of the estate already produces rather than standing up a parallel process to gather it. Security and agent operations generate the record; this task turns it into something an auditor, a regulator or a customer will accept. In regulated sectors that usually means second-line risk writing the policy and a first-line AI team evidencing against it, and increasingly it means treating each agent as an auditable system in its own right. The external demands are widening faster than most roadmaps assume, from the EU AI Act to client contracts to works councils, so the teams that stay ahead wire their audit evidence off the telemetry and inventory they already built and instrument once to report many times, instead of assembling it by hand each time someone asks.
The unsettled tasks, and how to settle them
Intake and approval, tool and server vetting, runtime enforcement and retirement have no clear owner. We expect the market to converge on these over the next 18 to 24 months. The teams furthest ahead today are the ones that wrote down who owns each of these before an incident forced the question. When thinking about your own estate and ownership of unsettled tasks, these factors may be useful to keep in mind:
| Factor | Which way it pulls |
|---|---|
| Config-time vs behavior-time | Declared properties, such as identity, access and lifecycle, sit with IT. Observed properties, such as how an agent behaves when it runs, sit with security or agent operations. |
| Regulatory exposure | A regulated sector adds an attestation step and a named risk owner, pulling contested tasks toward security and GRC. An unregulated one lets them sit with IT, operations or engineering. |
| Where the agent was built | Agents shipped through a deployment pipeline inherit engineering’s ownership for free. Agents assembled in a SaaS tool or adopted in a browser arrive through no pipeline and need another owner. |
| Blast radius and reversibility | Read-only, reversible agents tolerate operations ownership. Agents that take consequential or irreversible actions pull the gate and the enforcement toward security. |
| Data sensitivity | The moment an agent reads or emits regulated or personal data, privacy and data governance become non-optional co-owners, and in parts of Europe so do works councils. |
As with everything we write, we’ll review this every 2-3 months and update as necessary. We hope seeing the responsibilities around agent security and governance laid out like this, as well as some insights from what the world’s most forward-thinking organizations are doing, will help settle some contentious decisions you and your teams are grappling with. If you want to speak to us on any of the above, get in touch.
References
- 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.
- European Union, Regulation (EU) 2024/1689 (the EU AI Act), which sets obligations for high-risk AI systems including logging, human oversight and record-keeping.
- OWASP, Top 10 for LLM Applications, which names excessive agency and prompt injection among the primary risks in agent-based systems.
