Access Policy Enforcement for AI Tools Across Business Units

The policy documents exist. The trouble was never a shortage of policy; it was written for a world where AI tools lived inside a browser tab, and the tools have since moved into CRMs, codebases, calendars, and every API an employee can reach. Enforcement has not followed the tools to where they now live.

The clearest evidence of that mismatch is the ownership gap. Only a small minority of AI governance measures across enterprises have an explicit, named owner, and that phantom ownership is the single biggest implementation risk in the field. CISO, Legal, Compliance, HR, and the business units each hold a fragment of the problem, and a policy with five partial owners functions as a policy with none. When a sales engineer connects an AI assistant to a CRM, Legal assumes IT approved it, IT assumes the business unit vetted it, and the business unit assumes the AI assistant came pre-governed because it was purchased through procurement. Everyone is correct about their own piece and wrong about the whole.

Business units are what turns a governance gap into a governance crisis. Engineering teams build automated workflows against CRMs, finance teams run AI projections, and legal teams use it to draft client communications. Each of those units has a different data sensitivity profile, a different regulatory exposure, and a different appetite for risk, and none of them sit under a shared enforcement layer that treats "AI access" as a single governable category. A policy calibrated for marketing's risk tolerance is either dangerously loose for legal or suffocating for engineering. Multiply that by every business unit in a mid-size enterprise and the result is not one governance problem.

Legacy IAM and DLP tools miss AI activity across business units

The instinct to point existing security infrastructure at this new problem is understandable and wrong. Legacy IAM, DLP, and CASB systems were built to govern structured access requests and data in motion, and they carry a structural blind spot for AI-specific risk that no configuration change can patch. They were never designed to parse conversational intent or reach the places AI tools now operate. The gap is architectural.

Security teams running shadow AI audits are discovering that visibility now requires five separate layers, network, browser, endpoint, code, and SaaS, and a tool built for only one of them misses a significant share of what is actually happening. Most audits that come back clean simply ran one layer and called it coverage, which is precisely the visibility gap that Speakeasy, an enterprise AI control plane for securing and governing AI agents and MCP servers across an organization's teams, is designed to close. The layer organizations miss most consistently is embedded LLM API calls buried inside production code. Repello's 2026 enterprise audits found that a substantial share of audited codebases contain undocumented LLM API call paths that network-based monitoring tools cannot see, because those calls ride on sanctioned credentials and legitimate network egress. Only static code analysis surfaces them. An organization confident in its network monitoring may be sitting on calls to external models it has never inventoried.

DLP tools fail for a related but distinct reason. They are built to classify structured data as it moves, a spreadsheet leaving through email, a file uploaded to an unsanctioned cloud drive. They have no mechanism for classifying a prompt that instructs an agent to summarize every customer contract sitting in a connected SharePoint folder, because the risk in that scenario lives in the instruction rather than in any file that physically moves. Nothing crosses a monitored boundary in a way DLP recognizes. The agent reads, synthesizes, and responds, and the exposure happens entirely inside a step the tool was never built to inspect.

The agentic layer deepens the problem further. An unauthorized agent holding persistent OAuth access to a company's CRM, email platform, and calendar is an autonomous system operating continuously inside business-critical infrastructure, making decisions and taking actions on a schedule no human is watching in real time. That is a fundamentally different risk category than the one DLP and CASB tools were built around, and treating it as a data-loss event rather than an infrastructure event is how it goes unnoticed for months. MCP servers add one more layer to this mismatch, and the detail matters enough to earn its own treatment later in this piece, but the short version is that engineering teams are standing up MCP servers to expose internal databases and APIs to agents without security review, and the protocol itself does not enforce authentication or capability scoping unless someone configures it to. Existing network monitoring tools have no vocabulary for what that traffic even is.

What identity-bound, role-based AI access policy means in practice

The fix is the extension of the identity-bound, role-based model enterprises already run through their IAM infrastructure to cover AI agents, the skills they invoke, and the tools they call, treating each as a governed resource with the same rigor applied to a human employee's access to a financial system.

