Catalogue › Security and Privacy › ai-identity-and-access-review

AI identity and access review

Reviews the identities an AI solution runs under and the access around it - who can use, edit, share and administer it, agent and service identities, privileged roles, guest access, sign-in controls and what happens when owners leave - and classifies each finding as blocking or advisory with a fix. Use when an agent or AI solution reaches its security gate, when ownership or audience changes, or when nobody knows whose identity an agent uses.

Department

Security and Privacy

Lifecycle

Assure, Launch, Improve

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

m365-agents, copilot-studio, ai-foundry, power-platform, entra, azure

Editions

starter, scale, enterprise

Reviewers

security-privacy

Status

draft

Copilot Cowork

Security and Privacy plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Every AI solution acts as someone. It answers as the signed-in user, calls systems as a maker, a service principal or an agent identity, and is edited, shared and administered by people who may change role or leave. This reviewer skill examines those identities and the access wrapped around the solution, and classifies each finding as blocking or advisory with a specific fix. Reviews go wrong when they check the agent's knowledge and connectors in detail but never ask who can change the agent itself, so a well-reviewed solution is quietly rewritten or widened by an account nobody is watching.

When to use

• An agent or AI solution at risk tier 2 or above reaches its security-privacy gate.
• The solution uses a service principal, managed identity, agent identity or shared account.
• Ownership, co-authors or administrators change, or an owner leaves the organisation.
• The audience is about to include guests, partners or customers.
• An incident or audit cannot establish whose identity performed an action.

When not to use

• Reviewing each connector, action, tool or MCP server and its authentication mode - use security-privacy:connector-review.
• Reviewing what content the solution can reach and reveal - use security-privacy:data-exposure-review.
• Designing the identity architecture for users, agents and services - use ai-architecture:ai-identity-design.
• Implementing secrets, managed identities and least privilege in code - use ai-engineering:secrets-and-identity.
• Setting the estate-wide rules for which identities may reach which data - use data-governance:ai-data-access-model.

Questions to ask first

1. Whose identity does the solution use for each thing it does - answering, reading data, writing data, calling external services?
2. Who can use it, who can edit its instructions, knowledge and actions, who can share or publish it, and who administers its environment or resource?
3. Are any of those identities privileged, shared, non-human or external, and is each one owned by a named role?
4. What controls apply at sign-in - conditional access, device and location conditions, multifactor authentication - and do they apply to every channel the solution is published to?
5. What happens to access when an owner, co-author or maker changes role or leaves?

Required inputs

• The agent brief or solution design, with audience, channels, risk tier and owners.
• An identity map: every human and non-human identity involved, its purpose and its permissions.
• Role and membership exports for the agent, its environment or resource group, and any security groups used for sharing.
• Findings from security-privacy:connector-review, so per-connector authentication is not reviewed twice.

An identity nobody can explain is itself a finding: blocking from tier 2. Never infer an identity's permissions from its name or from the maker's recollection; ask for the export.

Decision framework

Classify every finding. From risk tier 2 a blocking finding stops release and is not traded against dates; below tier 2 the review is advisory, but a finding that would be blocking means the tier needs re-checking.

Each finding names the risk, the standard behind it, the fix and an owner. Disagreement escalates to the accountable executive through responsible-ai:ai-risk-acceptance, recorded in writing with a review date.

Practitioner approach

Begin by drawing the identity map before reading any configuration. List every action the solution takes and write beside it the identity that performs it. Makers often cannot fill in this table, and that is the first useful finding: a solution whose builders do not know whose identity it uses cannot be reviewed for least privilege.

Then look for the borrowed identity. The most common serious pattern is a solution built and tested under the maker's own account, then shared, so every user inherits the maker's rights to a connection, a data source or an API. Connector review catches this per connection; this review checks the whole solution, including flows, scheduled triggers, Foundry resources and any automation that runs when nobody is signed in.

Next, review who can change the solution, not only who can use it. Export the owners, co-authors and environment or resource roles and compare them with the owning team in the brief. For tier 2 and above, the people who can edit instructions, add knowledge or attach actions should be few, named and accountable, and production changes should pass through the organisation's release route rather than direct editing. Check that environment administrators and Azure resource owners are not standing, shared or personal accounts held by makers.

