Access Policy Enforcement for AI Tools Across Business Units

Enterprise AI spending hit $37 billion in 2025, up from $11.5 billion the year before. Tools show up in every department faster than any central team could track by hand, and 88% of organizations now use AI in at least one business function, according to McKinsey's State of AI 2025 survey. That's the baseline, and the baseline has a hole in it: 96% of enterprises already run AI agents in some capacity, per an OutSystems survey of 1,900 global IT leaders conducted December 2025 through January 2026, and 94% of those leaders call AI sprawl an active concern. Only 12% have built anything centralized to manage it. I've sat in enough of these planning meetings to know that gap isn't a rounding error; it's the whole ballgame.

Adoption itself has scaled cleanly. The absence of any infrastructure to control access while it scales is what turns a productivity story into a liability story, and right now, most companies are flying that plane without instruments.

What shadow AI looks like when it crosses business unit boundaries

Eight in ten employees use AI tools their employer never approved, and only 37% of enterprises have any AI governance policy at all. Do the arithmetic and you land somewhere uncomfortable: this is a Tuesday, not a future risk.

Picture something unremarkable. An analyst pastes a customer list into a chatbot on her personal account during lunch, because the sanctioned tool would've taken three weeks to provision and this one took three minutes. LayerX's 2025 Enterprise AI and SaaS Data Security report found 77% of workers paste sensitive data into generative AI tools this way, mostly from personal accounts sitting entirely outside company visibility. LayerX's 2025 Browser Security Report takes it further: generative AI is now the single largest channel moving data from corporate systems to personal ones, ahead of personal email, ahead of personal cloud storage. It even beat out email, and email used to be the thing that kept IT security teams up at night.

Cross department boundaries and it gets messier. An HR employee's AI assistant might hit the same internal API that a developer's coding agent uses, but without a shared policy layer, their permissions and audit trails never talk to each other. One team's shortcut becomes another team's blind spot, and nobody finds out until something breaks.

Employees aren't going rogue here. Governance that only knows how to say no produces exactly this pattern. Say no often enough without offering a fast yes, and the behavior doesn't disappear; it just moves somewhere you can't see it. Regulators have started noticing too: global fines tied to AI misuse hit roughly $2.1 billion in 2025, about seven times what they were in 2023. The bill for looking away is arriving, and it's arriving with interest.

Why role-based permissions tied to existing identity infrastructure are the practical starting point

Policy belongs at the identity level, not the tool level, because tools turn over every few months while identity doesn't. Pin your rules to a specific app and you'll be rewriting them by next quarter's product release. Pin them to who someone is and what role they hold, and the policy outlives the tool that triggered it.

That's the case for role-based access control tied to Okta, Entra ID, or a standard SAML/OIDC setup: AI access inherits from the same source of truth already governing VPN logins, SaaS accounts, and internal APIs. Nobody builds a second system and prays it stays in sync with the first, because it never does.

Take an HR manager in Munich and a sales engineer in Singapore, both opening the same AI assistant. Their permissions shouldn't match just because they clicked the same icon. Data residency rules differ, compliance postures differ by business unit, and a uniform policy set by whoever happened to deploy the tool ignores all of that. NIST's AI Risk Management Framework breaks governance into four functions: govern, map, measure, manage. You can't map or measure access you can't attribute to a specific identity, and put plainly, you can't govern what you can't trace back to a person.

Agent identity is the trickier piece, and it's the one most teams haven't thought through yet. When an AI agent makes an autonomous API call on someone's behalf, it needs a verifiable identity of its own, distinct from a shared service credential that five other agents also use. Share that credential across five agents and the audit trail collapses exactly where human and machine access meet, which is the one spot you actually need it to hold. Agentic systems produce behaviors that older, static governance models never anticipated, and setting limits on that autonomy starts with knowing, precisely, which agent acted on whose authority.

This work extends the identity system already running, using existing groups, roles, and entitlements as the foundation for AI permissions rather than bolting on something separate that drifts out of sync within a year.

How a centralized governance layer enforces consistent policy without creating a bottleneck

