Why AI Adoption Creates a New Access-Control Problem

Observable condition

An AI assistant starts by answering questions. Then it is connected to documents. Later it can create tickets, update records, send messages or call APIs. The capability expands faster than the access model around it.

The organisation may know which employee requested the agent, but not which identity the agent uses, exactly what it can access, which actions it can perform, who owns it after the original sponsor changes roles, or how to revoke its access cleanly.

In a mid-sized business this rarely looks dramatic. A finance administrator connects an assistant to the shared drive to summarise supplier contracts. A sales lead connects another to the CRM using their own login so it can draft follow-ups. An operations manager builds a low-code flow that lets a bot update stock levels. Each decision is reasonable on its own. Together they create several non-human actors with real access and no shared rules.

Realisation

The security question changes once AI can act. A model that only produces text has a different risk profile from an agent that can read customer records, modify systems or trigger business processes.

Microsoft's 2026 Cyber Pulse report explicitly argues that organisations should treat agents like people and apply Zero Trust principles: least-privilege access, explicit verification and an assumption that compromise will happen. It warns that agents with excessive access or poor instructions can become unintended "double agents". Microsoft Learn's guidance on least privilege for AI agents similarly frames least privilege, scoped tool access, auditability and revocation as design requirements, to be defined before autonomy expands.

Realisation prompt: for every agent that can act, can you answer who owns it, what identity it uses, what it can read, what it can change, and how you would stop it?

Identification

This is an agent identity, least-privilege access and lifecycle-governance problem. The visible condition is AI adoption. The structural issue is that non-human actors are entering workflows that were historically governed around people and conventional applications.

Most businesses already have some discipline for people: joiners get accounts, leavers lose them, and senior roles get more access than junior ones. Agents slip between those processes because they are neither employees nor traditional applications. They are created by individuals, often inside tools the IT function does not administer, and they persist after the person who created them has moved on.

Diagnosis

Risk grows when agents inherit broad user permissions, use long-lived shared credentials, can call more tools than their task requires, or are deployed without clear owners and audit trails.

Agentic systems can chain actions across multiple services. That makes the permission boundary more important, not less. An apparently harmless starting action can become consequential when combined with downstream access. The Microsoft Learn guidance names the specific failure modes:

Identity ambiguity: agents running under shared secrets or mixed "on behalf of user" modes, so it is unclear who is responsible for an action.
Permission creep: broad roles granted to unblock a pilot and never narrowed once the workflow stabilises.
Over-broad tool access: an agent able to invoke any available tool, so a single prompt injection or workflow bug can trigger export, delete or privilege changes.
Weak audit trails: logs that capture the chat response but not the underlying tool actions.
Slow revocation: disabling an agent is incomplete because tokens persist or keys are shared.

The second of these is common enough to have its own discovery note: agent permissions broader than the task requires. The first often starts with an automation built on someone's personal account, which is why automations should not run on personal credentials.

A worked example

A 90-person financial advisory practice deploys an assistant that summarises client files for advisers. To get it working quickly, it is connected with a service account that has read access to the entire document store, including HR files and partner remuneration. Six months later the assistant gains a feature that lets it email summaries. Nobody revisits the access. The assistant can now, in principle, read any document in the business and send its contents by email. No one designed that capability. It emerged from two reasonable decisions taken months apart.

Commercial impact

The commercial value lies in risk, resilience, governance and scalability. Weak access design can expose sensitive data, create unauthorised changes, make investigations harder and prevent the organisation from confidently expanding agent use. For South African businesses handling personal information, uncontrolled agent access also makes it harder to show that personal data is processed only for defined purposes.

Good governance is therefore not only a control cost. It is an enabler. Organisations can scale useful automation faster when identity, permissions, ownership and logging are standardised rather than reinvented for every agent. The financial side of this exposure is covered in uncontrolled AI access to company data.

Common misidentification

A common mistake is to treat an agent as a feature inside a chatbot, or to give it the same access as the human who created it. Another is to focus mainly on prompt safety while overlooking the permissions attached to tools and data.

The more useful an agent becomes, the more important its execution authority becomes. A well-written system prompt cannot stop an agent doing something its credentials allow. Only the permission boundary can.

Possibility

A better state gives each material agent a known identity, sponsor and lifecycle. Permissions are scoped to the minimum data and actions required. Read and write capabilities are separated where appropriate. High-impact actions can require policy checks or human approval. Logs make actions traceable, and access can be revoked without dismantling the entire workflow.

Identity platforms are beginning to support this directly. Microsoft Entra Agent ID, for example, provides agent identities with named owners and sponsors, lifecycle governance, access packages and Conditional Access for agents. The specific product matters less than the principle: agents should be first-class identities, governed like any other.

Trade-offs

Microsoft's guidance is candid about the costs. Task-based roles and tool allowlists take more design effort than granting broad access. Access reviews and revocation testing are ongoing work. Approval steps slow down high-impact actions. For a smaller business, the sensible response is proportion: tight controls on agents that touch money, personal data or customer communications, and lighter ones on agents that only summarise internal, non-sensitive material.

Intervention

Inventory agents and the systems they can reach. Classify their actions by impact, define owners, replace shared credentials with managed identities where appropriate, apply least privilege, allowlist tools, and test revocation and logging.

Governance should be designed into the workflow before autonomy expands, not added after the agent becomes business-critical. Visibility is the first step, because you cannot govern agents you cannot see, the condition described in when AI agents can act but governance cannot see them.

What to do first

Ask each department head to list every AI assistant, bot or automated flow their team uses that connects to business data.
For each, record the owner, the identity it runs under and the systems it can reach.
Flag any running on a personal login or a shared account, and any with write access.
Remove write access that is not needed for the stated purpose.
Add agents to your leaver process, so that a departing owner triggers a handover or shutdown. The same discipline applies to people, as shown in when offboarding leaves digital access behind.
Test switching off one agent and confirm its access really stops.

Practical diagnostic questions

Does every production agent have a named owner or sponsor?
Does it use its own identity or inherit a broad human identity?
Can it perform write actions that are unnecessary for its purpose?
Are tool calls and downstream actions auditable?
Can access be revoked quickly if the agent behaves unexpectedly?
What happens to the agent when its owner leaves or changes roles?

Bottom line

AI adoption creates a new access-control problem because capable agents are becoming participants in business processes. Organisations that recognise this early can design identity and governance as infrastructure for scale, rather than discovering the problem after autonomy has already spread. Ongoing oversight matters as much as initial design, which is the subject of who watches the automations?

Sources and further reading

Microsoft Cyber Pulse — Navigating cyber risk in the agent era (last verified 10 October 2026)
Microsoft Learn — Least privilege for AI agents (last verified 10 October 2026)
Microsoft Entra Agent ID documentation (last verified 10 October 2026)