Runtime guardrails for Copilot Studio agents raise the bar on AI governance

At a glance

What this is: This is an analysis of runtime guardrails for Copilot Studio agents, with the key finding that real-time evaluation and blocking move AI security closer to the point of action.

Why it matters: It matters because agent governance has to cover tool use, intent, and execution, which are the moments where security and business impact are decided.

Context

Runtime guardrails sit between agent intent and agent execution, which is where many AI governance models are still weakest. In Copilot Studio environments, the real issue is not whether an agent exists, but whether it can safely decide to use tools, move data, and continue a workflow without creating unacceptable risk.

For identity and security teams, this is a governance problem as much as an AI control problem. AI agents behave like high-change, high-delegation actors, so access scope, tool connections, and runtime enforcement now need to be managed as part of the same control plane rather than as separate checkpoints.

Key questions

Q: What fails when Copilot Studio agents only have posture management and no runtime guardrails?

A: Posture management can show risky permissions, but it cannot stop an agent when a dangerous action is about to happen. Without runtime guardrails, a compromised prompt, tool, or connector can still drive the agent to overshare data, trigger a destructive workflow, or misuse trusted access before anyone can intervene.

Q: Why do agentic AI controls need to sit at decision time rather than deployment time?

A: Because the main risk appears when the agent turns intent into action. Deployment-time approval only says the configuration looked acceptable at one point in time, while decision-time controls can block unsafe behaviour in the exact session where it would cause harm.

Q: What are the signs that an AI agent security programme is too focused on configuration reviews?

A: The warning signs are familiar: teams can list agent settings, but they cannot say how a harmful tool call gets blocked, how prompt injection is detected during execution, or who can override the guardrail. If the control set stops at inventory and posture, the programme is not governing runtime behaviour.

Q: How should security teams govern AI-enabled workflows that can act on their own?

A: Treat them as identity-governed execution paths, not just software features. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.

Technical breakdown

Runtime guardrails for agent execution

Runtime guardrails evaluate an agent while it is operating, not only when it is configured or approved. That means the control must inspect tool calls, prompts, connector use, and the intent behind a requested action before the action is completed. In a Copilot Studio setting, this is materially different from posture management, which can tell you an agent has risky permissions but cannot stop a harmful email, data query, or workflow step at the moment of execution. The architectural shift is from static policy checking to inline decision enforcement.

Practical implication: teams need controls that can interrupt execution, not just report on misconfiguration after deployment.

Why prompt injection and tool poisoning are runtime problems

Prompt injection and tool poisoning succeed because the agent trusts inputs that look legitimate inside the workflow. A prompt can steer the model, while a compromised tool or API can inject malicious instructions through a path the agent already treats as normal. The risk is not limited to text generation, because the agent can chain a poisoned instruction into real actions across connected systems. Runtime analysis matters because the malicious behaviour is often only visible when the agent actually decides what to do with the input.

Practical implication: defend the execution path, not just the model prompt, when agents can call external tools and services.

Decision-time policy enforcement in agentic systems

Decision-time enforcement treats the agent's choice as the security boundary. Instead of assuming a reviewed configuration will remain safe, the control checks every action against policy at the point where the agent requests to send, retrieve, modify, or trigger something. This is especially important when an agent has broad connectors, because the blast radius of a single unsafe decision can reach email, databases, documents, or business workflows. In practice, this becomes a form of runtime authorisation for non-human decision makers.

Practical implication: align policy checks to the action the agent is about to take, not to the environment it was originally approved in.

Threat narrative

Attacker objective: The attacker objective is to use the agent's trusted execution path to trigger harmful or data-exposing actions inside enterprise systems.

1. Entry occurs when an agent receives a crafted prompt or compromised tool input that appears valid inside the workflow.
2. Credentialed or trusted access is then used to steer the agent toward an unsafe action such as oversharing data or invoking a harmful connector.
3. Impact follows when the agent executes the decision in-line, turning a manipulated instruction into a real business action before users can intervene.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime enforcement is now the missing layer in agent governance: configuration review alone cannot stop an agent from making a harmful choice once execution begins. The security boundary for agentic systems has moved from build-time approval to decision-time enforcement. For practitioners, that means runtime policy must sit inside the control model, not beside it.

Copilot Studio makes the identity problem visible, not smaller: once an agent can call tools and act inside business workflows, it behaves like a non-human identity with delegated authority. That creates a direct intersection between AI governance and NHI governance, because the real control question becomes who or what is authorised to act, under what conditions, and with what blast radius. Practitioners should treat agent access as governed identity, not just application logic.

Malicious intent detection is more useful than syntax filtering in agent security: the article's emphasis on blocking unsafe actions shows why security teams need to reason about outcomes, not just inputs. An agent can produce benign-looking text while still carrying out a destructive workflow step. The more agents are embedded in operational systems, the more security depends on outcome-based control points. The named concept here is decision-time authorisation gap: the failure to enforce policy at the exact moment an agent turns intent into action. Practitioners should close that gap before broad production rollout.

Tool ecosystems are becoming the real attack surface for agentic AI: the agent is only as safe as the connectors, APIs, datasets, and MCP-enabled integrations it can reach. That means the category is converging on supply-chain style governance, where the security question is no longer just model safety but dependency trust. Security teams should inventory every connected component as part of the agent's trust boundary and enforce controls accordingly.

Inline guardrails change the adoption debate: organisations no longer have to choose between broad agent deployment and visible security, but they do have to accept that runtime control becomes a prerequisite for scale. That shifts the market conversation away from pilots and toward enforceable operating models. Practitioners should assume agent deployment without runtime controls will remain an exception rather than a sustainable standard.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Decision-time authorisation gap: agent programmes fail when teams rely on configuration review but cannot stop an unsafe action at the moment an agent decides to act. The control model has to move into the execution path, because that is where prompt injection, tool abuse, and oversharing become real outcomes.

Runtime guardrails also change how access should be measured. If an agent can reach tools, datasets, and workflows during a live session, the question is not whether it was approved once, but whether its current action still fits policy, least privilege, and business intent.

For practitioners

• Implement runtime blocking for agent actions Enforce inline checks that can stop an agent before it sends email, modifies data, or invokes a risky connector. The control should evaluate the requested action and its context at the moment of execution.
• Map every Copilot Studio connector and tool Inventory the tools, APIs, MCPs, and datasets each agent can reach, then tie those dependencies to approved business use cases and risk tiers.
• Separate posture review from runtime approval Use posture management to identify misconfiguration and over-permissioning, but require runtime policy to make the final decision when the agent acts.
• Define explicit blocks for oversharing and destructive actions Write policies for data exfiltration, sensitive-data disclosure, destructive commands, and suspicious tool behaviour so the guardrail can stop the exact outcomes you want to prevent.

Key takeaways

• Runtime guardrails shift Copilot Studio governance from static approval into the execution layer where an agent's action can be blocked before harm occurs.
• The governance gap is not visibility alone. The issue is whether a security team can stop a prompt-driven or tool-driven action at decision time.
• Treat Copilot Studio agents as governed non-human identities with runtime policy, scoped tool access, and explicit stop conditions for unsafe behaviour.

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.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Decision-Time Authorisation: Decision-time authorisation is the practice of checking whether an action is allowed at the exact moment a system is about to perform it. For AI agents, this means policy must be enforced during runtime, because approval at setup time does not prevent unsafe behaviour later.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It gives security practitioners a practical way to align delegated access with the controls needed for agentic systems.