AI Runtime Security: Securing Agents at Runtime, Not Configuration Time

Security teams managing AI deployments typically start in the same place: the configuration console. They review which agents exist, which connectors are attached, and which OAuth scopes were requested. That review produces a posture snapshot, a point-in-time picture of what agents are set up to do.

The problem is that posture snapshots describe theoretical configuration, not operational behavior. An agent configured with read-only access to a CRM may hold a bearer token that resolves to administrative privileges inside the application once all entitlements stack. A connector marked low risk in a configuration file may be calling MCP server tools that expose sensitive file systems at runtime. Neither fact is visible in the configuration layer.

One enterprise security team described the experience as ghost chasing: spending hours correlating static configuration signals with no runtime evidence of what actually happened, what data was accessed, or whether any policy was violated. The configuration looked fine. The runtime told a different story.

This is not a tooling failure. It is a category failure. Posture-based tools were designed for a world where applications behave deterministically. AI agents do not. They are probabilistic systems that select actions based on context, user input, and model inference. Their behavior at runtime can deviate meaningfully from the behavior their configuration implies. Governing them requires observing them while they run, not reviewing how they were set up.

Configuration is not reality. Runtime truth is the only signal that tells you what an agent actually did, on whose behalf, and what data it touched.

AI runtime security is the continuous observation of agent and MCP activity as it occurs, combined with identity correlation and effective authority mapping across every platform where agents operate. It answers questions that configuration review cannot: was this agent invoked, by whom, what tools did it call, what data did it access, did the invoker have the right to see that data?

This is distinct from AI observability in the engineering sense. Observability tools track latency, token usage, and model performance. AI runtime security tracks identity, access, and action: the three dimensions that determine whether an agent's behavior is policy-aligned or a security event.

The core capabilities of an AI runtime security approach include:

Continuous agent activity monitoring. Every tool call, connector invocation, and data access event is captured as it happens, not after the fact through log review.

Identity correlation. The agent's runtime actions are linked back to the human invoker, the agent's own machine identity, and the credentials it is operating under.

Effective authority mapping. What an agent can actually do inside each connected SaaS application, after all entitlements, OAuth grants, and inherited permissions stack, produces a real picture rather than a theoretical configuration.

MCP server inventory and tool visibility. Which MCP servers are connected, sanctioned versus unsanctioned, and what tools those servers expose at runtime, because tools inside an MCP server are only visible when the server is active.

Shadow AI and shadow agent detection. Agents deployed without IT or security oversight, including orphaned AI agents whose creator accounts have been disabled but whose credentials remain active, are surfaced automatically.

For a broader view of how these capabilities fit together, the AI agent security overview covers the full attack surface.

AI agents are non-human identities. They hold OAuth tokens, bearer credentials, and service account keys. They access data, send requests, and take actions continuously, without human confirmation at each step. In every functional sense, they behave like insiders.

No enterprise insider risk program covers them.

Non-human identities already outnumber human identities by 25 to 50 times in modern enterprises. Every AI agent deployment accelerates that ratio. Traditional IAM programs assume human lifecycle events trigger access reviews: onboarding, role changes, offboarding. None of those events apply to agents. An agent whose creator leaves the organization does not get offboarded. It becomes an orphaned agent, still running, still holding the creator's credentials, still capable of accessing every system the creator could reach.

The machine insider risk is not hypothetical. It is the direct consequence of deploying agents faster than any governance framework can track them. One enterprise discovered 377 Copilot agents through a security assessment they had not known existed. Another had over 2,500 agents created before any inventory was in place. In both cases, the agents were operating with inherited credentials and SaaS access that no security team had reviewed.

Treating every agent as a machine identity with a blast radius (the full scope of data and systems it could access or affect given its current entitlements) is the starting point. That blast radius is almost always larger than the configuration suggests.

For a structured path to surfacing these risks, the AI agent risk assessment walks through the method security teams use in practice.

Two specific runtime behaviors produce the highest-severity risk in enterprise AI deployments: maker mode credential inheritance and action chaining.

Maker mode is the default configuration in many low-code agent builders. When an agent is built in maker mode, it uses the creator's credentials for every connector it calls. A user invoking that agent at runtime does not need the creator's permissions. The agent provides them automatically. A user without Salesforce access can invoke a maker mode agent built by a Salesforce administrator and retrieve CRM records they were never authorized to see. The agent did exactly what it was designed to do. IAM controls were bypassed entirely.

