I almost wish we’d kept calling some of these things bots.

I’ve been trying to keep a working guideline for evaluating agent risk. The word “agent” covers a lot of ground, and some agent-builder experiences look to me like large prompt books: reusable instructions, selected knowledge, and a consistent way to ask for something.

Useful, absolutely. But if it still works within your permissions, answers when you ask, and leaves you responsible for taking action, how much new authority did we introduce?

Microsoft describes Agent Builder as respecting existing Microsoft 365 permissions, without granting new privileges.[8] Its current external-service action boundary also matters: adding those actions means moving to Copilot Studio.[6]

For that bounded pattern, I’d expect relatively little net-new authority. I want the governance process to reflect that. A reusable prompt book shouldn’t inherit the release process for an autonomous worker just because both are called agents.

There is still risk in what people do with the answer. Microsoft’s middle risk tier explicitly includes wrong answers that mislead people or disrupt operations.[1] Existing permissions also remain something to examine; preserving access doesn’t tell you whether that access was appropriate in the first place.

This map is how I keep the different solutions and control boundaries straight.

Thor's framework / Microsoft agent solutions

One ecosystem. Different control boundaries.#

How I organize the builders, experiences, governance, and risk progression.

Scroll across to compare all six categories.

  1. Discover
  2. Inventory
  3. Approve
  4. Monitor
  5. Govern
  6. Lifecycle
  7. Report

Microsoft Agent 365 monitors and governs registered / onboarded agents across supported platforms. [3]

No codeLow codePro code
0

First-party agents#

BuilderMicrosoft

Focus

Microsoft-managed lifecycle & experiences

  • Researcher
  • Analyst
  • Sales
  • Cowork
  • PowerPoint
  • Excel

Governance controls#

Platform-specific

  • Microsoft-managed experience
  • Microsoft-managed lifecycle
  • Built-in security & compliance
  • Limited extensibility
Primary audienceEnd user
Purpose
Personal productivity
Identity
Typically no separate Agent ID
1

Agent Builder#

BuilderUser / team

Focus

Knowledge & retrieval agents (primarily knowledge retrieval)

  • On-behalf user agents
  • Team / shared agents
  • Workflow agents

Governance controls#

Platform-specific

  • Agent sharing controls
  • Creator-managed lifecycle
  • Connector controls
  • Agent ownership
  • User-delegated permissions
Primary audienceUser / team
Purpose
Personal productivity
Identity
No separate Agent ID currently required
2

Copilot Studio#

BuilderMaker / IT

Focus

Enterprise agents & process automation

  • Enterprise agents
  • Team agents
  • Workflow agents
  • Business process
  • Connected systems

Governance controls#

Platform-specific

  • Power Platform governance
  • Managed Environments
  • Connector policies
  • Agent publishing controls
  • ALM: development / test / production
Primary audienceEnterprise organization
Purpose
Personal / business
Identity
Agent ID / legacy app registration
3

Autopilots#

BuilderIndividual user

Focus

Personal AI assistant that learns preferences and acts proactively on your behalf

  • Local agents
  • Proactive assistance & automation
  • Contextual understanding

Governance controls#

Platform-specific

  • User consent & approvals
  • Device compliance
  • Conditional Access
  • Local capability controls
  • Enterprise policy controls
Primary audienceIndividual user
Purpose
Personal / business
Identity
Own agent identity where supported
4

Foundry agents#

BuilderDeveloper

Focus

Custom AI solutions & multi-agent systems

  • Multi-agent systems
  • Industry solutions
  • Custom AI applications

Governance controls#

Platform-specific

  • Azure RBAC
  • Azure policies
  • Network isolation
  • Agent orchestration controls
  • Content safety controls
Primary audienceEnterprise organization
Purpose
Extensibility
Identity
Agent identity depends on runtime
5

External agents#

BuilderPartner / ISV

Focus

Third-party, partner & SaaS agents; ecosystem integration

  • Partner ecosystem agents
  • SaaS / third-party agents
  • Custom external agents

