The AI Governance Gap
Your security stack controls who can access your SaaS tools. It has no idea your AI agents even exist.
The assumption that broke
Modern identity infrastructure is genuinely impressive. SAML, OIDC, SCIM, MFA, JIT provisioning. Enterprise IT has spent two decades building a system that knows who every employee is, what they should access, and when to cut them off.
That system has one core assumption: access requests come from people.
An employee authenticates via SSO. Your IdP issues a token scoped to their groups and roles. When they leave, SCIM deprovisions them automatically. When their role changes, group memberships update. The whole system is predicated on identity. Because it is, it works.
That assumption quietly broke over the last two years. And most organizations haven't caught up yet.
How agents get access today
AI agents like Claude, ChatGPT, Copilot, and Gemini are now doing real work inside real organizations. Not just answering questions, but reading pipelines, writing emails, querying databases, and taking actions that have consequences.
To do that work, they need access to your SaaS tools. And the way they get that access today is simple: someone generates an API key, pastes it into the agent's configuration, and the agent starts calling APIs.
That's it. No SSO. No group membership. No session token tied to an identity. A raw credential that grants access to whatever that key's scope allows, typically whatever the developer who generated it was allowed to do.
Three gaps that current tooling doesn't close
read_deals, but write_deals, delete_contacts, export_all. There is no "least privilege" applied to agents by default. In practice, agents run overpermissioned, not by design but because tight scopes are friction and business value is the priority.Compare this to how a human analyst does the same work:
The regulatory angle is closer than it looks
The EU AI Act came into full effect in 2025. Its requirements for high-risk AI systems include human oversight measures (Article 14) and automatic logging of events (Article 12). The scope of what counts as "high-risk" is broader than most legal teams expect, and enforcement is ramping up.
Meanwhile, SOC2 auditors are starting to ask pointed questions about AI governance. The typical answer is a vague policy document plus good intentions. It is increasingly insufficient. Type II reports are supposed to demonstrate operating effectiveness over time. You can't demonstrate that for controls that don't exist.
GDPR's data minimization principle (Article 5) is also relevant. If your agent reads 10,000 customer records to answer a question about one deal, that's a data minimization problem. Current agent architectures make it easy to accidentally over-retrieve, with no mechanism to constrain access at the level of individual tool calls.
What governance for agents actually looks like
The good news: we know how to solve this in principle, because we've already solved it for humans.
The right mental model is simple. Agents should be first-class identities in your access control system. Not service accounts. Not API keys. Identities with:
- A registered agent ID tied to a definition: what is this agent, who built it, what is it supposed to do
- A role using the same RBAC framework you already use for people: "sales-analyst" reads deals but can't write; "hr-ops" accesses employee data; "finance-viewer" is read-only everywhere
- A policy set governing which tool calls are allowed, with what parameters, at what rate
- An immutable audit log capturing every tool call with full context: agent ID, tool called, parameters, response, and outcome
- A kill switch that suspends an agent globally, across every tool it touches, in seconds, without revoking underlying credentials
What that audit log looks like in practice:
The DENY on line 2 is the part that matters most. Governance isn't just about logging what happened. It's about preventing the wrong things from happening in the first place.
The MCP opportunity
The Model Context Protocol (MCP), released by Anthropic in late 2024, is becoming the standard way AI agents connect to external tools. Instead of each agent needing bespoke integrations with every SaaS tool, agents call tools through MCP servers, standardized middleware that brokers the connection.
This creates a natural control point. An MCP server sitting between your agents and your SaaS tools can:
- Authenticate the calling agent and map it to a registered identity and role
- Evaluate each tool call against a policy before forwarding it to the target SaaS
- Log every call with full context: what was asked, what was returned, what policy applied
- Block calls that violate policy without the agent needing to know why
- Provide a global kill switch that suspends an agent across all tools simultaneously
It's the equivalent of what a reverse proxy does for web traffic, or what an API gateway does for services. There's a natural enforcement layer. The question is what policies you enforce there.
The window is now
Most organizations are still in the "we'll figure out governance later" phase with AI agents. That's understandable. The use cases are compelling, the tooling is new, and the security implications feel abstract until they're not.
The organizations that build governance infrastructure now, while agent deployments are still manageable, will be in a very different position from those who retrofit controls onto a system that's grown too large to audit.
Access control for humans took decades to get right. The window to get it right for agents, before the mess becomes irreversible, is narrowing. The frameworks already exist. The control point already exists. What's needed is the will to enforce it before something goes wrong.