Enterprise IAM already runs on this principle: a user's access should derive from a verified identity and an assigned role, scoped to the business unit and function that person belongs to, and checked at the moment of request rather than assumed in advance. Applying that principle to AI tools is not a conceptual leap. It requires the same discipline: no self-reported scope, no advisory guideline an employee can route around, and no assumption that a tool is safe because someone in IT remembers approving it eighteen months ago.

The hardest design challenge inside this framework is that giving an AI agent its own identity and scoping it independently lets an intern act through that agent to route around their own restricted permissions. But if the agent instead inherits the full access of whichever human invoked it, one successful prompt injection can cascade through every system that human could touch. Neither extreme works. The resolution is an evaluation, for each action at runtime, of the intersection between what the agent is permitted to do and what the requesting user is permitted to do, executing only the overlap. Liminal's 2026 governance guide places access management alongside data loss prevention and audit logging as one of the technical controls inside a six-component governance framework, because policy documents only state the rule, and enforced technical controls are what make the rule real.

Risk-based classification has to run alongside that model because not every AI use case deserves the same scrutiny. An assistant answering general HR questions about vacation policy carries a different risk profile than an agent with write access to a financial system, and that in turn differs from a code agent operating against production infrastructure. Permissions have to scale with what's actually at stake in the use case, not with a flat, organization-wide default. This holds together only when accountability sits at its center. Every AI system needs a specific individual or committee named as responsible for its access policy; a cross-functional aspiration is not enough. Accountability is the structural prerequisite that makes enforcement possible.

Treating AI agents as first-class identities in enterprise IAM

The architectural answer to the two-identity problem is to stop treating AI agents as credentials borrowed from a human account and start treating them as identities in their own right. An agent operating under a shared service account or an inherited login cannot be audited independently, cannot be scoped independently, and cannot be revoked without also cutting off whatever human or system shares that credential. Giving the agent its own identity solves all three problems at once.

Okta for AI Agents is the clearest evidence that this is no longer a theoretical architecture. It went generally available on April 30, 2026, and its approach scopes the tools exposed to an agent before the underlying model ever executes a request, filtering out any MCP tool the delegating user was not authorized to use in the first place. An agent built on that architecture cannot reach a database or an API outside its explicit, pre-filtered scope, because the filtering happens upstream of execution rather than as an after-the-fact check. Microsoft has taken a related but distinct path with Entra Agent ID: it gives AI agents their own identities inside Entra ID, while Microsoft Purview applies data security and compliance controls across those AI apps, so identity and data protection stay separate concerns instead of being enforced at the point a request is made.

Model providers are building the same logic in from the other direction. Anthropic's Workload Identity Federation, generally available since June 17, 2026, lets a workload authenticate to the Claude API using short-lived OIDC tokens issued by an identity provider the organization already runs, AWS IAM, Google Cloud, Kubernetes service accounts, Microsoft Entra ID, Okta, or any standards-compliant OIDC issuer. Those tokens get exchanged for short-lived Anthropic access tokens, so each workload ends up with its own identity, its own role, and its own audit trail instead of every service sharing one static API key that nobody remembers the full blast radius of. A static shared key is a single point of failure dressed up as a convenience. Per-agent identity is what makes per-agent policy possible in the first place: once an agent has a distinct identity, a security team can assign it a role, scope its tool access to that role, bind its effective permissions to the access tier of whoever delegated the task, and revoke that one agent without touching anything else connected to the same system.

Structuring role-based AI access across business units with different risk profiles

Identity solves who an agent is. It does not solve what that agent, or the human it serves, should be allowed to do inside a given business unit, and that is a design problem that resists a single company-wide template. A legal department handling privileged client communications, an engineering team with direct access to production infrastructure, and a marketing team running campaign automation cannot be governed by one uniform permission model, because it will either over-restrict the low-risk unit or under-restrict the high-risk one.

