Non-human identities now outnumber human identities by 25 to 50 times in the average enterprise.
Security teams managing large AI deployments consistently report the same frustration: they are ghost chasing. They review configuration signals that tell them what could theoretically happen, with no evidence of what actually did happen. The native audit logs exist inside each AI platform, but they are siloed per tenant, require manual correlation across tools, and do not show what an agent is authorized to do inside the SaaS applications it connects to.
The core mechanism behind this visibility gap is straightforward. AI agents operate as machine insiders. They hold OAuth tokens and embedded credentials the same way a human insider holds a badge and a password. But no existing insider risk program covers them. When an agent acts on behalf of a user using maker mode credentials (the creator's admin-level privileges baked into the agent at build time), every user who invokes that agent gains access at the creator's privilege level. The invoker bypasses IAM controls entirely. The agent did nothing technically wrong. Your access controls were simply circumvented.
This is the machine insider risk pattern. It is distinct from a breach. It is a design-level privilege escalation that existing network, endpoint, and identity tools cannot detect because they were built to watch humans, not agents.
AI agents also move data at scale that human users cannot match. Agents move data at roughly 16 times the rate of human users. When a misconfigured or orphaned agent runs undetected, the blast radius compounds with every action it takes across connected applications.
For a deeper look at how this attack surface develops, the AI agent security overview covers the full threat model.
Security teams at large enterprises have discovered hundreds of AI agents in their environments that no one in the security organization knew existed. Inventory is not a feature. It is the prerequisite for every other security conversation.
A credible platform must answer these questions without manual effort:
Orphaned agents represent a specific, high-severity risk class. An agent whose creator account is disabled continues running with the inherited credentials of that disabled account. No human reviews it. No lifecycle process catches it. It is a zombie credential with an active blast radius.
The AI agent governance framework covers how to structure ownership and accountability once inventory is established.
Theoretical configuration is what the agent is set up to do on paper. Effective authority is what the agent can actually execute inside each connected SaaS application after all entitlements resolve.
These two things are almost never the same. An agent configured with read-only access in its builder interface may hold an OAuth token with write permissions to a connected CRM. A connector built in maker mode may grant every invoker access to the creator's full Salesforce administrator view, regardless of the invoker's own Salesforce permissions.
Platforms that only read configuration files see theoretical configuration. Platforms that correlate agent setup with actual SaaS entitlements, identity context, and real-time behavior produce effective authority maps. Only the second category gives security teams a true picture of blast radius.
This is the architecture gap in agent security that most enterprise teams discover too late.
Model Context Protocol (MCP) servers are the connective tissue between AI agents and external tools. Every MCP connection an agent holds is a potential action pathway into a real system. Security teams need to know which MCP servers exist in their environment, which are sanctioned, and which are shadow servers operating without security review.
The black box problem with MCP is specific: the tools inside an MCP server are only visible at runtime. Retroactive log review cannot reconstruct what tool calls were made or what data was accessed. A platform that only reads configuration cannot tell you which tools an MCP server exposed to an agent during a live session.
Shadow MCP servers represent the same risk as shadow AI apps, with one critical difference: apps receive data, agents take actions. An unsanctioned MCP connection is an active action pathway, not a passive data channel.
Evaluate whether a platform can:
Detection without enforcement is expensive logging. Probabilistic agents, by design, can deviate from intended behavior. Deterministic guardrails apply fixed, predictable rules to agent behavior at runtime, cutting off action options before damage occurs.
When evaluating vendors, ask specifically about their enforcement architecture. A platform that sits at the control plane layer (correlating identity, entitlements, and agent behavior) is positioned to enforce guardrails without becoming an inline network proxy. The distinction matters: an inline proxy creates latency, single points of failure, and deployment friction. A control plane approach enforces through the AI platform's native APIs and webhooks.
Treat runtime guardrail availability as a capability to require on your vendor roadmap, not necessarily a day-one general availability feature. Ask vendors for specific platform timelines and enforcement mechanisms.
Use this table during vendor evaluation to separate platforms with runtime truth from those offering only theoretical configuration.
Evaluation CriterionConfiguration-Only ToolsRuntime-Aware PlatformsAgent inventory sourceStatic config readsLive platform integration plus runtime telemetryEffective authority visibilityWhat the config saysWhat the agent can actually execute in each SaaS appMCP server discoveryKnown/registered servers onlySanctioned and shadow servers, including tool call activityOrphaned agent detectionManual review requiredAutomated: flags agents with disabled creator accountsMaker mode privilege escalationNot visibleCorrelates runner identity with creator credentialsAgent-to-agent data exposureSingle platform onlyCross-platform agent communication pathsDeployment requirementSaaS connector per appConnector-free, security team deploys independentlyToxic combination detectionIndividual risk flagsCompound risk scoring across multiple factors simultaneouslyPath to enforcementAlert and logDeterministic guardrails via native platform APIs (roadmap)Single pane of glassPer-platform dashboardsUnified view across multiple AI platforms
The SaaS AI agent security platform overview provides additional context on what a unified view looks like in practice.
These questions separate platforms with genuine runtime capability from those repackaging configuration reads as security.
On inventory:
"Show me every agent in our environment, including agents created by users outside the IT organization. How does your platform discover agents that were never registered with security?"
On effective authority:
"If an agent is built in maker mode using an administrator's credentials, how does your platform detect when a lower-privilege user invokes that agent and accesses data beyond their authorization?"
On MCP coverage:
"Can your platform enumerate MCP servers that were connected to agents without security team approval? How does it surface tool calls made during live agent sessions?"
On connector-free deployment:
"Does your platform require a SaaS connector or admin-level integration for every application an agent connects to? Can the security team deploy independently without SaaS platform admin involvement?"
On toxic combinations:
"How does your platform prioritize risk when multiple risk factors appear on a single agent simultaneously? For example: an org-wide accessible agent, built in maker mode, with sensitive CRM access, whose creator account is now disabled."
On enforcement:
"What is your specific roadmap for deterministic guardrails? Which platforms support enforcement today, which are targeted for near-term delivery, and what is the enforcement mechanism (native API, webhook, or inline proxy)?"
Use this checklist as a minimum viable requirements set before any AI agent security platform reaches procurement review.
Agent Inventory
- [ ] Automated discovery across all supported AI platforms without manual enumeration
- [ ] Orphaned agent detection (creator account disabled, agent still active)
- [ ] Shadow agent identification (agents deployed without security oversight)
- [ ] Agent creator, owner, and invoker identity correlation
- [ ] Org-wide and publicly accessible agent flagging
Effective Authority and Identity
- [ ] Maker mode detection: correlates runner identity with creator credential level
- [ ] Cross-platform identity graph mapping agents to their SaaS entitlements
- [ ] Confused deputy detection: agent with elevated permissions acting for unauthorized invoker
- [ ] Non-human identity lifecycle tracking (creation, modification, disablement)
MCP Server Coverage
- [ ] Automated MCP server inventory across the environment
- [ ] Sanctioned versus unsanctioned server classification
- [ ] Shadow MCP server discovery
- [ ] Runtime tool call visibility (not configuration-only)
- [ ] Flagging of agents connecting to unregistered external domains
Risk Prioritization
- [ ] Toxic combination scoring: compound risk across multiple simultaneous factors
- [ ] Blast radius estimation per agent based on actual entitlements
- [ ] Tiered severity: critical, high, medium mapped to specific risk factor combinations
Deployment and Operations
- [ ] Connector-free deployment: security team operates independently of SaaS admins
- [ ] Single pane of glass across all supported AI platforms
- [ ] Audit trail sufficient for compliance and incident response
- [ ] Integration with existing ticketing and SIEM workflows
Enforcement Roadmap
- [ ] Documented platform-by-platform timeline for deterministic guardrails
- [ ] Enforcement mechanism clearly defined (native API, webhook, not inline proxy)
- [ ] Policy configuration capability for least privilege enforcement at runtime
The AI agent risk assessment can help security teams baseline their current exposure before beginning vendor evaluation.
The framework above reflects a single, non-negotiable principle: configuration is not reality. Security teams that evaluate AI agent platforms on configuration-only criteria will invest in tools that show them what should be happening while remaining blind to what actually is.
The shift from posture to evidence is the central buyer evolution in 2026. The questions to ask, the criteria table, and the requirements checklist in this guide are designed to accelerate that shift. Start with inventory. Demand effective authority mapping. Require MCP server discovery that includes shadow servers. Insist on a credible, platform-specific roadmap for deterministic guardrails. Deploy without connector dependencies so the security team controls its own timeline.
Probabilistic agents operating across your enterprise SaaS environment will not wait for your governance program to catch up. Deterministic guardrails, built on runtime truth, are how security teams close that gap without slowing down the business.
Actionable next steps: