Microsoft 365 Governance

Microsoft is giving Copilot a job. Your IT controls need to catch up.

Microsoft’s Copilot announcement points towards persistent agents with their own identity and workspace. For a business, that makes ownership, permissions and offboarding practical IT questions.

9 min read — Altitude IT Security Team

A persistent AI service identity is connected to business applications with separate ownership, permission and audit controls.
A persistent agent belongs in the IT inventory, with a named owner and a defined access boundary.

Microsoft’s 25 September 2026 Copilot announcement described more than a new chat window. It introduced Copilot Home and Code and set out Autopilot as a persistent, proactive cloud-hosted agent: something that can continue work over time, with its own identity, memory, computer and workspace.

Microsoft said the agent could work across Teams, Outlook, chats, channels and documents, with permissions, audit and governance around it. That is Microsoft’s description of the planned capability, not a promise that every tenant can use it today. The announcement said Home and Code would begin rolling out through Frontier in the following weeks and Autopilot would expand to private preview at the end of September. It did not announce general availability for all Microsoft 365 customers. Check current eligibility and licensing before making plans.

For an SME, the useful question is not whether an agent sounds like an employee. It is whether the organisation can identify who owns it, what it can reach, what it may change and how to remove that access when the job ends.

Start with a named purpose and owner

Before enabling an agent, write down the business task it is meant to perform and name both a business owner and a technical contact. The owner should be able to explain what successful work looks like; the technical contact should know which identity, connections and data access make it possible. Record the environment and the person responsible for reviewing it.

Do not build a permanent workflow around one employee’s everyday sign-in if the product offers an appropriate separate identity or delegated access pattern. Actions need to be attributable, and the agent must not disappear from the inventory when its creator changes role or leaves. The right identity model depends on Microsoft’s product design and current controls; avoid assuming that every Copilot feature uses the same one.

Give it only the access required for the task

If an agent needs to read a particular mailbox, SharePoint site or Teams channel, that does not automatically justify access to the whole tenant. Start with the smallest useful scope. Avoid broad membership or administrator access added simply to make a pilot easier.

Review the permissions already attached to the information. An agent may make an existing overshared folder easier to discover; it does not create every underlying access weakness. Check who can reach sensitive documents, whether old guest accounts remain active and whether the information is separated by role or project. Good access hygiene benefits people and software alike.

Separate preparation from authority to act

Automation is most useful when a person does not need to approve every harmless step. It is still reasonable to reserve human approval for actions with financial, legal, privacy or access consequences. A business might allow an agent to collect information, monitor a channel or draft a document, while requiring approval before it sends an external commitment, changes customer data, deletes information, makes a payment or alters permissions.

Turn those boundaries into a simple action table before a pilot:

  • Allowed: read approved material, summarise, draft or flag an item.
  • Confirm first: send an external message, make a consequential record change or start a customer-facing workflow.
  • Not allowed: use another person’s credentials, change its own permissions, make payments or delete business data without an explicitly approved process.

These are policy examples, not a claim that every Microsoft agent exposes the same controls. Verify what the specific product can and cannot enforce. If a required boundary is unavailable, narrow the workflow or do not grant the access.

Make audit and incident response part of the design

For each action that matters, decide what evidence the business needs: what the agent accessed, what it created or changed, who approved it and where the result went. Confirm which activity the product actually logs and how long it is available. Do not treat a general “audit” description as proof that every action will be visible in the format your incident process needs.

Give the support team a way to pause the workflow, revoke its access and investigate an unexpected result. If an agent sends an unintended message or changes the wrong record, the response should be familiar: stop further activity, preserve relevant logs, assess affected data and people, correct the record where possible and review the permission or instruction that allowed it.

Plan for offboarding before the first task

Agents need a lifecycle. Decide what happens if the employee who created the workflow leaves, the business process changes, the product is no longer licensed or the pilot stops. List the agent’s identity, delegated connections, application permissions, workspace and data dependencies. Make sure the owner can disable the agent and remove related access without hunting through individual user accounts.

Retention and deletion matter too. A business may need to retain a business record created by an agent while removing the agent’s own workspace or history. Follow the organisation’s record-keeping and privacy requirements; do not assume that turning off one interface automatically resolves every connected permission or data copy.

Budget for activity, not just a licence

A persistent cloud agent may run tasks over time rather than stopping when a person logs off. Microsoft’s announcement also discussed FinOps capabilities and usage-based charging for agentic features. It did not set out a price that should be assumed for every customer. Confirm current terms, measure actual use and set a budget owner before expanding a pilot.

Agree what the agent is expected to save or improve, how repeated or unnecessary activity will be noticed, and who reviews spend against value. A task that runs continuously but produces no useful outcome is both an operational problem and a cost-control problem.

What should businesses do?

  1. Choose one bounded workflow with a named business owner.
  2. List the specific data and systems it needs, then reduce access to that scope.
  3. Define which actions it may prepare, which require approval and which are prohibited.
  4. Test normal, ambiguous and incorrect requests before connecting the workflow to live data.
  5. Verify the product’s identity, permission, audit and cost controls in the tenant—not only in an announcement.
  6. Document how to pause it, revoke its access, transfer ownership and remove it.

Microsoft’s direction is significant because AI is moving beyond a toolbar button towards agents with continuing responsibilities. That can be useful when the task is clear and the boundaries are enforced. If an AI has an identity, permissions and access to company data, manage it as part of your IT estate—with ownership, identity, permissions, audit and lifecycle controls.

IT Club has covered the wider question of AI agents taking actions on a business’s behalf. This article applies that access discipline to Microsoft’s announced Copilot direction and the day-to-day controls an SME needs to verify.

Sources and further reading

Who will own the access granted to an AI agent?

Altitude IT can help review Microsoft 365 identity, permissions and security controls, giving your business a practical baseline before agent-style automation is connected to company data.

Talk to an Expert Microsoft 365 Security Review