If every AI request needs a human security reviewer, governance becomes the reason people stop asking for permission in the first place. That's the honest version of the bottleneck complaint, and it's a fair one. Automation, not more reviewers, is the fix.

A centralized governance layer should work like an API gateway: write the policy once, enforce it automatically on every request, and stay invisible to anyone whose access was already fine. A handful of things make that hold up in practice. Role-based decisions get made at request time, not in a ticket queue that sits for a week, and tool visibility narrows automatically by role, so agents and users only ever see what they're cleared for, which shrinks the attack surface without anyone needing to remember to lock a door. Real-time PII detection and prompt injection defense sit inside the request path itself, not in a report someone skims on Friday afternoon. Shadow AI detection routes unsanctioned tool use into an approval workflow rather than just throwing a wall in front of it.

Deloitte's 2026 State of AI in the Enterprise report found employee access to AI grew 50% in 2025, yet only one in five companies has a mature governance model for autonomous agents. Access outran control, and by a wide margin; that gap doesn't close on its own, no matter how long you wait for it to.

The pitch to platform and security teams should be blunt: centralized governance is what lets every business unit move fast without each one carrying a different risk profile. Human judgment still matters here. A working governance structure still needs an executive sponsor, a governance lead who actually owns the policy, data stewards, legal and compliance reps, and a risk owner sitting inside each business unit. The technology enforces what that group decides, and the decisions stay theirs.

What MCP servers add to the access policy problem and why gateways are the answer

Anthropic released the Model Context Protocol in November 2024. By December 2025 it had racked up 97 million monthly SDK downloads, making it the closest thing this industry has to a standard for connecting AI agents to tools and data.

Here's the catch nobody mentions in the launch blog posts: MCP doesn't handle authentication, authorization, or audit logging on its own, and an agent connecting straight to an MCP server, no gateway in front of it, is an ungoverned access event the moment it fires. Connect agents directly to dozens of these servers across an enterprise and you get fragmented security, duplicated integration work, and no unified view of what's actually being called or by whom. MCP also doesn't track token consumption or cap usage, so at real scale this stops being just a security question. It becomes a budget question too, and finance teams notice budget questions fast.

The fix is the same pattern that solved this exact problem for REST APIs a decade ago: put one governed gateway in front of the servers. It authenticates the agent, routes the request, filters which tools are even visible based on role, logs every interaction, and enforces rate limits and spend caps. Gartner's guidance on emerging AI practices recommends treating MCP servers exactly like production APIs, with the same gateway-first architecture teams already use for everything else they've built.

Applied across business units, this solves the cross-team problem directly. Agents in different departments see different tool inventories based on role. A sensitive tool doesn't get blocked for someone who lacks permission so much as it never shows up in their context at all, which is a cleaner outcome than a rejection message. Every invocation logs the requester's identity, building an audit trail that spans the whole organization instead of stopping dead at department lines. Tie it to Okta or Entra ID through SSO, and MCP access rides on the same identity rails as everything else already does.

How to evaluate MCP gateway options for enterprise access policy enforcement

The best gateway is the one whose access model matches how your enterprise already handles identity, and whose logs show your security team what they actually need. A long feature list on the sales deck matters far less.

A few questions cut through the noise fast. Does it plug into your existing Okta, Entra ID, or SAML/OIDC setup without forcing a second identity system alongside the first? Can permissions be set at the level of an individual tool rather than just the server, so "can use the calendar tool but not the payroll tool" is something you can actually write down and enforce? Does every agent call generate a log entry with identity, tool, input, and output attached, or just a vague summary that won't hold up to an auditor's questions? Does it catch prompt injection and PII exposure in the request path, in real time, rather than after the fact in some weekly report? Can a finance lead see exactly what her team is spending in tokens against a budget she set herself? And does it fit the Kubernetes, cloud, or on-prem setup already running in your shop, instead of demanding you build a new one from scratch?

