AI Agent Access Reviews After Permission Creep

Agentic Business Design

19 July 2026 | By Ashley Marshall

AI agents do not create permission creep from nowhere. They expose the access debt that Microsoft 365, CRM and finance workflows have been carrying for years.

Permission Creep Is Now An Agent Risk

Most access reviews still assume that the risk sits with a person clicking around a system. That assumption is getting thin. A sales operations agent that can search SharePoint, summarise Teams discussions, update Dynamics records and prepare an invoice does not need malicious intent to become dangerous. It only needs inherited access that nobody has checked since the workflow was built.

The UK evidence base is blunt enough. The Cyber Security Breaches Survey 2025 found that 43% of UK businesses identified a cyber breach or attack in the previous 12 months, rising to 67% of medium businesses and 74% of large businesses. The same survey found that only 40% of businesses had two-factor authentication in place and only 30% used user monitoring. That matters because agent access reviews are not a theoretical AI governance activity. They sit directly inside ordinary cyber hygiene.

The access problem is also no longer just about privileged administrators. NCSC guidance says organisations should know who or what needs access, why and under what circumstances, and should review accounts for unnecessary privileges regularly. In agent workflows, the words who or what become important. The actor might be a licensed user, an enterprise application, a custom connector, a workflow identity, a service account or a delegated OAuth token.

The operating model needs to reflect that mix. Start by naming every agent-assisted workflow and assigning three owners: a business process owner, a system owner and an access owner. The access owner should maintain a review pack that shows what the agent can see, what it can change, which human account or app registration it uses, which approvals it can initiate, which logs prove activity, and when exceptions expire. If those facts cannot be produced quickly, the business does not have an AI agent access model. It has a collection of permissions with a conversational front end.

Microsoft 365 Agents Inherit Your Existing Mess

The common misconception is that Microsoft 365 Copilot or an internal agent creates a new tenant-wide data leak. Microsoft's own architecture documentation says the opposite: Copilot access is scoped to the signed-in user's permissions and it cannot access data the user does not have permission to access. That is reassuring, but it is not a control by itself. If a user already has access to old board papers, HR folders, historic deal rooms, abandoned Teams channels and finance exports, an agent can make that over-permissioned estate far easier to search and combine.

Microsoft's Copilot privacy and security documentation is clear that Copilot uses content in Microsoft Graph such as emails, chats and documents that the user has permission to access. It also notes that admins can view permissions and data access required by agents in the Integrated apps section of the Microsoft 365 admin centre. Microsoft Entra's access reviews guidance goes further: excessive access rights can lead to compromises and audit findings, and reviews can cover group memberships, enterprise applications, role assignments and access packages.

For Microsoft 365, the access review should not be a once-a-year spreadsheet. A practical rhythm is monthly for high-risk agent workflows, quarterly for ordinary productivity agents and event-driven reviews when a workflow changes. Review SharePoint sites exposed through Microsoft Graph, Teams and Microsoft 365 group membership, Entra enterprise apps, admin consent, delegated permissions, guest access, service principals, Power Automate connections and Purview labels. The review question is not simply can this agent use Copilot. It is which user, group, app and document permissions will shape the answer it gives and the action it takes.

In practice, this creates a new job for operations leaders: access attestation in business language. Instead of asking a manager to approve a list of cryptic group names, ask them to confirm that the agent supporting sales proposals still needs access to the proposal library, the approved pricing sheet, the CRM opportunity entity and the finance quote template. If they cannot explain the business need, remove or narrow the access.

CRM Permissions Accumulate Quietly

CRM is where permission creep often becomes commercially sensitive rather than just administratively untidy. Sales, service and customer success teams accumulate role changes, territory moves, temporary cover, agency support, integrations and reporting exceptions. An AI agent layered on top of that environment can summarise account history, prepare renewal notes, draft customer emails or update next steps. Useful, certainly. But if the underlying CRM role design has drifted, the agent can also surface restricted accounts, sensitive notes, personal data, complaint history or pipeline information to people who no longer need it.

Microsoft's Dataverse documentation is unusually plain on this point. Dataverse uses role-based security, but privilege grants are accumulative and the greatest amount of access prevails. It gives the example that if broad organisation-level read access is granted to all contact records, you cannot then hide a single record. Dynamics 365 security role guidance makes the same point: each user can have multiple security roles and security role privileges are cumulative. This is exactly how operational shortcuts become long-term risk.

Agent access reviews in CRM should therefore include two layers. The first is ordinary role hygiene: business units, teams, security roles, field security profiles, record sharing, owner teams, access teams and integration users. The second is agent capability: read, create, write, assign, share, append, approve, enrich, export and trigger. A customer service summary agent might need read access to cases and contact preferences, but not delete, assign or export rights. A revenue operations agent might need opportunity fields and product catalogue data, but not unrestricted access to complaints, employment notes or dormant customer records.

The operating model should make CRM role changes visible to process owners before they become agent permissions. Create an access matrix by workflow, not just by department. For example: lead triage, renewal preparation, complaint escalation, quote generation and customer onboarding. For each workflow, list the agent, the human role it supports, the CRM entities it touches, the permitted actions and the evidence required. Then run a quarterly exception meeting that removes shared records, temporary teams and old integration accounts. CRM teams dislike this work because it feels like housekeeping. With agents, it becomes a revenue protection control.

Finance Workflows Need Scope Reviews, Not Trust

Finance workflows deserve a separate review because the consequences of small permission mistakes are immediate. An agent that can read supplier records, draft payment runs, reconcile invoices, chase debts or prepare management accounts is connected to decisions that move money and expose sensitive personal or commercial data. The mistake is to treat the finance platform as a black box and focus only on who can open the AI tool.

Xero's OAuth scope guidance is a useful example of how finance access creeps. Xero says apps should request the minimum scopes required for the action being performed. It also says that each later OAuth flow adds new scopes to previously consented scopes, and that it is not possible to remove scopes from an existing access token. The only way to reduce consented scopes is to revoke the token and start again. That is a precise description of permission creep in a finance workflow: small additions become persistent authority unless someone actively removes them.

The scope review should cover people, apps and process controls. For people, check who can approve suppliers, edit bank details, raise purchase orders, approve invoices, create manual journals, run payroll reports and export attachments. For apps, list every connected integration, custom connector, refresh token and automation account. For the process, map where the AI agent is allowed to recommend, draft, update, approve or execute. The most important control is separation of duties. A finance agent may prepare a supplier payment file, but a different human role should approve the payment and a separate notification should alert finance leadership when bank details change.

UK leaders should also connect this to cyber-facilitated fraud. DSIT estimated that 3% of all businesses experienced fraud resulting from a cyber breach or attack in the last 12 months, equating to around 40,000 businesses, with an estimated mean average cost per business of £5,900 including zero responses. An agent does not need payment authority to amplify fraud risk. It may only need enough access to make a spoofed request more convincing, find the right approver or draft a clean supplier change email. Access reviews should test those pathways before a real attacker does.

The Review Pack Boards Should Ask For

The right access review pack is short enough to run every month and detailed enough to satisfy audit, security and business owners. It should not be an AI ethics document. It should be an operational control pack for workflows where an agent can access, transform or trigger business data. Boards and senior leaders do not need to inspect every permission. They do need evidence that the organisation knows where agent authority starts, where it stops and who can change it.

NCSC's identity and access management guidance says policies should cover who should have access to which systems, data or functionality, why and under what circumstances. It also says audit records should be acquired and safeguarded against tampering, and that account management should include joiners, movers and leavers. The same guidance highlights third-party access, temporary accounts and regular review of unnecessary privileges. Its logging and monitoring guidance recommends storing the most important logs for at least 6 months because incidents can take months to detect. Those points translate neatly into an agent access review pack.

A practical pack has six pages or dashboards. First, a workflow register: agent name, purpose, owner, systems connected and current risk tier. Second, an identity register: users, service accounts, app registrations, OAuth clients, groups and guests used by the workflow. Third, a permission map: read, write, approve, export, delete and execute rights by system. Fourth, an exception list: temporary access, policy exemptions, break-glass accounts and expiry dates. Fifth, a log and monitoring summary: sign-ins, consent changes, privileged actions, failed MFA, unusual geography, high-volume exports and approval overrides. Sixth, a decision log: approvals, removals, compensating controls and unresolved risks.

