Security teams should treat AI agents as a governed runtime, not just another user convenience. Start with visibility into creation, usage, and behavior, then apply controls based on risk, especially for agents that touch sensitive or regulated data. Regularly review permissions, content, and changes so agent sprawl does not become an unmanaged access path.
How business-built AI agents change the governance problem
When business users can create and customize AI agents in Microsoft 365, the security question is no longer just who has access to a document or app. The real issue is that the agent can act with delegated authority, reuse connected data sources, and change behavior as users modify prompts, tools, and permissions. That makes agent governance a runtime control problem, not a one-time approval problem.
Security teams need to govern three moving parts at once: who can create the agent, what the agent can reach, and how much autonomy it has once deployed. If those are handled separately, teams often miss the combined effect. An agent with “reasonable” permissions can still become risky when it is connected to mail, files, calendar, or other business data and then customized by a user who does not understand the blast radius. The practical challenge is not whether the agent is useful, but whether the organisation can explain, review, and revoke its authority quickly enough. In practice, many security teams discover the real exposure only after an agent has already inherited more access than its creator intended.
For agentic risk framing, the OWASP Top 10 for Agentic Applications 2026 is useful because it treats autonomous behaviour, tool use, and privilege as first-class design concerns rather than as afterthoughts.
How to govern the agent lifecycle in practice
Effective governance starts before the agent is published. Teams should maintain an inventory of agents, owners, connected data sources, and the permissions each agent can invoke. That inventory matters because business-built agents often spread through informal use, not through central engineering teams. A security owner needs to know which agents are meant for personal productivity, which are shared across a function, and which are touching regulated or sensitive information.
After inventory comes policy. The useful control pattern is to separate creation rights from data access rights and from action rights. A user may be allowed to build an agent, but the agent should only gain access to approved connectors, scoped workspaces, and tightly defined actions. Where possible, prefer short-lived credentials, explicit consent flows, and reviewable approvals over broad standing permissions. Microsoft’s own governance concepts are best understood alongside the NIST AI Risk Management Framework, which reinforces that AI risk controls should be measured, monitored, and continuously improved rather than treated as a static checklist.
Monitoring should focus on behavior, not just existence. Security teams need logs that show when an agent was created, what connectors were added, what prompts or instructions were changed, and which data sources or actions were actually used. If the platform supports it, review whether the agent has access to email forwarding, file export, external sharing, or write actions that could change data outside the original use case. The NHIMG report on AI agents as a new attack surface is a useful reminder that many organisations already see agents acting beyond intended scope, which makes post-deployment auditing essential.
A practical operating model is to tier agents by risk. Low-risk personal assistants can remain lightly governed, while agents that can read sensitive content, act on behalf of users, or trigger downstream workflows need stronger approval, periodic recertification, and tighter change control. These controls tend to break down when organisations allow unsupervised self-service agent creation across shared tenants because the platform can multiply small permission mistakes into broad, persistent access paths.
One useful field signal comes from research on CoPhish OAuth token theft via Copilot Studio, which shows why token and consent abuse must be part of the governance conversation, not only content safety or prompt hygiene.
Where agent sprawl and over-permissioning create the hardest edge cases
Tighter control over AI agents often increases friction for business users, so teams need to balance usability against the risk of uncontrolled delegation. The hardest cases are not the obvious malicious ones. They are agents that start legitimate, then accrete connectors, broader scopes, or more permissive workflows over time. That is especially true in environments with many department-built automations, because ownership becomes unclear once the original creator changes roles or leaves.
Current guidance suggests treating high-impact agents differently when they can touch customer data, financial records, HR content, or external systems. Those agents should be reviewed like sensitive business applications, not like simple productivity add-ons. The most common mistake is to focus on the user who created the agent and ignore the authority the agent can exercise after creation. In well-governed programs, every material change to the agent is a review event, not just the first approval.
For teams looking at attacker behaviour as well as governance, the Anthropic report on AI-orchestrated cyber espionage is relevant because it highlights how autonomous systems can be used to scale reconnaissance and abuse trusted workflows. That is why security teams should treat policy drift, overbroad consent, and unreviewed connector additions as security events, not just governance nuisances.
Practitioner takeaway: The decisive control question is not whether business users may create agents, but whether every agent can be explained, bounded, and revoked before it becomes a durable access path.
Risk and Threat Considerations
Business-built AI agents introduce a governance and access-risk problem because they can accumulate delegated authority, move data across systems, and continue acting after the original creator has lost context. The exposure is highest when agents can read sensitive content, perform actions, or inherit broad tenant permissions without a strong approval and review model.
Failure mechanism: Risk materialises through permission creep, unreviewed connector additions, consent abuse, and weak visibility into changes. An attacker or careless user can exploit trusted automation by inducing the agent to access data or execute actions beyond the intended scope, especially when tokens, approvals, or write permissions remain active.
Impact: The likely consequence is unauthorised data access, accidental disclosure, workflow manipulation, or a persistent shadow access path that security teams cannot easily audit or revoke.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Agentic Access Control | Agents in M365 need scoped authority and constrained tool use. |
| Recommendation — Restrict agent capabilities to least-privilege actions and approved tools. | ||
| CSA MAESTRO | GOVERN — Governance | This question is about governing AI agents as enterprise assets. |
| Recommendation — Assign ownership, approval, and review for every business-created agent. | ||
| NIST AI RMF | GOVERN — Govern | The topic requires measurable, monitored AI risk governance. |
| Recommendation — Set AI risk policies, accountability, and continuous review for agent use. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Agent permissions and delegated access must be limited and auditable. |
| Recommendation — Limit and audit agent access paths, scopes, and permissions. | ||
| CIS Controls v8 | 6 — Access Control Management | Agent sprawl needs account and privilege management discipline. |
| Recommendation — Inventory, review, and remove unnecessary agent permissions regularly. | ||
Practitioner Guidance
What to prioritise: Classify agents by the sensitivity of the data and actions they can reach, then apply the strongest review cadence to agents that can read, write, or export regulated content.
What to verify: Confirm that every material agent has a named owner, a current business purpose, an approved connector set, and a revocation path that security can use without depending on the original creator.
Common mistake: Treating the initial publish request as the main control point. For this subject, the higher-risk event is often the later change that expands scope, adds a connector, or inherits a new permission set.
What good looks like: Security can answer, for any live agent, who created it, what it can access, what it last changed, and how quickly it can be suspended if its behaviour becomes unacceptable.
Practitioner takeaway: Governance is working only when agent autonomy stays smaller than the organisation’s ability to monitor and reverse it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
