An AI agent should get its own identity and begin with no permissions, and a security team that lets agents borrow the access of the employee who set them up has built the next over-privileged service account.
What Microsoft announced
On October 19 the Microsoft Security Blog described how the company is extending Project Perception to agents. It expands discovery by 35 additional types of local agents, for a total of 60 supported local agents that includes Claude Code, OpenAI Codex and GitHub Copilot. It extends Microsoft Entra Agent ID with identity types for local and previously unknown agents, and it introduces Dynamic Permissions, Dynamic Agent Risk and Dynamic Conditional Access. The product names are Microsoft’s, and the principle underneath them can be adopted this quarter on whatever identity platform a team already runs.
The post states that principle in two sentences: “An agent should not automatically inherit all the standing access of its user. It should begin with no authority and receive only what it needs for the approved task, for only as long as the task requires.” I agree with both, and I would go further than the post does about what happens when a team ignores them.
Borrowed access is the default failure
The fastest way to make an agent useful is to run it with its sponsor’s credentials. The employee can read the finance share, so the agent can too. The employee can approve expenses, so the agent can approve expenses. The post describes this scenario with an expense-approval agent and says that agent “should not inherit every permission of the employee who sponsors it.” Anyone who has audited service accounts knows the pattern. A credential created for one job accumulates reach because nobody wants to break the job by trimming it.
An agent makes that pattern worse, because its behavior can change while its configuration stays the same. The Microsoft post says an agent may begin a task with the right access and then meet a prompt injection in an external document: “Its configuration has not changed, but its behavior and risk have.” A permission review at onboarding cannot see that shift. Only a permission that is small to begin with, and expires, limits what the shift can reach.
Why identity comes first
Separate identity is what makes any of the rest enforceable. The post says an agent identity lets the enterprise “distinguish what a person did from what an agent did on that person’s behalf.” Without that split, a log line that says an employee approved a payment cannot tell the investigator whether the employee did it. An earlier piece here made the case for tracking non-human identity as an unwatched entry point, and every agent adds one more.
The same site has argued that a scope prompt is not an AI agent control. Telling a model in its instructions to stay inside a task is a request. A permission that the agent does not hold is a limit. Satya Nadella, Chairman and Chief Executive Officer of Microsoft, is quoted in the post on where the limit belongs: “The most trustworthy agentic system will not be the one with the model we trust most. It will be the one designed that enables us to trust the model least.”
The strongest objection
The objection I take most seriously comes from the teams that have to run this. Task-scoped, time-bound permissions mean someone must define the task, grant the access, and renew it, and for a single agent doing a single job that may look like more administration than the job is worth. A second objection is that the post comes from a vendor selling the controls it describes, so its sense of urgency deserves a discount.
Both points have weight, and neither changes my position. The administrative cost per agent falls as the number of agents rises, because the template for a narrow grant gets reused. The vendor’s interest does not change the principle, which long predates agents: least privilege and short-lived access are the standard controls for any identity that can act on its own. A team on a different identity platform can apply them with scoped tokens, a service principal per agent and an expiry date on every grant.
What to do
- Give every agent a credential of its own and never reuse a person’s session or token.
- Start each agent with read access to the single data set its task needs, and add write or approve rights only for named actions.
- Put an expiry on every grant and review what lapsed without being renewed, since that list shows which access was never needed.
- Route consequential steps, such as approving payments or deleting data, through a human approval the agent cannot give itself.
An agent that holds no authority it has not been handed for the task in front of it can be wrong, manipulated or compromised, and the damage stays small. That is the result a security leader should ask for before the next agent goes into production.
Source: Microsoft Security Blog, Agents are your newest insiders. Security must move at their speed.
