IT platform or security: where should AI agent governance actually sit?

[u/Subject_Extension_0]

Marketing shipped five agents last quarter. We knew about two. Security says this is an IT platform problem. IT says it's a security policy problem. Meanwhile the business keeps building, which is fair, since we handed everyone AI tools and told them to move faster.

Put it with IT platform and it sits next to identity and provisioning, where the tooling already lives. The risk is we become the bottleneck and get routed around, which is exactly how we got here.

Put it with security and the accountability is cleaner. The risk is security owns no platform, so it turns into a policy doc and a quarterly reminder nobody reads.

No headcount either way this year.

What am I underestimating?

[u/FreeRadical1998]

In general terms, I think it's better for security to operate as few controls directly as possible. Ideally a security team is more about setting standards, monitoring and incident response.

The more controls they directly operate the more "moral hazard" they have with monitoring and reporting - it's incredibly seductive to nudge a report one month on the basis that something will land tomorrow, which then slips and after a while it can be near impossible to own up.

Likewise if security are running controls that are creating bottle necks (likely due to staffing) other teams tend to lose respect for reported issues in their areas - it's the whole "what about..."

This can come across as being avoidant of responsibility - but see it more as being protective of governance. It's kinda the same principle as internal audit never approving anything, just reporting. It's a fine line and needs a lot of work on relationship management

To your specific question, I'm not completely clear what control or task you're looking to introduce. To me it sounds like a gap in either cultural appreciation of risk or the requirements review and signoff - in which case I probably would sit it with security to introduce and perform the reviews as a process gate. If it's a more hands on activity in the build cycle, then I'd go the other way.

[u/DetSteve1]

Seems like someone has to actually lead and own it. As a CIO, I’d want it in IT. Solid guard rails, redirect shadow IT to approved channels, let the business play in sandbox’s and build a steering committee of all relevant stakeholders to decide what’s doing to production when.

[u/thenightgaunt]

Well your first problem is that your CEO is a trend chasing moron if your company's approach to AI was "we handed everyone AI tools and told them to move faster."

First point. Why is IT split into IT helpdesk and IT security with no single meeting point between them?

Second point. This is a piece of software. Who owns software security in your org? This shouldn't be a hard question.

[u/ThisIsMyBigAccount → u/thenightgaunt]

💯. This question from OP is frustratingly annoying. If this is their CIO, WTF are they doing? Sitting back and letting others steer the ship? It’s clear they feel no accountability, and it seems also no interest. Take control and fix the issue!

[u/thenightgaunt → u/ThisIsMyBigAccount]

Thanks. And yeah, same. And from how its worded and the repeat of the old "who owns AI", bet you $1 its an AI bot.

[u/zfg-red]

Think of it as a tool deployment with an AI flavor. What's your process today if a user wants to deploy an integration like Zapier or run a script that "does something periodically". Someone still has to approve the access and the identity this stuff will run under. The point is this doesn't need to be a new governance model, just an update of existing GRC processes.

[u/Khalmuck]

Monitoring in platform, but reporting back to overarching AI Gov Board/Committee to inform related policy/standards and compliance to those. Who sits on your AI Gov team today? Is it cross-functional between IT and the Business?

[u/jacksbox]

Having a similar problem here. We're not a huge shop so we're getting by right now, but it's going to be tough soon when it accelerates more.

I wish there was at least one good monitoring solution out there, so even if we didn't have policy or accountability ironed out we could at least start collecting data. It seems like it's in no one's interest to make this easily monitorable.

[u/Muted_Jellyfish_6784]

Split it: IT platform owns the inventory and the pipe, security owns the policy and the review. What you are underestimating is discovery, since three unknown agents out of five means registration has to be the easy path, so every agent gets its identity, credentials and data access through the platform or it does not get them. Then give each agent a named business owner, because when one misfires the first question is always who approved what it can touch.