This is not a bug. It is a feature that creates machine insider risk at scale. The maker mode security risk appears across Microsoft Copilot, Salesforce Agentforce, and other major platforms.

Action chaining compounds the problem. Agents do not take single actions. They take sequences of actions across multiple tools and applications, with each step building on the last. A single agent invocation can trigger a connector call, retrieve a file, pass its contents to a second tool, write output to a third system, and send a summary to an external endpoint. The blast radius of that chain is the sum of every system touched, not the permissions of the user who started it.

Point-in-time configuration reviews cannot capture this: by the time a security team reviews the agent's configuration, the action chain has already completed.

Toxic combinations multiply severity further. An individual risk factor (an agent accessible org-wide, or a connector running in maker mode) may score as medium severity in isolation. When those factors appear together on the same agent, the combination produces critical-priority risk. An unmanaged shadow agent with org-wide access and maker mode credentials connecting to a system containing sensitive financial data is not three medium risks. It is one critical exposure with a blast radius that spans the organization.

The operational challenge for security teams is not understanding that AI runtime security matters. It is getting visibility across a fragmented landscape where agents run on Copilot Studio, Salesforce Agentforce, Amazon Bedrock, n8n, ChatGPT Enterprise, and custom platforms simultaneously.

Each platform produces its own logs. Those logs are siloed, require manual correlation, and do not show what an agent is actually authorized to do inside the other SaaS applications it connects to. A Copilot agent calling a Salesforce connector appears in Copilot's logs as a connector invocation. It does not appear in Salesforce's logs as a user access event. The cross-platform action is invisible to both native tools.

A single pane of glass for AI runtime security requires correlating data from agent platforms, identity providers, and connected SaaS applications into one unified authority map. That map needs to show:

SignalWhat It AnswersAgent inventoryWhat agents exist, who built them, which platform they run onEffective authorityWhat each agent can actually access after all entitlements resolveRuntime activityWhat the agent did, when, on whose behalfMCP server connectionsWhich servers are active, sanctioned or unsanctioned, what tools they exposeIdentity correlationWhether the invoker had the right to access the data the agent retrieved

This cross-platform view is the prerequisite for every other AI security conversation. You cannot govern what you cannot see. AI agent governance starts with inventory and effective authority mapping, not with policy documents.

The AI agent visibility layer provides the structural model security teams use to sequence these capabilities from initial visibility through runtime enforcement.

Detection without enforcement is expensive logging. Security teams need to move from observing risky agent behavior to preventing it. That requires deterministic guardrails applied to probabilistic systems.

The conceptual tension here is real. AI agents are non-deterministic by design. Their responses and action selections vary based on context, model state, and user input. You cannot make the agent deterministic. You can make the rules that govern its actions deterministic.

Deterministic guardrails for AI agents enforce fixed, predictable rules at the action boundary: before a tool call completes, before a connector retrieves data, before an agent passes context to a downstream system. The rule does not ask the model what it intended. It evaluates the action against policy and either permits or blocks it.

Specific guardrail targets for enterprise AI deployments include:

Maker mode enforcement. Block invocations where the invoker's identity does not have the right to access data at the maker's privilege level.

Least privilege enforcement. Restrict agent operations to the minimum permissions required for the current task, regardless of what the agent's configuration technically allows.

Orphaned agent controls. Flag or suspend agents whose creator accounts are disabled, preventing continued operation under inherited credentials.

Unsanctioned MCP server blocking. Prevent agents from calling tool servers that have not been reviewed and approved by the security team.

Runtime enforcement capabilities targeting specific platforms are in active development. The target state is deterministic guardrails operating at the moment of action, integrated directly with AI platforms via native APIs rather than inline proxies. Continuous monitoring and effective authority mapping are the present capabilities that this enforcement layer builds on.

For security teams evaluating where to start, the AI agent risk assessment provides a structured method for identifying the highest-priority agents and toxic combinations in an existing environment.

The next step is knowing what agents you have. Start with a structured AI agent risk assessment to surface the inventory gaps, toxic combinations, and effective authority exposures that configuration tools are not showing you.