The starting point has to be an inventory. Everythingcloud's governance framework treats a risk-classified AI system registry as the second pillar of governance, requiring every model or tool in active use to carry an entry listing its owner, its purpose, its data inputs, and its assigned risk tier, on the straightforward logic that permissions cannot be assigned to a system the organization does not know it is running. From that registry, a three-tier structure gives security and platform teams a workable scaffold. Low-risk tools, general productivity assistants with no connection to internal systems, can be rolled out broadly with light scoping, governed mainly through an acceptable-use policy and standard audit logging; getting this tier wrong mostly costs an organization visibility, not an active breach, but it is still where shadow AI usage tends to start and spread. Medium-risk tools, agents with read access to business data, customer records, or internal APIs, need role-scoped credentials tied directly to the user's function and business unit, with tool-level filtering so an agent can only invoke the subset of capabilities relevant to that specific role; get the scoping wrong here and a read-only HR assistant ends up with visibility into compensation data it was never meant to touch. High-risk tools, agents with write access to financial systems, production infrastructure, or regulated data, require per-action authorization, a human in the loop for anything irreversible, and audit trails built to satisfy a regulator rather than just an internal review; misjudge this tier and the agent is not leaking data anymore, it is executing financial transactions or infrastructure changes nobody signed off on.

Cross-unit workflows are where this scaffolding gets tested hardest. An agentic workflow that spans a finance agent, a CRM integration, and an HR data pull has to run on the intersection of what each of those roles is separately permitted to do, never the union, which would grant each unit's agent the combined access of all units it touches. Grant the union by default and every agent touching multiple systems inherits the combined privileges of every business unit it crosses, which turns the agent into the most over-privileged identity in the company by accident rather than by design. Liminal's 2026 governance guide treats this risk-based calibration as a core principle precisely because the two failure modes sit on opposite sides of the same mistake: uniform controls set too high drive employees toward unsanctioned shadow tools, and uniform controls set too low leave the organization exposed at exactly the business units that can least afford it. Each risk tier needs a named accountable party: a business unit lead owns the registry entry, an IT or security owner owns the enforcement policy itself, and a compliance owner owns the resulting audit trail, distributed clearly enough that enforcement does not fall into the gap between functions, giving the fragmented ownership described earlier in this piece a named owner at each tier.

Governing MCP servers and agentic workflows at the infrastructure layer

All of the role design in the world does not help if the infrastructure routing an agent's tool calls has no enforcement point built into it, and that is exactly the condition most organizations are running MCP under today. The protocol does not enforce authentication or capability scoping on its own, and engineering teams have been standing up MCP servers to expose internal databases, file systems, and APIs to agents without routing that decision through security review first.

Model Context Protocol crossed 10,000 active public servers in March 2026, and it now runs in production at a large majority of enterprise AI teams, with most of those deployments standing up outside of any governed distribution layer. That is tens of thousands of potential entry points into internal systems, provisioned the way shadow IT always gets provisioned: quickly, locally, and without anyone outside the team that needed it that afternoon knowing it exists.

The specification itself has started closing part of that gap. The June 2026 Enterprise-Managed Authorization extension formalizes enterprise identity providers as the authoritative source for MCP server access, so a user authenticates once through the identity provider the organization already runs, and that provider automatically provisions the specific MCP servers that user is authorized to reach. It is the spec-level version of the registry-and-ownership model described in the previous section, built directly into the protocol rather than bolted on as organizational policy. A specification update does not enforce itself at the infrastructure layer; an enterprise MCP gateway is the actual enforcement mechanism. A gateway sits between AI agents and the MCP servers they call, and it functions as the enforcement point for every tool invocation that passes through it, the same architectural role an API gateway has long played for REST APIs.

Several platforms are already filling that role in production deployments as of 2026, evaluated by the security and platform teams responsible for deploying them. TrueFoundry supports containerized MCP server deployment with authentication, access control, guardrails, fallback mechanisms, load balancing, and rate limiting managed from a single interface, and reports roughly 3 to 4 milliseconds of latency at high request throughput per vCPU. Lunar.dev's MCPX is built specifically for multi-tenant enterprise governance: a team can access the same underlying MCP server as another team while seeing a completely different subset of available tools, and that per-team tool filtering prevents over-privileged agents directly at the infrastructure layer. Cloudflare has entered the same space with MCP Server Portals. The specific vendor an organization chooses matters less than the architectural decision it represents: every tool call an agent makes should pass through a point that can say no, and an organization without that point is one unreviewed MCP server away from finding out the hard way.