AI agents are now internal users: Microsoft proposes identity, permissions and containment
An agent that checks invoices, approves expenses or updates inventory is more than a tool: it has access, makes decisions and affects real systems. Microsoft proposes treating it as a new kind of internal user, with its own identity and authority that can be reduced or withdrawn while it works.
01
Risk does not start only when someone attacks an agent
On 19 October 2026, Microsoft announced an expansion of Project Perception aimed at agents already operating inside organisations. The company describes them as internal agents: systems that access data, applications, tools and other agents to carry out business tasks.
The idea does not assume that a model is malicious. The more ordinary problem is that it can make a mistake, receive a manipulated instruction, change its plan after finding new information or inherit permissions that are too broad. An agent that starts by checking an invoice might try to alter a resource it never needed for that task.
That is why Microsoft proposes separating intelligence from authority. A model can propose and reason, but the rules for what it may read, write, approve or call should sit outside the model, in a layer it cannot disable or bypass.
02
Each agent needs an identity separate from its user
The first condition for controlling an agent is knowing that it exists, who owns it and why it was created. Microsoft says its systems will be able to discover 60 types of local agents, including Claude Code, OpenAI Codex and GitHub Copilot, and add them to a shared registry.
Microsoft Entra Agent ID then gives each agent an identity separate from the human account sponsoring it. That separation makes actions attributable, gives the agent a lifecycle and prevents it from automatically inheriting all of an employee’s privileges.
The principle matters even to a small business without a complex security platform. A reconciliation automation should not use the same credentials the owner uses for banking, email and storage. Its account should be limited to the specific documents, periods and operations it needs.
03
Time-limited permissions matched to a task
Microsoft introduces Dynamic Permissions to tie an agent’s authority to a particular task and period. The organisation’s policy sets the maximum boundary; within it, the agent receives only the permissions it needs and loses them when the job ends or the context changes.
This replaces permanent access with progressive authorisation. Reading an invoice folder may be allowed; recording a proposed reconciliation may need an extra check; making a payment should be outside the agent’s scope or require verifiable human approval.
The same logic applies to inventory, bookings, purchasing, support and audiovisual production. Not every step has the same impact: looking up, proposing, changing and committing resources should be distinct levels of authority.
04
A permission that was safe at the start may not be safe later
A traditional access control checks who is entering and what permission they have. An agent may need something more dynamic because its risk changes during execution. It might read an external document containing a prompt injection, drift from its objective or try to connect an unapproved tool.
Dynamic Agent Risk combines signals about identity, data, network, cloud, device, runtime environment and agent activity. Dynamic Conditional Access uses that risk to respond gradually: allow reading but block writing, reduce accessible resources, require approval, isolate the environment or stop execution.
This avoids two unhelpful extremes: trusting the agent until an incident happens, or shutting down all automation at the first anomaly. Containment can match the severity while preserving safe functions.
05
An architecture businesses can adopt without buying the whole platform
Project Perception is a Microsoft proposal for large-scale environments, but its principles can be used with simpler tools. An agent inventory can be a register of automations and owners; an identity can be a dedicated service account; permissions can be limited by folder, API, operation and time.
Execution should leave understandable evidence: data accessed, actions requested, decisions made, errors and approvals. Irreversible steps need a control point outside the model, and credentials should not appear in instructions, conversations or files the agent can edit.
The goal is not to turn every automation into a cybersecurity programme. It is to design the system so a failure has a limited scope, is visible and can be stopped. The more capable the agent, the less sensible it is to rely on trust in the model as the only barrier.
Sources
Where could this apply to your business?
I help teams turn technology into clear, measurable processes, with sensible controls around the work that matters.