An always-on agent is an account, not a feature.

The next account added to your Microsoft 365 tenant may not belong to a person.

Microsoft's new Autopilot keeps working when its owner is away. It watches channels, follows up on threads, runs recurring work and returns to projects days later. More importantly, it has its own identity, memory, computer and workspace.

That is not another Copilot button. It is a new operating account inside the business.

What Microsoft announced

On September 25, Microsoft introduced a new Copilot experience built around Home, Code and Autopilot. Home and Code are headed to the Frontier early-access program. Autopilot, previously called Scout, expands to private preview at the end of September.

Autopilot is the consequential part. Microsoft describes a cloud-hosted agent that can monitor Teams channels, manage a supplier review, contact stakeholders and continue working without another prompt. It appears in Teams, Outlook, chats, channels and documents. Reuters reported that each agent will carry its own directory identity and specific permissions.

Microsoft documents controls for Microsoft 365 agents generally. Its administration guide lets a tenant restrict agent access to all users, no users or selected groups. It also distinguishes simple, user-initiated agents from custom agents that can trigger actions without direct user input. Those custom agents must be published and approved before they are available to the organization.

The controls are real. Which of them apply to Autopilot's private preview must be confirmed before enabling it.

Persistence changes the security model. An agent that can act tomorrow needs the same discipline as an identity that can act tomorrow.

Why this is different from chat

A chat session waits for a person. A persistent agent has standing instructions, retained context and time.

That combination matters. A permission that looked reasonable for one supervised task becomes continuing access. A connector added for one workflow becomes another route into company data. An agent assigned to a project can remain active after the project owner changes roles or the process ends.

The risk is not that every agent will behave badly. The risk is that organizations will deploy a durable identity with the review process used for a software feature.

Traditional identity programs already have the right questions. Who owns this account? What can it read? What can it change? Which actions require approval? Where are its logs? When does its access expire? Those questions do not become less important because the account uses natural language.

Microsoft's own management guidance covers connector permissions, sharing restrictions, data loss prevention policies, approval workflows and eventual agent retirement. That lifecycle language is the point. Deployment is only the beginning.

What we would do before the preview

Register the identity. Give every persistent agent a unique record with a named business owner, technical owner, purpose and creation date. Keep it beside service accounts and enterprise applications, not in a list of productivity experiments.
Write an access contract. Record the exact mailboxes, sites, channels, connectors and actions the agent needs. State where it may send or publish output. If a permission cannot be tied to the assigned job, remove it.
Set an expiration date. Persistent access should not mean permanent access. Give the identity a review date and an automatic end date. Renewal should require the owner to confirm that the job, data and permissions are still current.
Make ownership transferable. The agent should not become unmanageable when its creator changes roles. Document who can pause it, who can accept ownership and which executive is accountable for the business process it runs.
Prove the audit trail. Run known test tasks and trace the resulting access, messages and changes through the logs. Record the identity consistently. If an investigator cannot separate the agent's work from its owner's work, the deployment is not ready.
Connect lifecycle events. A departure, role change, closed project, expired connector or removed data source should trigger a review. Decide which events pause the agent automatically and which require the owner to reapprove its access.
Retire the whole agent. Disabling the visible workflow is not enough. Revoke the identity and connectors, preserve required records, remove scheduled work, settle ownership of its output and delete retained context under the applicable policy.

Microsoft says long-running Autopilot work uses usage-based billing. Review spend beside the access record. An unexpected rise can expose a forgotten schedule or an agent doing more work than its owner intended.