Notifications
Clear all
Topic starter
21/08/2026 4:48 pm
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.
NHIMG editorial — based on content published by Noma Security: Runtime guardrails for Microsoft Copilot Studio agents
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Noma Security's runtime guardrails analysis for Microsoft Copilot Studio agents →
Copilot Studio runtime guardrails: are your agent controls keeping up?
Explore further
21/08/2026 5:06 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime guardrails for Copilot Studio agents raise the bar on AI governance
