Should IT Own Your AI Tools?

Your organization is deploying AI agents faster than you can track them. The decision isn't whether to govern these tools, but how to establish oversight before risks turn into incidents.

Recent analysis of enterprise telemetry found that 80% of AI tools operate without IT oversight. Vulnerabilities affecting agents and LLM tools have surged from fewer than five monthly disclosures in 2023-2024 to about 29 per month since January 2025. The question isn't academic anymore: who controls AI deployment in your organization?

The Decision You're Facing

You need to choose between three governance models for AI tools:

1. Centralized IT control, all AI tools require formal approval and provisioning.
2. Federated oversight, business units deploy tools within guardrails set by IT and risk.
3. Reactive monitoring, track what's deployed and intervene when risk thresholds are breached.

Each path creates different risk exposures and operational constraints. Your choice depends on four factors that determine which model fits your organization's risk appetite and operational reality.

Key Factors That Affect Your Choice

Current AI tool proliferation rate
If you're seeing rapid, uncontrolled adoption (consider organizations where SMBs average 414 unsanctioned tools per 1,000 employees), you're already behind the deployment curve. Centralized control becomes harder to enforce retroactively.

Technical capabilities of deployed agents
Analysis of 500 Model Context Protocol servers revealed that half can execute shell commands directly, more than 80% can read or write local files, and roughly 75% can make outbound network calls. Nearly two-thirds combine command execution, file access, and network egress in a single package. If your agents possess these capabilities, the attack surface expands dramatically.

Patch management capacity
Tracking of 637 vulnerabilities across agents and LLM tools found that 525 were disclosed in the past 18 months, including at least 111 rated critical with CVSS scores of 9.0 or higher. If your security team struggles to patch traditional software within your defined SLA windows, adding AI tools to that queue compounds the problem.

Business velocity requirements
Some units need to experiment with AI tools to maintain competitive positioning. Locking down every deployment creates friction that drives shadow IT deeper underground.

Path A: Centralized IT Control

Choose this path if:

• You operate in a highly regulated sector (financial services, healthcare, critical infrastructure) where unauthorized data access creates material compliance risk.
• Your organization has fewer than 2,000 employees and IT can realistically review every tool request within 48-72 hours.
• You've already experienced a data breach or audit finding related to unsanctioned SaaS applications.
• Your Cyber Risk Appetite statement explicitly prohibits tools that execute system commands or access production data without formal review.

Implementation steps:

1. Inventory existing AI tools through network traffic analysis, OAuth grant reviews, and endpoint detection logs.
2. Establish a lightweight approval workflow tied to your existing software procurement process.
3. Define technical requirements: authentication standards, data access boundaries, logging requirements.
4. Create an approved tools catalog with deployment templates that satisfy your baseline controls.

The trade-off:
You'll slow deployment velocity. Business units will complain. Some will route around you through personal accounts or consumer-grade tools. You need executive sponsorship to enforce this model, and you need to prove you can approve legitimate requests within days, not weeks.

Path B: Federated Oversight

Choose this path if:

• Your organization exceeds 2,000 employees and centralized review creates bottlenecks.
• Business units have mature risk management practices and dedicated IT resources.
• You can define clear guardrails that business units can apply without consulting central IT for every decision.
• Your priority is visibility over pre-approval.

Implementation framework:

1. Define prohibited capabilities: tools that execute shell commands, access sensitive data repositories, or lack authentication mechanisms should trigger mandatory IT review.
2. Establish technical guardrails: require SSO integration, enforce network segmentation for agent traffic, mandate audit logging.
3. Create a risk classification scheme: low-risk tools (no data access, no command execution) get streamlined approval; medium-risk tools require risk assessment; high-risk tools follow Path A.
4. Deploy monitoring to detect tools that violate guardrails, focus on OAuth grants, API calls to external AI services, and agents with file system access.

The trade-off:
You're trusting business units to make sound risk decisions. You'll discover violations after deployment, not before. Your Cybersecurity Risk Register needs to reflect residual risk from undetected tools, and your incident response structure must account for AI-related events.

Path C: Reactive Monitoring

Choose this path only if:

• You lack the resources or executive support to enforce Paths A or B.
• Your organization treats AI tools as experimental and hasn't integrated them into critical business processes.
• You're building the business case for formal governance and need data on actual deployment patterns.

Minimum viable controls:

1. Deploy discovery tools to identify AI agents through network traffic patterns, OAuth integrations, and endpoint telemetry.
2. Tag high-risk deployments: agents with command execution, file access, and network egress combined.
3. Create an escalation path when monitoring detects critical vulnerabilities, the 111 vulnerabilities with CVSS scores of 9.0 or higher disclosed in the past 18 months won't wait for your quarterly review cycle.
4. Document every identified tool in your Risk Management Information System with severity level and remediation timeline.

The reality:
This isn't governance; it's damage control. You're accepting that 80% of AI tools will operate without oversight until something breaks. Your audit findings will reflect this gap. Use this model only as a temporary state while you build toward Path A or B.

Summary Matrix

Factor	Path A: Centralized	Path B: Federated	Path C: Reactive
Approval required	Yes, before deployment	Only for high-risk tools	No
Business velocity	Slower	Moderate	Fast
IT resource load	High upfront, lower ongoing	Moderate throughout	Low upfront, high when incidents occur
Risk exposure	Lowest	Medium	Highest
Best for	Regulated industries, <2K employees	Large enterprises with mature risk culture	Temporary gap state only
Executive support needed	Critical	Moderate	Minimal

The 525 vulnerabilities disclosed in the past 18 months won't distinguish between your governance model. What matters is whether you can detect, assess, and remediate critical findings before they're weaponized. Choose the path you can actually execute, not the one that looks best in your GRC platform.

Your AI tools are already deployed. The question is whether you'll govern them before they govern your risk profile.