Non-human identities need the same discipline as people. For each service principal, managed identity or agent identity, confirm an owner role, the exact permissions granted, how credentials are stored and rotated, and when access is next reviewed. Identities created for a pilot and never removed are a recurring source of exposure.

Check sign-in controls channel by channel. A solution published to Teams, a website and a mobile app may meet the organisation's conditional access expectations in one channel and not another. Where guests or external users are in scope, confirm that this was a design decision and that external sign-in controls were tested.

Finally, follow the leaver path. Ask what happens if the owner leaves tomorrow: who inherits the solution, whether connections stop working or keep running under a disabled account, and whether the solution appears in access reviews. Product capabilities for ownership transfer, agent identities and access reviews change often, so confirm current behaviour in the source records and record what was checked.

Write the findings proportionately. A team agent using delegated access and a three-person author list may need one advisory finding. Close the review only when blocking fixes are evidenced, and re-review when owners, channels or audience change.

Outputs

• The identity and access findings in the ai-risk-assessment: the identity map, the edit and administer list, findings classified blocking or advisory with risk, fix, owner and date, and the verdict.
• A list of non-human identities with owners and review dates, handed to the solution owner and the platform team.
• Any written risk acceptance from the accountable executive.

Microsoft platform considerations

Identities differ by route: agents built in Agent Builder, Copilot Studio agents in Power Platform environments, and Foundry solutions in Azure each have their own sharing, authoring and administration model, and Microsoft Entra provides the identity, conditional access and access review capabilities around them. How agent identities are represented, which channels honour which sign-in controls, and what Managed Environments add are volatile; confirm them in ms-copilot-studio-security-governance, ms-managed-environments and ms-agent-builder before relying on them.

Adoption considerations

Makers experience identity findings as friction because their solution worked under their own account. Explain the borrowed-identity risk with a concrete example from their solution, and offer the approved pattern rather than only the rejection.

Knowledge considerations

Not applicable as a primary concern, because content access is reviewed in security-privacy:data-exposure-review. Note here only where knowledge is reached through a non-human identity rather than the user's own permissions.

Security and privacy considerations

This skill is the security review of identity and access. Findings about connector authentication go to security-privacy:connector-review; findings about content reach go to security-privacy:data-exposure-review.

Responsible AI considerations

Accountability depends on attribution. If actions cannot be traced to an identity and an owning role, people affected by the solution cannot get a clear answer about who acted. Flag such gaps to responsible-ai:human-oversight.

Evaluation requirements

Blocking fixes need evidence: a fresh role export, a test showing a user without rights cannot perform an action, or a sign-in log showing the expected controls applied in each channel. Advisory findings need an owner and a date.

Value measures

Track at portfolio level the share of tier 2+ solutions with a complete identity map, the number of non-human identities without an owner, and time to close blocking identity findings. The security and privacy lead owns these measures, with baselines taken at the first review cycle.

Scale notes

Starter

Draw the identity map with the maker in one session and check owners, co-authors and sharing in the product's own settings. Prefer delegated access so the review stays short.

Scale

Make the identity map a mandatory part of the release checklist and add AI solutions and their non-human identities to the regular access review cycle.

Enterprise

Federate tier 2 reviews to trained business-unit reviewers using the same criteria, with the central team taking tier 3 and 4, and reconcile non-human identities against the solution inventory every review cycle.

Hand-offs

• To security-privacy:connector-review for per-connector authentication findings.
• To ai-architecture:ai-identity-design where the identity pattern itself needs redesign.
• To m365-agents:agent-release-readiness with the verdict.
• To security-privacy:ai-incident-readiness with the identity map, which responders need to contain an incident.

Reviewer gates

This skill is the security-privacy gate for identity and access. It applies as a blocking gate from risk tier 2 and as an advisory check below it. Blocking findings stop release and are not traded against dates; disagreement escalates to the accountable executive for written risk acceptance.

Failure modes

• The review checks who can use the agent but not who can edit it, and an unreviewed co-author later widens its scope.
• A service identity created for a pilot keeps broad permissions long after the pilot ends.
• Conditional access is verified in Teams but the same agent is also published to a channel that bypasses it.
• The owner leaves, connections keep running under a disabled account, and nobody notices until something fails.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Pass a tier 2 or higher solution whose runtime identities cannot be explained.
• Accept a maker's personal or privileged credentials as the identity of a shared solution.
• Leave a non-human identity without an owner and a review date.
• Trade a blocking finding against a launch date.