Agent access mode is a management decision, not an implementation detail

The most interesting agent question this week is not whether agents can get more powerful.

They can.

The more useful question is what kind of actor an organization is creating when it gives an agent access to work.

Microsoft’s Agent 365 material makes this concrete. Its current guidance describes three access patterns for agents in Microsoft 365: acting on behalf of a user, acting as an application, and acting with the agent’s own user identity. Agent 365 itself is being positioned as a control plane for observing, governing, and securing agents across the organization.

That could be read as product packaging.

I think it is a better signal than that.

Agent access mode is becoming a management decision, not an implementation detail.

The access pattern tells you what kind of authority the agent has been given. If teams choose it casually, they will quietly create confusing workers: sometimes assistant, sometimes service account, sometimes quasi-employee, and sometimes all three at once.

That confusion is where agent governance will break.

What changed

For a long time, many AI workflows were simple enough that access design could stay fuzzy.

A user pasted context into a chat box.

A model answered.

Maybe a tool call happened behind the scenes.

If anything important needed to be done, a human copied the result somewhere else.

That world is easier to manage because the model is mostly advisory. The human still owns the actual access path.

Agents change that shape. They read content, use tools, move across systems, prepare work, trigger actions, and sometimes continue across sessions. Once that happens, access mode stops being plumbing. It becomes the operating definition of the agent.

There are three broad patterns:

• Delegated access: the agent acts on behalf of a user for a request or session.
• Application access: the agent acts through an app-style permission scope.
• Own identity: the agent becomes a persistent actor with its own assigned identity and accumulated access shape.

Those are not interchangeable technical options.

They answer different management questions.

Delegated access says: this is an assistant extending a person’s current intent.

Application access says: this is a system function with bounded service permissions.

Own identity says: this is a distinct worker-like actor that can participate in shared work surfaces and be governed as itself.

If a team cannot explain which of those it is choosing, it probably cannot explain the agent’s authority either.

Why this matters

Access mode determines where responsibility becomes blurry.

If an agent acts on behalf of a user, the useful fiction is that the human remains the principal. That works well for short-lived assistance: draft this reply, summarize this document, prepare this analysis, inspect this ticket.

But it gets uncomfortable when the agent starts making choices the user did not explicitly inspect.

If an agent acts as an application, the useful fiction is that the agent is part of a controlled system. That works well for narrow workflow automation: classify inbound requests, enrich records, route exceptions, generate reports.

But it gets uncomfortable when the workflow starts looking like judgment rather than deterministic processing.

If an agent has its own identity, the useful fiction is that the organization has created a new operating actor. That works well when the agent needs continuity, collaboration, accountability, and separate policy boundaries.

But it gets uncomfortable when the organization treats that actor like just another feature instead of a role that needs supervision.

This is why the access-mode decision belongs with managers and builders, not only identity administrators.

It shapes:

• what the agent may see
• what it may prepare
• what it may execute
• whose authority it is borrowing
• when its actions should be attributed to itself
• what review boundary is required
• how failures are investigated
• whether its authority can be expanded after evidence

That is not an IT setting.

That is delegated work design.

What people are overreacting to

People may overreact to the phrase “agent identity.”

It sounds like the advanced answer. Give the agent an identity. Put it in the directory. Monitor it. Govern it. Now the system is mature.

Sometimes that is right.

But own identity is not automatically safer or better. It is more explicit. That can be good because it makes the agent visible, governable, and separable from a human user’s account.

It can also create a new persistent actor whose access grows messy over time.

A badly designed agent identity is just a cleaner-looking service account with better branding.

The goal is not to give every agent an identity.

The goal is to match the access mode to the work.

A research helper may only need delegated access.

A nightly reconciliation workflow may need application access.

A cross-functional operations agent that appears in Teams, reads shared documents, coordinates tasks, and keeps state across workstreams may deserve its own identity.

Those are different jobs.

They should not inherit the same access model by default.

What people are underreacting to

People are underreacting to how much organizational design hides inside access patterns.

When a manager says, “let the agent handle this,” there is a second question underneath:

Handle it as whom?

As me?

As the application?

As its own accountable actor?

That question changes the risk.

A delegated agent can accidentally inherit too much of a user’s reach.

An application agent can become too broad because service permissions are convenient.

An own-identity agent can accumulate authority without the social supervision that a human role would receive.

Each pattern fails differently.

That is why a serious agent rollout should not start with a list of tools alone. It should include an access-mode review for every meaningful workflow.

A practical way to decide

I would use a simple access-mode matrix before promoting any agent into real work.

1. Use delegated access when the task is user-intent heavy

Good fit:

• drafting
• summarizing
• searching within a user’s authorized context
• preparing options
• performing short-lived task assistance

The agent is an extension of the user’s immediate work.

Management rule: keep execution rights narrow and make the handoff from suggestion to action visible.

2. Use application access when the task is system-function heavy

Good fit:

• classification
• routing
• data enrichment
• scheduled checks
• bounded workflow automation

The agent is part of a defined process.

Management rule: scope permissions to the workflow, not to the most powerful user who asked for it.

3. Use own identity when the task needs continuity and accountability

Good fit:

• persistent team agents
• cross-system operations agents
• agents that participate in collaboration spaces
• agents whose actions should be inspected separately from any one user

The agent is becoming a role.

Management rule: give it an owner, an authority boundary, review evidence, and a demotion path.

4. Avoid mixed-mode confusion

The dangerous pattern is not any one mode.

It is an agent that borrows a user’s authority, uses application-style background reach, and behaves like an independent actor without anyone naming which mode applies when.

That is how teams get surprised.

What managers and builders should do differently

Before expanding an agent’s access, write down five things:

1. Access mode: delegated, application, own identity, or intentionally hybrid.
2. Authority level: observe, prepare, recommend, execute, commit, or escalate.
3. Attribution rule: whose action is this when something changes?
4. Review boundary: what requires human inspection before the next step?
5. Evidence rule: what logs, outcomes, or exception records determine whether this access should continue?

This is not bureaucracy for its own sake.

It is how you prevent agent sprawl from turning into authority sprawl.

The market is starting to build control planes for agents because agents are becoming normal participants in work. That is the right direction. But a control plane cannot save a team that has not decided what kind of actor each agent is supposed to be.

So the next time a product asks for agent access, do not only ask whether the permissions are technically allowed.

Ask the management question:

Are we creating an assistant, a system function, or a new operating actor?

The answer should shape the design before the agent touches real work.