Notifications
Clear all
Topic starter
22/06/2026 10:02 am
TL;DR: Copilot Studio agents can reach enterprise resources through MCP-connected tools in a few clicks, but static credentials and user-consent OAuth flows leave weak auditability and unpredictable access scope, according to Aembit. The deeper issue is that existing IAM models still assume stable, reviewable access paths, which agent runtime behaviour does not provide.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
Q: How should security teams govern Copilot Studio agents that connect to enterprise systems?
A: Treat Copilot Studio agents as non-human identities with runtime behaviour, not as normal user sessions.
Q: Why do static credentials create more risk for AI agents than for scripts?
A: Static credentials assume the actor’s behaviour is predictable after issuance.
Q: What breaks when an agent shares credentials across multiple sessions?
A: Shared credentials destroy attribution and make it impossible to prove which user session triggered which access.
Practitioner guidance
- Define a separate access model for Copilot Studio agents Map agent access paths separately from user entitlements and service accounts, then document which resources the agent may call, under what conditions, and with what expiry rules.
- Eliminate standing credentials for agent sessions Replace persistent secrets with short-lived credentials issued only when the request matches policy, the session is valid, and the target resource is approved.
- Tie every agent action to an attributable audit chain Log the user session, agent identity, policy decision, credential issuance, and accessed resource in one record so incident response can reconstruct the path without guesswork.
What's in the full announcement
Aembit's full blog post covers the operational detail this post intentionally leaves for the source:
- A concrete explanation of how the Copilot Studio integration brokers credentials at runtime for enterprise resources.
- A step-by-step view of the audit trail fields that tie agent, user session, policy, and resource access together.
- Implementation detail on how the integration handles short-lived credentials and policy enforcement in practice.
- A walkthrough of the Agentic AI Deployment Checklist for teams evaluating multiple agent platforms.
👉 Read Aembit's analysis of Copilot Studio agent access and IAM gaps →
Copilot Studio agents and IAM: what security teams need to govern?
Explore further
22/06/2026 10:45 am
Standing access was designed for stable actors. That assumption fails when a Copilot Studio agent can decide which tool to call at runtime and change its execution path across sessions. The implication is not simply to add more policy checks, but to recognise that provisioning-time privilege design no longer describes the actual access behaviour of the actor.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable when an AI agent accesses the wrong enterprise resource?
A: Accountability should sit with the team that owns the agent policy, the connected resource, and the approval logic that allowed the access. Human delegation does not remove accountability, but shared or opaque credentials make it much harder to assign it cleanly after the fact.
👉 Read our full editorial: Copilot Studio agent access exposes the IAM gap teams must close