The operating cadence matters. Weekly security review is excessive for many SMEs, but monthly review of high-risk agent workflows is not. Finance payment flows, HR data workflows, customer complaint handling and board pack search should sit in the monthly tier. Lower-risk agents that summarise public collateral or draft internal updates can be reviewed quarterly. Any agent that gains a new connector, new OAuth scope, new CRM entity or new finance permission should trigger an out-of-cycle review.

The Counterargument Is Half Right

The strongest counterargument is that all of this slows adoption. If Microsoft 365 Copilot honours existing permissions, Dataverse already has role-based security, finance platforms already use OAuth scopes and people already approve payments, why add another access process? The answer is that the counterargument is half right. You should not create a parallel governance theatre around AI agents. You should reuse the controls you already pay for, but tune them to the way agents actually operate.

Access reviews fail when they ask abstract questions. They work when they sit inside normal operating meetings. The sales operations meeting should review CRM agent exceptions. The finance controls meeting should review payment and supplier workflow permissions. The Microsoft 365 platform owner should review enterprise applications, admin consent, guest access and high-risk SharePoint sites. Security should own the evidence standard and monitoring thresholds, but business owners should approve business need. That split keeps the review practical and stops it becoming a central bottleneck.

The ICO's AI and data protection guidance is helpful here because it frames AI through accountability, governance, transparency, lawfulness, fairness and lifecycle considerations. For an access review, accountability means being able to explain why the agent had access to a dataset at the time it used it. Transparency means knowing whether a decision or recommendation was shaped by data from Microsoft 365, CRM, finance or a connected app. Lawfulness and fairness are hard to defend if old permissions allow an agent to process personal data that the workflow no longer needs.

The practical answer is not to block agents until every permission is perfect. That will never happen. Start with the workflows where the agent can influence money, customers, staff or regulatory reporting. Remove stale access, narrow broad roles, revoke old tokens, document exceptions and monitor the actions that matter. Then repeat. Permission creep is not fixed once. It is managed as part of how the business changes.

Frequently Asked Questions

What is permission creep in an AI agent workflow?

Permission creep is the gradual accumulation of access that no longer matches a current business need. In an AI agent workflow, it includes user permissions, app permissions, OAuth scopes, service accounts, CRM roles, shared records and finance approval rights that the agent can inherit or use.

Does Microsoft 365 Copilot ignore existing permissions?

No. Microsoft states that Copilot accesses data according to the signed-in user's permissions and does not access data the user is not authorised to access. That makes the quality of the underlying Microsoft 365 permission model critical.

How often should AI agent access reviews happen?

High-risk workflows such as finance payments, HR data, board information, customer complaints and regulated reporting should be reviewed monthly. Lower-risk drafting or research agents can usually be reviewed quarterly, with out-of-cycle reviews when connectors, scopes or permissions change.

Who should own AI agent access reviews?

Ownership should be split. The business process owner confirms business need, the system owner confirms technical permissions, and security or compliance owns the evidence standard, exception process and monitoring requirements.

What should be reviewed in Microsoft 365?

Review SharePoint and Teams access, Microsoft 365 groups, guest users, Entra enterprise applications, admin consent, delegated and application permissions, service principals, Power Automate connections, Purview labels and Conditional Access coverage.

What should be reviewed in CRM?

Review security roles, business units, teams, field security profiles, record sharing, integration users, owner teams, access teams and whether the agent can read, write, assign, share, export or trigger updates across customer data.

Why are finance integrations a special risk?

Finance integrations often rely on OAuth scopes, refresh tokens and connected apps that persist over time. If broad scopes or old tokens remain in place, an agent-assisted workflow may retain access to invoices, bank transactions, payroll data or supplier records beyond the current business need.

Is the answer to block AI agents until permissions are perfect?

No. The practical answer is to prioritise workflows where agents affect money, customers, staff or regulated data, then narrow access, document exceptions and monitor activity. Perfect permissions are unlikely, but unmanaged permission creep is avoidable.