Microsoft 365 agents can make enterprise information and business actions easier to reach, but they do not remove the need for identity architecture. They make it more visible. Every useful agent depends on a chain of trust: the user must be authenticated, the user must be entitled to the agent, the agent must be allowed to use its data sources and tools, and every downstream system must enforce its own authorization. The current AB-900 scope places agent administration beside Microsoft 365 identity, security, and governance for exactly this reason.
The central design rule is to avoid treating “agent access” as a single permission. There is access to discover the agent, access to invoke it, access to the content it can ground on, and access to any action it can perform. Those layers should reinforce each other. A user should not gain data or transaction authority merely because an agent creates a convenient conversational interface.
Keep the user identity as the primary security context
In most enterprise scenarios, the safest starting point is that an agent should respect the permissions of the signed-in user. If a person cannot open a SharePoint document or reach a protected application directly, the agent should not become a back door to that resource. This keeps AI access aligned with the organization’s established authorization model.
That principle also helps with auditability. When actions are performed in a user context, investigators can relate the activity to a known identity and existing access decisions. A shared service identity that performs everything with broad permission may be easier to build, but it can erase accountability and greatly expand the impact of a compromise.
The broader identity model in SC-300 is therefore foundational. Agent security begins with users, groups, authentication methods, application access, workload identities, and governance—not with the chat window.
Separate access to the agent from access to its data
Publishing an agent to a user does not mean every data source behind the agent should become visible. The agent’s audience and the resource permissions are two different control planes. Administrators should verify that the underlying repository, application, or API still performs its own authorization.
This is especially important with Microsoft 365 content. Copilot and agents can use content that the user is already allowed to access, which means an old SharePoint permission or inherited group membership can become easier to exploit accidentally. The correct fix is to repair the source access, not to hope the agent’s prompt instructions hide sensitive information.
Use groups and role-based assignment to make access explainable. The basic principle behind dynamic access control applies even when the implementation differs: access decisions should be based on meaningful identity and resource attributes rather than ad hoc exceptions.
Protect the sign-in path with stronger authentication
An agent can concentrate access to many business resources into one interface, so account takeover becomes more valuable to an attacker. Strong authentication should be part of the deployment model. MFA reduces dependence on a password alone, but high-risk roles should move toward phishing-resistant methods where possible.
Administrators also need to distinguish user authentication from application or workload authentication. A person might sign in with passkeys or another strong method while the agent connects to a downstream API with a separate workload identity. Both contexts need appropriate credentials, lifecycle controls, and monitoring.
For organizations still building their baseline, multifactor authentication is a useful starting point, but the target should be an identity architecture that can resist modern phishing and token theft rather than simply adding one more prompt.
Use least privilege for agent administrators and publishers
Administrative roles that can approve agents, change tenant-wide settings, or grant consent are sensitive. Do not make every agent operator a Global Administrator. Use the least-privileged Microsoft 365 and Microsoft Entra roles that support the required task, and separate business approval from technical administration when that improves control.
Publishing authority is also a privilege. A user who can create an agent for personal use is not automatically the right person to publish it across the company. Organization-wide publication can create new data-discovery and action paths, so approval should include security and ownership checks.
Track role assignments and review them periodically. Agent administration is a fast-moving area, and temporary project privileges can become permanent if there is no revalidation process. Privilege should be an entitlement with an owner and expiration logic, not an informal status.
Review application permissions and delegated consent carefully
Some agents use tools, connectors, plugins, APIs, or other integrations. Those components can require application permissions or delegated permissions. Administrators should evaluate the requested scope, the resource being accessed, whether user consent is appropriate, and whether tenant-wide admin consent would create excessive reach.
A permission with a broad name can hide a large blast radius. Before approving it, ask which operation requires that scope and whether a narrower permission would work. For delegated access, remember that the application acts within the user’s permissions. For application permissions, the workload can act without an interactive user, which can be significantly more powerful.
The architectural mindset from SC-100 is useful here: trust is established across identities, applications, data, and monitoring. No single approval should be viewed in isolation from the systems it connects.
Design external and guest access deliberately
Agents used in collaborative environments can surface questions about guest users, external partners, and cross-tenant sharing. If an external identity can access a site, team, or application, the agent may be able to help that user find permitted content more efficiently. That can be entirely legitimate, but it makes stale guest access more consequential.
Use Microsoft Entra external collaboration controls, Conditional Access, group membership, and access reviews to keep those relationships current. A project partner should not retain access years after the engagement ends simply because nobody revisited the guest account.
Do not create a separate set of identity exceptions just for agents unless the business requirement truly demands it. Reusing the same collaboration boundary across direct access and agent-mediated access creates a simpler model to audit and explain.
Give agent tools their own security review
An agent that only summarizes permitted content has a different risk profile from an agent that can send messages, create records, submit transactions, or call remote tools. Tool access should therefore be reviewed as a distinct capability. Identify what the tool can do, how it authenticates, what data leaves Microsoft 365, and whether actions are reversible.
For high-impact actions, consider approval steps, confirmation prompts, scoped permissions, and transaction limits. The conversational interface should not hide the seriousness of the underlying operation. “Create a purchase request” may look like one chat instruction while still triggering a business process with financial consequences.
Maintain an inventory of approved tools and owners. If a connector or remote service is no longer supported, remove it rather than leaving a dormant integration with credentials and permissions. Tool governance is part of the agent lifecycle.
Agent identity design should also consider what happens when the user is absent. Some background or scheduled scenarios need a workload identity rather than delegated user context. That can be legitimate, but it changes the risk model because the workload may continue operating when no user is present. Give that identity only the permissions required for the task, prefer managed or federated credentials where supported, and avoid long-lived secrets that are copied into configuration.
Where an agent performs actions on behalf of a user, preserve enough context to distinguish “the user requested this” from “the service executed this.” Audit records, correlation identifiers, and downstream application logs should make the chain reconstructable. Otherwise an organization may know that an API call occurred without being able to prove which user interaction caused it.
High-risk tools should also define transaction boundaries. An agent that can read a ticket is different from one that can close it; an agent that drafts an email is different from one that sends it. Separate read, propose, approve, and execute permissions when possible. That design lets the organization introduce useful assistance before granting autonomous authority.
Monitor identity events that change the agent’s effective reach
Agent risk can change even when the agent itself does not. A user might join a privileged group, a site might become broadly shared, an application might receive new permissions, or an administrator might approve a more powerful tool. Monitoring should therefore include identity and resource changes, not only agent usage.
Use sign-in, audit, provisioning, and administrative logs to investigate unusual behavior. If an agent suddenly reaches data it never accessed before, determine whether the cause was an agent update or an access change somewhere else in the chain. Good observability preserves those relationships.
Single sign-on can simplify the user experience, but convenience does not replace authorization. The concepts in single sign-on help explain why a user can move smoothly between services while each application still needs its own access decision.
Recovery planning should include compromised agents and compromised owners. If an agent begins behaving unexpectedly, administrators need to know how to block or remove it quickly, revoke related credentials, and identify users who interacted with it. If the only owner leaves the organization, ownership should transfer before the account is disabled. Agent lifecycle controls and identity lifecycle controls therefore need to exchange information.
For sensitive agents, maintain a minimal dependency record: owner, publisher, audience, data sources, tools, permissions, billing model, and emergency disable procedure. This is not heavy documentation. It is the information an incident responder needs when a normal conversational interface becomes part of a security investigation.
Privileged agent scenarios should also avoid collapsing approval and execution into one person where separation of duties matters. A developer can build an agent, a business owner can validate its purpose, a security reviewer can assess permissions, and an administrator can publish it. Small teams may combine roles, but the decision trail should still show which questions were considered before broad access was granted.
Make ownership and periodic review part of the access model
Every production agent should have named owners who can answer why it exists, which users need it, which data and tools it depends on, and what happens if it is compromised. Ownership is an access-control mechanism because it creates accountability for permissions that would otherwise persist indefinitely.
Review agents on a schedule proportional to risk. High-impact agents that can take actions or reach sensitive data deserve more frequent review than a low-risk information assistant. Reconfirm audience, data sources, tools, administrator roles, and business purpose. Remove agents whose purpose has disappeared.
The goal is not to create friction around every AI interaction. It is to preserve the same security properties the organization expects from its applications: strong identity, explicit authorization, least privilege, accountable administration, auditable activity, and a reliable way to withdraw access. When those properties remain intact, agents can improve user experience without becoming a parallel identity system.