Governance controls#

Platform-specific

  • Agent 365 SDK onboarding
  • Registry sync & discovery
  • Agent inventory & visibility
  • Entra Agent ID when onboarded
  • Policy evaluation & audit
Primary audienceEnterprise organization
Purpose
Extensibility
Identity
Agent identity when onboarded / supported
Personal productivityPersonal / businessExtensibility
Typically no separate Agent IDAgent ID / agent identity where supported

Lower riskMy directional view: expanding capability, integration, and authorityHigher risk

Shared governance foundation Across all six categories#

Identity & access#

  • Entra ID
  • Conditional Access
  • Authentication (MFA)
  • Agent identity where supported

Security#

  • Microsoft Purview
  • DLP policies
  • Sensitivity labels
  • Information protection

Compliance#

  • Audit logs
  • eDiscovery
  • Retention policies
  • Communication Compliance

Operations#

  • Monitoring
  • Lifecycle management
  • Usage analytics
  • Reporting & dashboards

Shared responsibilities, not identical feature coverage. Apply controls where supported. MFA concerns human authentication where applicable; agent and workload identities use their supported authentication controls.

My framework and directional risk judgment, recreated from my original diagram. Categories 0–5 are reference labels, not Microsoft's official risk scores. Authoring methods overlap; actual risk depends on permissions, data, actions, and audience. Agent 365 capabilities vary by platform, onboarding, licensing, and configuration.
Platform and identity notes
  • Agent Builder currently doesn't require its own Entra Agent ID. That does not mean identity or access controls are absent. Connector and workflow entries describe governance boundaries to consider; external-service actions require Copilot Studio. Identity guidance [5] · Agent Builder guidance [6]
  • Autopilots is a useful operating-pattern category in my map, not a mutually exclusive builder platform. Microsoft's documented autopilot integration uses a Foundry hosted agent. Local-agent examples reflect the broader personal-assistant pattern; the controls must be checked for the actual runtime. Foundry integration [7]
  • Foundry supports configuration-driven and code-based agents. Placement toward the pro-code end reflects how I use this map, rather than a platform restriction. Foundry guidance [4]
  • Agent 365 onboarding paths include built-in integration, registry sync in preview, and SDK integration. SDK onboarding is one path for external agents, not a requirement for every integration. Integration guidance [3]

The six categories and risk progression are my framework. Moving right, I’m thinking about expanding capability, connected systems, and authority. The shared governance foundation stays underneath all of it.

The product name is a starting point. Foundry itself supports configuration-driven and code-based agents.[4] I’d still evaluate the actual deployment before assigning risk.

The risk changes when the authority changes#

Microsoft’s Center of Excellence guidance calls the assist-to-execute line its clearest risk signal. It describes three tiers:[1]

  • Individual productivity: named owner, basic monitoring, release checklist, and self-service guardrails.
  • Expert knowledge and internal services: domain validation, knowledge-quality monitoring, formal release review, and accuracy feedback.
  • Business-critical and external-facing: process ownership, SLA monitoring, security and responsible AI review, decision rights, incident response, and quarterly maturity review.

Its citizen, partnered, and professional development zones add guidance on how teams build and manage agents.[2]

The platform notes under my map cover the separate identity, onboarding, and Autopilot implementation details.[5][3][7]

My first questions would be: whose permissions does it use, what can it change, and does a person approve the action?

Those answers tell me more than the agent label does.

Thanks for reading!

Sources#

[1] https://learn.microsoft.com/en-us/agents/center-of-excellence/govern-agents-risk

[2] https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/sec-gov-phase2

[3] https://learn.microsoft.com/en-us/microsoft-agent-365/developer/choose-integration-option

[4] https://learn.microsoft.com/en-us/azure/foundry/agents/overview?view=foundry

[5] https://learn.microsoft.com/en-us/microsoft-copilot-studio/govern-agents-identities-overview

[6] https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/agent-builder

[7] https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agent-365-integration

[8] https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/copilot-studio-experience