A few named options show the range. Speakeasy positions itself as an enterprise AI control plane built for this exact cross-unit problem: one governed layer connecting agents and MCP servers to internal and external systems, RBAC tied to Okta and Entra ID, real-time prompt injection detection and PII blocking, shadow AI detection, and cost telemetry across the org, aimed at letting companies open AI access to every employee on day one without a security review for each request. Microsoft's MCP Gateway is open source, works as a reverse proxy and lifecycle manager for MCP servers running on Kubernetes, and uses MSAL and Entra ID in cloud mode so filtering follows the signed-in user's entitlements; it fits Microsoft shops well, but takes real engineering time to get running at scale. Kong AI Gateway governs LLM, MCP, and agent-to-agent traffic on one control plane, with OAuth 2.1, MCP tool access lists, and observability built in, which makes sense if Kong already runs your API layer. Lasso leans security-first, with reputation scoring for MCP servers and real-time threat detection aimed squarely at prompt injection and PII leaks. TrueFoundry, named a Representative Vendor in Gartner's 2025 Market Guide for AI Gateways, combines MCP governance with LLM routing in one place.

There's no single right answer here, and anyone who tells you otherwise is selling something. Start with identity integration and audit requirements. Those are the two things genuinely painful to bolt on after the fact.

What a phased rollout of AI access policy actually looks like across business units

Start by finding out what's already running, because you can't govern ghosts. Shadow AI detection comes first, not last: writing policy for tools you don't know exist is a wasted afternoon, so map usage across every business unit before drawing a single access tier.

Second, wire it to identity infrastructure you already have. Extend Okta, Entra ID, or your existing directory groups to define AI roles, and resist the urge to build a parallel identity model for AI; it will drift from the one governing everything else, and drift is exactly what you're trying to prevent.

Third, write policy at the tool and data level, not the category level. "Finance can use the CRM connector but not the HR records connector" is the right granularity. Broad allow or deny lists just create gaps someone eventually finds, usually the hard way.

Fourth, turn on the gateway and enforce in the request path itself, live, not on a quarterly audit cycle. This is the stage where tool-level RBAC, PII filtering, and logging stop being policy documents nobody reads and become running code.

Fifth, hand observability to business unit leads, not just the security team. When a department head can see her own team's usage, spend, and anomalies, she becomes part of the enforcement layer instead of the source of the next demand for a shadow tool.

None of this works if the governance structure isn't in place before the platform goes live: executive sponsor, governance lead, risk owners in each unit. The platform executes decisions; people still make them. Gartner projects more than 40% of agentic AI projects get canceled by the end of 2027, thanks to runaway costs, unclear payoff, and weak risk controls. A phased rollout protects the AI investment a business unit has already made, extending it rather than threatening it. The argument that lands with unit leads is simple: governance is what lets you deploy AI to every team quickly. Skip it, and every new tool needs its own security review, which is what actually slows things down.

Compliance requirements that make centralized AI access policy non-optional

The EU AI Act is already here, not a future concern to plan around eventually. Bans on prohibited AI practices took effect in February 2025, obligations for general-purpose AI models started in August 2025, and the remaining high-risk and transparency requirements land in August 2026. Organizations without access policy infrastructure today are already inside the compliance window, whether they've noticed or not.

The penalties make the math easy: violations tied to prohibited practices carry fines up to €35 million or 7% of global annual turnover under Article 99. Put that figure next to the cost of a gateway deployment and this stops being a debate worth having.

NIST's AI RMF gives the operational shape here. Govern, map, measure, manage translates directly into what a centralized access layer actually produces: attributable decisions, measurable usage, manageable risk. In financial services, SR 11-7's requirements around independent validation, documented governance, and clear accountability across the model lifecycle extend naturally to AI systems, and most governance programs at regulated banks build on that baseline rather than inventing a new one from scratch.

This isn't purely about dodging fines. Audit logs, role-based access records, and usage data are exactly what an examiner asks for during a review. Companies with a centralized governance layer already have those records sitting ready to hand over. Companies without one spend weeks reconstructing them after the fact, assuming reconstruction is even possible by then.

The cross-unit piece matters because that's precisely what regulators check for. Governing AI well in one division while ignoring the rest satisfies nobody. Both the AI Act and the NIST framework assume accountability runs across the whole organization rather than stopping at department lines. The real choice was never whether to govern AI. It's whether you build that governance now, on your own schedule, or rebuild it later, on a regulator's.