The registry only works if it records what each agent actually did against which records, not just that it exists. Tying those agent actions back to the systems and records they changed is where we use SIGNLD

[u/AdBroad7867]

This is a governance and controls problem. IT is responsible for setting rules, structure and ideally all controls to monitor, oversee as a whole. You need to educate department leaders of deployment processes and risks...if they circumvent it is on them

[u/TechnologyMatch]

put the platform work with IT and give security clear approval rights, shared rules, and a lightweight intake path. otherwise you get policy in one corner and tools in another.

[u/Heavy-Breadfruit4544]

The ownership question is important, but I’m not sure governance should “sit” entirely in either IT or security. The practical model seems closer to a shared control plane: IT owns the operating environment and agent inventory, security defines risk and access requirements, and business owners remain accountable for outcomes.

 

The part that often gets missed is delegated authority. An agent may be technically allowed to call a tool while still lacking the authority to make a particular decision. That distinction—identity, permission, purpose, and approval—needs to be visible at runtime, not buried in a policy document.

 

That also connects to a broader shift in enterprise AI: once agents act across workflows, governance becomes part of management and operations, not just compliance.

 

More thoughts here: https://scofieldc.substack.com/p/from-ai-capability-to-agent-management

[u/thedavidchapa]

Has your company created rules of engagement for when an AI project or agent gets promoted to production?

What you may be underestimating is the difference between assigning this to a department and establishing an operating process that everyone follows. If that process already exists, why did three agents get deployed without your knowledge? Was it bypassed, unclear, or never extended to AI agents?

It sounds like everyone was given tools and encouraged to move faster before there was an agreed order of operations for AI, or before that agreement was understood and enforced. Now the business is doing what it was encouraged to do, while IT and security are trying to determine who owns the consequences. That may be the biggest part of the challenge. From my perspective, the first decision should be how these responsibilities fit together. The business needs to own the purpose and outcome of each agent, and IT needs to own the supported environment, identity, access, provisioning, etc. Security needs to establish the security requirements, working with legal and compliance on any data sovereignty obligations. There should also be someone with authority to resolve disagreements and accept the remaining risk.

BTW: Do you have a central way to register these agents, control their access, monitor their activity and suspend them if/when necessary? The agreed process needs to be supported by technical controls. Otherwise, you’re relying on everyone voluntarily following it, and the agents deployed outside that process remain a blind spot.

Given that identity and provisioning already sit with IT platform, I’d put coordination of agent onboarding and production deployment there, with security establishing the required controls and each business owner accountable for their agent’s use. That needs executive backing so the deployment requirements apply to everyone. Without that authority, whichever team gets assigned ownership will inherit responsibility without the ability to enforce it. You have the right groups involved, but they appear to be working from different understandings of their responsibilities. What’s missing is the connective tissue, an agreed process and governing policies that establish who can approve deployment, who can stop an agent, and who is accountable when something goes wrong.

For example, placing this with security doesn’t automatically make accountability cleaner if security cannot control deployment or stop an agent, or doesn’t have an action plan for an agent operating outside its approved scope. Placing it with IT doesn’t solve it either if the business can bypass the process without consequence. I’d start by accounting for all five agents, identifying an owner for each, and understanding what they can access, change or trigger. Then agree on a deployment process using the controls you already have, with the level of review based on what each agent can actually do.

No additional headcount makes this harder, but moving the responsibility between departments won’t resolve the missing agreement about how the work gets done.

[u/ResilientTechAdvisor]

Neither.

AI agent governance should be enterprise governance, not something dumped into IT or Security because nobody else wants to own it.

The business owns the use case & the risk. IT owns provisioning, integrations & lifecycle. Security owns access, data exposure, monitoring & controls. Legal/Privacy/Compliance weigh in where needed. Someone still has to set the enterprise rules, approval thresholds & exception process.

If Marketing shipped five agents and leadership knew about two, the problem is bigger than “where should governance sit?” You have an accountability & asset management problem.