Traditional security was built for users, endpoints, and applications. AI agents violate all three assumptions. Field research from Microsoft Security professionals and Microsoft's own agent misconfiguration research reveals the real-world risks are worse than most organisations realise.
| Property | Capability Upside | Security Downside | Risk Severity |
|---|---|---|---|
| Self-initiating | Automates workflows without human prompts | May take unintended actions outside guardrails | HIGH |
| Persistent | Continuous value; handles tasks 24/7 | Over-permissioning drift; undetected misuse; orphaned agents | HIGH |
| Opaque | Abstracts complexity; simplifies workflows | LLM black-box; hard to audit; LLM non-determinism makes output unpredictable | HIGH |
| Prolific | Low-code / no-code creation accelerates adoption | Shadow agents; sprawl; most existing Copilot Studio agents are Classic — outside Entra security perimeter entirely | CRITICAL |
| Tool-invoking | Real actions: email, APIs, file write | Prompt injection converts to real-world harm; MCP tools extend this to any connected system | CRITICAL |
| Context-consuming | Rich reasoning over enterprise data | Sensitive data enters AI context — new exfiltration surface | CRITICAL |
| Maker-authenticated | Creator can configure deep integration at build time | Copilot Studio agents authenticate as their maker, not the user — maker's full permissions extended to every user who interacts with the agent | CRITICAL |
| Autonomous | Acts independently without per-action human approval | Overprivileged, manipulated, or misaligned agents can act as "double agents" — working against the outcomes they were built to support (Microsoft ZT4AI framing). Agents with excessive permissions and no guardrails are the primary risk vector. | CRITICAL |
Our Identity page covers the OBO (On-Behalf-Of) token problem. Copilot Studio introduces a more dangerous variant: maker credentials. The agent authenticates to connected services as the person who built it — not the person using it. If a developer with admin rights builds an agent and shares it org-wide with one toggle, every employee in the organisation can interact with it using the maker's admin-level permissions. This is the most widespread and underappreciated privilege escalation risk in current enterprise AI deployments. Field research by Microsoft Security MVP Derk van der Woude confirms this pattern is common in production environments.
The specific Copilot Studio risk patterns — no-auth agents, org-wide sharing, Classic vs Modern agents, maker credentials, ownerless agents, name sync bug — are covered in detail on the Copilot Studio vs Microsoft Foundry page alongside the five authentication patterns and 30-minute audit KQL. For detection and remediation runbooks, see Playbooks.
Microsoft's Secure Access in the Age of AI report found a near-even split: 53% of AI-related access incidents were malicious, 47% were accidental. Accidental incidents are driven by complexity, unclear ownership, and misaligned controls — not adversaries. As agents are deployed faster than policies can be updated and permissions are configured broadly "to make sure they work", unintentional misuse escalates quickly. The risk taxonomy below covers both categories.
Additionally: 97% of organisations experienced an identity or network access incident in the past year, and 70% of those were tied to AI-related activity. Source: Microsoft Entra Blog, March 2026
| Risk | Description | Who Owns It | Primary Microsoft Control |
|---|---|---|---|
| Agent sprawl | No inventory of deployed agents; no lifecycle ownership | IT / Security | Agent 365 ⚠ per-user license |
| Classic agents — outside Entra perimeter | Most existing Copilot Studio agents are Classic Service Principals with no Entra security product coverage | IAM / Security | Migration to Modern Agents ⚠ tool not yet available |
| Maker credentials | Copilot Studio agents authenticate as their builder — maker's permissions extended to all users of the agent | IAM / AppSec | Power Platform Managed Environments; enforce end-user auth per agent |
| No-auth agents | Agents set to no authentication — accessible to anyone in Teams with no login | IT / Security | AIAgentsInfo KQL detection; Power Platform admin enforcement |
| Org-wide sharing | One toggle exposes agent to all employees — compounds with maker credentials | IT / Security | Power Platform Managed Environments — set sharing limits |
| Over-permissioned access | Agents granted broad access; OBO inherits user's full rights | IAM / Security | Entra Agent ID ⚠ preview, Modern Agents only |
| Shadow AI / plugins | Business users deploy unsanctioned AI tools and MCP servers outside IT oversight | IT / CASB | Defender for Cloud Apps + Entra Internet Access GA Mar 31 2026 |
| MCP tool misuse | Agents invoke real enterprise tools via MCP — now via official Microsoft MCP server catalog | AppSec / Security | Foundry Guardrails ⚠ preview + Defender for Cloud Apps |
| AI model supply chain | Pretrained models from registries (Hugging Face, Azure ML) may carry embedded malware or backdoors. Training data can be poisoned before it reaches the pipeline. Build-time risks that traditional AppSec doesn't cover. | AppSec / ML Eng | AI Model Scanning in Defender for Cloud GA · RSAC 2026 |
| Prompt injection / XPIA | Malicious inputs hijack agent behaviour mid-task | AppSec / SOC | Prompt Shields + Entra Internet Access Prompt Injection Protection GA Mar 31 2026 |
| Data leakage | Sensitive data enters AI context; exfiltrated via outputs or prompts | DLP / Compliance | Purview DSPM + Purview DLP for Copilot GA Mar 31 2026 |
| Ownerless agents | No accountable owner — agents persist indefinitely with no governance review | IT / IAM | Power Platform Inventory; AIAgentsInfo Advanced Hunting |
How the three Zero Trust principles — Verify Explicitly, Use Least Privilege, Assume Breach — apply specifically to AI agents, the three-stage maturity model, and the 12 highest-priority ZT Workshop controls are covered on the Frameworks page.
Risk categories describe what can go wrong. This tier rubric tells you which agents to remediate first. Apply the criteria below to every agent in your inventory register — the tier drives both the remediation timeline and the depth of subsequent controls (red teaming scope, governance review cadence, sponsor accountability).
| Tier | Criteria (any of) | Required action | Governance cadence |
|---|---|---|---|
| HIGH Priority 1 | • No authentication • Maker credentials at agent or connector level • Org-wide sharing • No assigned owner • Handles regulated data (PII, financial, health, citizen records) | Remediate or block within 14 days. Full red team engagement before production. Sentinel Analytics Rule alerting on any change. | Reviewed at every Agent Lifecycle Board (monthly) |
| MEDIUM Priority 2 | • Authenticated but broad connector access (SharePoint, Exchange, Teams) • Sensitive but not regulated data connectors • Named owner present but no business sponsor • Shared with large group (50+) but not org-wide | Scope review within 30 days. DLP coverage validated. Annual focused red team on prompt injection & data exfiltration. | Quarterly governance sweep |
| LOW Monitor | • Delegated end-user authentication • Named users or small group sharing • Scoped data access (single team site, single connector) • Both owner and sponsor assigned | Document. Include in quarterly inventory check. Regression red team only on significant change (connector, tool, system prompt). | Annual audit + change-triggered review |
An agent that meets one HIGH criterion and four LOW criteria is still HIGH. Risk does not average down. A no-auth agent serving a tiny team and reading only a single SharePoint list is still HIGH because the no-auth condition alone makes it externally reachable. Apply the criteria as a screen, not a score.
Phase 1 inventory output → Phase 2 governance sequence (remediate HIGH first) → Phase 4 red team scope (Tier 1/2/3 maps to High/Medium/Low) → Phase 6 board reporting (tier distribution + trend). See the six-phase rollout on Strategy for the full sequence.
For agents that interact directly with citizens, vulnerable users, or make consequential decisions (benefits, healthcare, financial outcomes, public-facing services), security testing alone is not sufficient. An AI Trust and Safety assessment — typically using a recognised safety assurance methodology such as Adelard's safety case methodology — validates that the agent is trustworthy, reliable, and dependable across its full data pipeline. This is a separate assurance discipline from penetration testing or red teaming.
| Discipline | What it tests | Output |
|---|---|---|
| Security testing / red teaming | Adversarial robustness — prompt injection, data exfiltration, tool chain manipulation, jailbreak, model extraction | Vulnerabilities & exploit paths · OWASP LLM Top 10 coverage |
| AI Trust and Safety assurance | Reliability, dependability, fairness, safety-of-use — including failure modes for vulnerable users, edge cases, hallucination tolerance, and traceability of decisions | Safety case · auditable assurance argument · evidence pack for regulators |
| Responsible AI evaluation | Harms — bias, toxicity, manipulation, discriminatory outputs — typically via Foundry evaluations and Content Safety | Harm taxonomy coverage · evaluation telemetry |
Required for: agents interacting directly with the public, agents making decisions about benefits or eligibility, agents in healthcare or safeguarding contexts, agents handling vulnerable users. Recommended for: any agent classified as HIGH risk per the tier methodology above, plus any agent newly subject to EU AI Act Annex III high-risk classification. The output is an auditable safety case — not a posture score — suitable for regulator submission alongside the security evidence pack.