Ninety percent of AI agents running in enterprise SaaS environments today hold more access than any workflow actually requires.
Security teams managing AI agent deployments face a question their existing tools cannot answer: what did that agent actually do?
Configuration-based and posture-first tools can tell you what an agent is set up to do. They can read a connector definition, scan an OAuth scope list, or flag a permission that looks broad. What they cannot do is tell you whether the agent used that permission, on whose behalf, against which data, and whether the invoking user had any right to that data in the first place. That gap is the central AI runtime security challenge in 2026.
The Config-vs-Runtime Gap
Posture tools operate on theoretical configuration. They read the policy file, not the execution log. For human users, that approximation is often good enough because human behavior is relatively predictable and access changes slowly. AI agents are different. They execute thousands of tool calls per session. They chain actions across multiple SaaS applications in seconds. A connector that looks appropriately scoped in a configuration view may be querying sensitive CRM records, forwarding full conversation context to a sub-agent, or operating with a creator's admin credentials long after that creator's account was disabled.
One enterprise discovered 377 Microsoft Copilot agents through a security assessment that their own team did not know existed. Another had 2,500 agents created across their environment before any inventory existed. Configuration tools did not surface either situation, because the agents were not misconfigured by policy. They were simply invisible.
Agents Are Probabilistic by Design
This is the architectural argument that posture-first frameworks cannot escape. AI agents do not follow deterministic execution paths. They make probabilistic decisions about which tools to call, in what order, and with what parameters. A posture tool can verify that an agent has access to a SharePoint connector. It cannot predict or observe whether the agent will use that connector to retrieve a file, forward the content to a downstream sub-agent, and write a summary to an external webhook endpoint.
Probabilistic agents require deterministic guardrails. Those guardrails can only be enforced at runtime, because that is the only layer where the actual execution path is observable.
Effective Authority vs. Theoretical Configuration
The distinction that matters most for security architects is the gap between theoretical configuration (what the agent appears to have access to) and effective authority (what the agent can actually execute inside each SaaS application after all entitlements resolve).
Consider maker mode in Microsoft Copilot Studio. An agent built using a creator's admin credentials runs every invocation with that creator's full privilege level, regardless of who triggers it. A user without Salesforce access can invoke that agent and extract CRM records they were never provisioned to see. The configuration looks fine. The OAuth scope is assigned to the creator. No policy is technically violated. But the access control model has been bypassed entirely. That is effective authority in action, and no posture tool surfaces it.
Explore the full landscape of AI agent security risks to understand how these gaps compound across platforms.
Runtime-first agentic AI security is not a product category. It is an architectural principle: governance must happen at the layer where agents actually execute, not at the layer where they are configured. That principle translates into four capability layers, applied in sequence.
The Four Capability Layers
LayerWhat It AnswersWhy This Order1. IdentityWho built this agent? Whose credentials does it run on?You cannot scope access without knowing who the agent is2. InventoryWhat agents exist? What MCP servers are connected? What is sanctioned vs. unsanctioned?You cannot govern what you cannot see3. Runtime VisibilityWhat did the agent actually do? What data did it access? What actions did it chain?Configuration is not reality4. Deterministic GuardrailsWhat is the agent blocked from doing regardless of its probabilistic path?Detection without enforcement is expensive logging
Why These Four, In This Order
Identity comes first because every downstream question depends on it. An agent without a known, verified owner is an orphaned agent. An orphaned agent running with embedded admin credentials is a machine insider with no accountability chain. You cannot assign a blast radius, set a policy, or route an alert without knowing whose authority the agent is operating under.
Inventory comes second because security programs cannot govern what they cannot enumerate. Shadow agents, unregistered MCP servers, and unsanctioned connections are invisible to every control downstream of discovery.
Runtime visibility comes third because it converts posture signals into evidence. The question shifts from "could this agent access sensitive data?" to "did it, when, and what did it retrieve?" That shift from ghost chasing to runtime truth is what makes incident response tractable.
Deterministic guardrails come fourth because they are only meaningful once the first three layers are in place. A guardrail applied to an incomplete inventory blocks known agents while unknown agents operate freely. A guardrail applied without identity context cannot distinguish a legitimate admin action from a confused deputy attack.
For a deeper look at how these layers connect to specific AI agent governance controls, the governance framework page maps each layer to enforcement actions.
Agentic AI network security is not about packet inspection or traditional firewalls. It describes the live network of connections between agents, MCP servers, SaaS applications, and downstream tools that only becomes visible at runtime. This is the hidden layer between your SaaS apps, and it is where the most significant agentic AI security risk vectors operate.
Agent-to-Server Traffic at the MCP Layer
Model Context Protocol (MCP) servers are the connective tissue of modern agentic workflows. They expose tools that agents call to read files, query databases, send emails, and trigger API actions. An enterprise running n8n workflows may have dozens of MCP server connections, some authenticated, some not, some pointing to registered internal services, and some pointing to unregistered external domains.
The security question is not whether an MCP server exists. It is what tools that server exposes, whether those tools have been reviewed, and whether the agent calling them is authorized to do so. That question can only be answered at runtime, because the tools inside an MCP server are only visible when the server is executing.
Action Chaining Detection
Action chaining is the mechanism by which a single agent interaction compounds into a multi-step data extraction event. A user asks an agent a question. The agent calls a SharePoint connector to retrieve a document. It calls a CRM connector to pull related account records. It formats a summary and writes it to an external webhook. Each individual action may be within the agent's configured scope. The chain, observed as a sequence, reveals a data movement pattern that no single posture check would flag.
Runtime visibility surfaces action chains as sequences of tool calls with timing, identity context, and data classification signals attached. That is the difference between a configuration audit and operational network intelligence.
Blast Radius Visibility
Every agent has a blast radius: the scope of damage it could cause given its current entitlements if it were compromised, misconfigured, or invoked by an unauthorized user. Blast radius is not calculable from configuration alone because it depends on what the agent can actually execute across all connected SaaS applications, not just what its connector list shows.
Runtime-first security maps blast radius dynamically. When an agent gains a new MCP connection or its creator account is disabled, the blast radius changes. Static posture snapshots miss those changes between review cycles. Runtime observation catches them as they happen.
Learn how toxic risk combinations compound blast radius when multiple risk factors appear on the same agent simultaneously.
See what your agents are actually doing across platforms. Request an AI agent risk assessment to establish your runtime visibility baseline.
Traditional AI agent threat modeling starts with configuration gaps: what permissions does this agent have that it should not? Runtime-first threat modeling starts with a different question: what runtime-observable signals would confirm that a threat is occurring or has occurred?
The Shift From Config Gaps to Behavior Observation
Configuration-gap thinking produces a list of theoretical risks. Runtime-observable signal thinking produces a detection model. The distinction matters because probabilistic agents can execute harmful action chains without any single configuration being technically wrong.
"The question for security teams should not just be: which agents exist. It is what they can actually execute, on whose behalf, with what downstream reach, and whether any of that is policy-aligned."
A Runtime Threat-Modeling Exercise: Maker Mode Privilege Escalation
The following contrast shows how runtime-first threat modeling works in practice.
Threat: A user without Salesforce access invokes a Copilot Studio agent built in maker mode by a Salesforce administrator. The agent runs on the admin's embedded credentials. The user retrieves CRM records they were never provisioned to see.
Configuration-gap view: The agent has a Salesforce connector. The connector is in maker mode. Risk flag: medium. No further signal available.
Runtime-first view: The agent was invoked by User A. User A has no Salesforce entitlement in the identity graph. The agent executed a Salesforce query using the creator's admin credentials. The query returned records from the enterprise accounts object. User A has no record of accessing Salesforce through any other path. Alert: privilege escalation via maker mode, confirmed by runtime correlation of invoker identity against SaaS entitlement map.
The runtime view converts a theoretical medium risk into a confirmed, high-priority incident with an evidence trail. That is the operational value of mapping AI agent risks to runtime-observable signals rather than configuration states.
For a structured view of the full AI agent attack surface, including the vectors that runtime observation surfaces, the attack surface deep dive maps each threat to its detection layer.
Security teams ask the right question when they start planning a runtime-first program: where do we begin this quarter, and in what order do the four capability layers actually get deployed?
The Implementation Sequence
Start with identity resolution. Before any inventory work is meaningful, the identity layer must be established. This means correlating agent configurations with the credentials they run on, the creator accounts behind them, and the entitlements those accounts hold across connected SaaS applications. Identity resolution is what separates an agent inventory from a list of agent names.
Build the inventory second. Once identity is established, the inventory layer can classify every agent as sanctioned or unsanctioned, map connected MCP servers, and flag orphaned agents whose creator accounts are disabled but whose credentials are still active. This is the single pane of glass prerequisite. No security program is possible without it.
Activate runtime visibility third. With identity and inventory in place, runtime visibility becomes actionable. Tool calls are attributed to specific agents and invokers. Action chains are reconstructed from execution sequences. Data access events are correlated against entitlement maps to surface effective authority in real time.
Apply deterministic guardrails fourth. Guardrails enforced against a complete, identity-resolved inventory are precise. They block specific action types for specific agents based on confirmed entitlement context, not broad policy sweeps that generate noise or miss shadow agents entirely.
What to Start This Quarter
The most common mistake security teams make when beginning a runtime-first program is skipping the inventory layer and jumping directly to detection rules. Detection rules applied to an incomplete inventory are gap-ridden by definition.
This quarter, the practical starting point is a full AI agent risk assessment that surfaces every agent in the environment, maps creator identity and credential type, classifies MCP server connections as sanctioned or unsanctioned, and scores toxic combinations where multiple risk factors appear on the same agent. That assessment produces the inventory foundation on which all four runtime-first capability layers depend.
For teams managing Microsoft Copilot deployments specifically, the Microsoft Copilot AI agent defense page maps the maker mode risk scenario to specific detection and inventory capabilities. For Salesforce Agentforce environments, the Salesforce Agentforce security page covers the system mode and credential sharing risks specific to that platform.
The central argument of runtime-first agentic AI security is simple: configuration is not reality. Probabilistic agents operating across interconnected SaaS environments, MCP servers, and agent-to-agent pathways cannot be governed by tools that only read what agents are set up to do. They require a governance layer that observes what agents actually do, correlates that behavior against identity and entitlement context, and enforces deterministic rules at the moment of execution.
The four-layer sequence, identity, inventory, runtime visibility, and deterministic guardrails, is not arbitrary. Each layer is a prerequisite for the one that follows. Security teams that skip to detection without completing inventory are ghost chasing. Teams that apply guardrails without identity resolution are enforcing policy against an incomplete picture.
The agentic AI security risk problem is solvable. The framework is runtime-first. The starting point is knowing what you have.
Actionable next steps: