By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: Noma SecurityPublished October 7, 2025

TL;DR: Copilot Studio agents can now be evaluated and blocked in real time during execution, extending visibility and posture management into the runtime layer where unsafe tool calls, prompt injection, and policy violations can actually cause harm, according to Noma Security. The governance shift is that agent security must cover decision-making, not just configuration.


At a glance

What this is: This is an analysis of runtime guardrails for Microsoft Copilot Studio agents, with the key finding that runtime control is needed because visibility and posture management alone do not stop unsafe agent actions.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly need to govern agent behaviour at the point of execution, not only at provisioning and configuration time.

By the numbers:

👉 Read Noma Security's runtime guardrails analysis for Microsoft Copilot Studio agents


Context

Runtime guardrails for AI agents address a simple but unresolved security problem: configuration checks do not stop bad decisions once an agent is live. In Copilot Studio and similar agent platforms, the governance gap sits at the execution layer, where tool use, delegated permissions, and data access can create damage faster than human review can react. The underlying issue is not limited to one vendor's environment; it affects any programme treating agents as ordinary automation rather than dynamic identity-bearing systems.

For IAM and NHI teams, the important shift is that an agent's risk profile is defined by both its standing access and its runtime behaviour. That means security decisions must account for tool connections, connector scope, data exposure, and whether the platform can halt unsafe actions before they complete. In practice, the article describes a capability set that is now becoming typical for serious enterprise agent deployments rather than an edge case.


Key questions

Q: What breaks when AI agents are approved only once at deployment?

A: Point-in-time approval breaks when an agent’s capabilities, integrations, or data access change after review. Weekly feature updates, new MCP connections, and expanded API reach can turn a previously acceptable tool into a higher-risk one without any new approval event. Continuous validation is the only defensible response.

Q: When does AI governance become an IAM and NHI problem?

A: It becomes an IAM and NHI problem as soon as autonomous systems use credentials, APIs, or delegated access to perform actions. At that point, the quality of identity assignment, privilege scope, logging, and lifecycle control determines whether the system can be governed and audited responsibly.

Q: How do security teams know whether agent guardrails are working?

A: They know guardrails are working when denied tool calls are visible in logs, high-risk paths are blocked consistently, and the agent cannot override policy from inside its own session. Observe mode is useful first because it shows what the agent actually tries to do before the team decides where to deny access. The signal is repeatable enforcement, not model compliance.

Q: Should organisations treat Copilot Studio agents like privileged identities?

A: Yes, where those agents can send messages, access business systems, or invoke APIs that alter records. The practical question is not whether the agent is human, but whether it can cause privileged outcomes. When it can, governance should include least privilege, runtime policy, and tight ownership over delegated access.


Technical breakdown

Why visibility and posture management stop short of runtime protection

Visibility and posture management answer what agents exist, what they can connect to, and which configurations are risky. They do not answer whether an agent will make a harmful decision during a live session. Runtime protection closes that gap by inspecting intent and execution as the agent calls tools, moves data, or triggers actions. In agentic systems, the threat is often not a broken login but a validly authorised action taken in the wrong context. That is why pre-deployment checks alone cannot be treated as a complete control plane.

Practical implication: treat configuration review as a starting control and add runtime enforcement for every high-impact agent workflow.

How in-line guardrails intercept unsafe Copilot Studio actions

In-line guardrails sit inside the decision path rather than outside it. The platform evaluates the agent's planned action, compares it to policy, and can block execution before a tool call completes. This is materially different from after-the-fact detection because it prevents oversharing, destructive commands, and unauthorised data movement while the session is still active. For Copilot Studio, this matters because agents can combine connectors, datasets, and MCP-style tool access in ways that amplify a single bad decision into a broader business incident.

Practical implication: enforce policy at the tool-call layer for email, database, and API actions that can leak data or alter systems.

What agent supply chain visibility needs to include

A Copilot Studio agent is not a single object. It is a composite of tools, APIs, models, datasets, connectors, and access paths that together form an attack surface. If security teams cannot map those dependencies, they cannot judge whether the agent has excessive permissions, risky data exposure, or a poisoned upstream dependency. That makes supply chain visibility part of agent governance, not just a cloud or app-security concern. The same logic applies to NHI governance because the agent inherits identities, secrets, and delegated access across its stack.

Practical implication: inventory each agent's tools, connectors, datasets, and delegated identities before approving production use.


NHI Mgmt Group analysis

Runtime control is now the dividing line between agent visibility and agent governance. A platform can show that an agent exists and list its connectors, but that does not prevent a live misuse event. The governance model fails when organisations stop at posture management and assume the runtime will behave. For IAM and NHI programmes, that is the wrong boundary because the risky object is the action, not the configuration alone. Practitioners should treat execution-layer control as mandatory for production agents.

AI agents create a new form of identity governance debt. They accumulate delegated access, tool trust, and data reach faster than traditional review cycles can keep up. That creates a named concept we should recognise as agent runtime exposure: the period in which an agent can take harmful action before policy intervenes. The shorter that window, the less blast radius an agent can generate. Security teams should measure whether they can constrain that exposure window in real time.

MCP and connector ecosystems widen the governance surface even when the model itself is not compromised. The issue is often not model jailbreak alone, but trusted tool paths that let an otherwise legitimate agent act beyond intent. This is where agent security intersects with NHI governance, because access tokens, service permissions, and delegated credentials become the operational control points. Practitioners should map tool trust with the same seriousness they apply to privileged human access.

Secure-by-design agent development will increasingly be defined by runtime policy, not by launch-time assurance. Enterprises that rely on static approval gates will find that the control breaks down as soon as agents begin chaining actions across systems. The market is moving toward controls that can evaluate context, intent, and downstream effect during execution. Security leaders should expect agent governance to converge with PAM-like enforcement patterns for high-risk actions.

Copilot Studio is a useful case study because it reflects a broader enterprise reality, not an isolated product pattern. Any agent platform that combines connectors, data sources, and delegated access faces the same governance problem. The lesson is not vendor-specific. It is that agent adoption without runtime guardrails converts speed into unmanaged identity and workflow risk. Practitioners should read this as a signal to harden the control plane before scale exposes the gap.

What this signals

Agent runtime exposure is emerging as the metric that matters most for enterprise AI control. The relevant question is no longer whether an agent is visible in inventory, but how long it can remain in a harmful state before policy interrupts it.

Runtime enforcement will increasingly define whether AI adoption is governable or merely observable. Teams that rely on connector review and posture scoring alone will discover that delegated access can still turn a legitimate action into a security event within a single session.

Identity teams should expect agent governance to blend NHI principles with policy enforcement at execution time, especially where tools and APIs can alter records or move data. The operational target is shorter exposure windows, tighter delegated scope, and stronger evidence that controls can stop actions rather than just record them.


For practitioners

  • Map agent decision paths before production approval Document each Copilot Studio agent's tools, connectors, datasets, and delegated identities, then classify which actions can change data, send communications, or invoke external systems. This inventory should become part of your production risk review, not a one-time architecture diagram.
  • Apply runtime policy to high-impact tool calls Block or require escalation for actions such as email sends, database writes, credential use, and API calls that can expose data or trigger business-impacting changes. Align those rules with least privilege and task scope so the agent only performs the minimum necessary action.
  • Separate posture review from execution control Keep configuration scanning, connector review, and permission analysis, but do not treat them as substitutes for in-line enforcement. The agent should be checked before deployment and re-checked during runtime when context, content, or intent changes.
  • Measure containment speed, not only detection coverage Track how quickly your controls can stop an unsafe agent action after intent is formed, especially when the action touches sensitive workflows. A control that logs an event but cannot interrupt execution leaves the organisation exposed to the exact risk runtime guardrails are meant to reduce.

Key takeaways

  • Agent security fails when organisations stop at visibility and posture management and never control the runtime decision path.
  • The evidence base is clear that AI agents are already acting beyond intended scope at scale, which makes runtime guardrails a present-tense control requirement.
  • Practitioners should govern agents like dynamic identity-bearing systems, with execution-layer enforcement for high-impact actions and delegated access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Runtime guardrails and tool misuse map directly to agentic AI security risks.
OWASP Non-Human Identity Top 10NHI-05Delegated access and runtime misuse are core non-human identity governance concerns.
NIST AI RMFGOVERNThe article is about governance, accountability, and oversight for AI systems in production.
NIST CSF 2.0PR.AC-4Agent access and least-privilege enforcement align with identity and access control outcomes.

Review agent permissions and connector scope so runtime actions stay within approved identity boundaries.


Key terms

  • Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
  • Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.
  • Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

What's in the full article

Noma Security's full technical post covers the implementation detail this analysis intentionally leaves for the source:

  • How runtime guardrails are embedded in Copilot Studio's decision flow for specific tool calls and agent actions
  • What the inline protection layer does when it detects malicious intent, prompt injection, or policy violations
  • How the platform maps connectors, APIs, datasets, and model dependencies across the agent stack
  • What audit trails and block conditions look like when an unsafe action is stopped in real time

👉 The full Noma Security post covers runtime enforcement details, connector coverage, and the specific agent behaviors the guardrails can stop.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps security and identity practitioners build the control mindset needed for AI agents, workloads, and privileged services.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org