Technology & everyday life

When Software Acts for You

October 2026
11 min

A computer that can act on your behalf needs more than access to your files. It needs a way to understand and enforce the limits of permission.

On 7 October, Microsoft released a new kind of container for Windows.

The word usually describes technology that isolates one software workload from another. Microsoft Execution Containers can place an AI agent inside a restricted environment, limiting which files it may open, which network destinations it may contact and which tools it may use. A lightweight process container can constrain a coding task. A separate Windows session can give a longer-running agent its own desktop, clipboard, identity and input boundaries. Higher-risk work can be placed inside a small virtual machine.

Microsoft announced the system alongside powerful models that can run directly on new Windows computers. Its MAI Code 1.1 Flash model has 137 billion total parameters, although only 6.8 billion are active at once; compression reduces its memory requirements sufficiently for specialised personal computers. Copilot will be able to use local files and recent activity, perform actions across Windows and decide whether a task should run on the device or in the cloud.

The obvious story is that AI is moving from remote data centres onto the personal computer. This may reduce cloud costs, improve responsiveness and allow some information to remain on the device. It also asks the computer to perform a different role.

The personal computer has long protected the authority of the signed-in user from other people and applications. It must now protect that user from software acting on the user’s behalf.

This sounds like a narrow security problem. It is really a problem of delegation.

From command to objective

Most conventional software operates through relatively direct instructions. A person clicks Save and the application writes a file. They select an address and the email client sends a message. An automated process may perform thousands of operations, but its actions were normally specified in advance by a developer.

An AI agent is given something closer to an objective.

“Find the documents my accountant needs and send them over.” “Clean up this project folder.” “Book the most convenient journey within my budget.” “Update the website and deploy the change.”

The agent must translate that instruction into a sequence of decisions. It may search messages, identify attachments, open files, compare dates, invoke other applications and communicate with external services. The useful part is precisely that the person does not have to prescribe every step.

But each missing instruction creates room for interpretation.

Which documents count as relevant? Is the accountant’s address known to be genuine? Does “clean up” mean moving old files or deleting them? Does a travel budget include cancellation protection? Is the agent permitted to change a production configuration if that appears to be the easiest way to deploy the website?

The person possesses broad authority over their own computer. The agent needs only the portion required for the task. Those are not the same thing.

Today’s digital permissions do not express this distinction particularly well. An application is generally allowed or denied access to categories such as contacts, photographs, location or files. Once permitted, it may retain that access for months. The system records which application used a resource, but not necessarily the purpose for which the user allowed it.

Agents make this weakness more consequential. They can combine information across applications and take unanticipated intermediate actions. A permission to read files and a permission to send messages may be reasonable separately. Together, they create the power to disclose anything the agent can read.

The central question is no longer simply whether software has access. It is whether a particular action falls within delegated intent.

Local does not mean contained

Running a model on the device offers genuine privacy advantages. A document can be analysed without necessarily being uploaded to a cloud service. The user may avoid per-token charges, and an agent can continue working when connectivity is limited.

Yet moving intelligence onto the computer also moves capability closer to the user’s most sensitive resources.

A local agent may have access to source code, browser sessions, saved credentials, private documents and applications already authenticated in the user’s name. It can act with low latency and may continue working while the person does something else. If compromised or misdirected, it is already inside the perimeter.

Microsoft’s own security research illustrates the mechanism. Researchers found vulnerabilities through which prompt injection could become remote code execution: an agent processed malicious language, selected a legitimate tool and passed unsafe parameters into it. The model did not have to “turn evil”. It followed the path made available by its framework.

This matters because an agent consumes material that may contain instructions from someone other than its user. A webpage, email, project document or tool response can include text telling the agent to ignore its original objective, inspect a sensitive file or contact an external server.

Humans recognise, imperfectly, that a sentence inside a document is part of the document rather than a command addressed to them. Language models do not reliably maintain that distinction. Microsoft’s Defender documentation acknowledges that local agents cannot consistently separate trusted instructions from hostile ones embedded in ordinary content. Its runtime protection therefore examines prompts, proposed tool calls and returned information, attempting to block dangerous actions before they occur.

Detection is useful, but it is not a sufficient foundation. Any detector can miss an attack or block legitimate work. A stronger system assumes that the agent may become confused and limits what that confusion can accomplish.

This is the significance of Microsoft’s observation that an agent cannot be its own security authority. The policy must sit outside the model. The agent may request access; it cannot grant access to itself.

An identity that is not yours

Containment limits reach. Identity establishes attribution.

If an agent operates entirely through the user’s account, a receiving system may see no difference between an employee downloading a record and an agent doing so automatically. The audit log says who owned the credential, not who chose the action.

That creates practical problems after something goes wrong. Did the user ask for the action explicitly? Did the agent infer it? Was an external instruction involved? Which application or sub-agent supplied the request? Could the organisation revoke the agent without disabling the employee?

Microsoft plans to use separate local agent identities and connect them to its Entra identity system. Agent processes can be tagged, governed and distinguished from human activity. Administrators can then restrict the agent while allowing the person to continue working.

This reflects a wider movement. The US National Institute of Standards and Technology began a project this year on software and AI-agent identity and authorisation. Its work treats agents as entities requiring their own identification, credentials and access policies rather than as invisible extensions of human accounts. Recent public feedback led NIST to concentrate initially on agents used in software development, where they already inspect code, call tools and modify operational systems.

Researchers have described the required model as authenticated delegation. A system should be able to establish who delegated authority, which agent received it, what the agent may do and how the resulting actions can be audited.

This is more than a technical refinement to login systems. It establishes a chain of responsibility.

When an employee appoints another person to carry out a task, the organisation does not usually hand over the employee’s passport, bank account and every workplace permission. It defines a role, limits authority and preserves evidence of who acted. Powers of attorney, expense approvals and delegated signing rights all separate the principal from the representative.

Agent identity brings the same distinction into computing.

Permission has several dimensions

A useful delegation is narrower than “allow” or “deny”.

It may be limited to a particular objective: prepare documents for this tax return. It may apply only to named resources: the 2025–26 accounts folder, not the whole drive. It may allow one kind of operation but not another: read a configuration file, but do not modify it. It may specify a recipient, a spending limit or an expiry time. A higher-risk action may require fresh human confirmation.

Some of these boundaries can already be enforced technically. Microsoft’s containers can distinguish between read and write access, restrict networks and keep the agent away from personal folders. Separate identities can support different permissions and better logging.

The harder boundary is semantic.

Suppose an agent may read the accounts folder and send email to the accountant. Those permissions do not establish which files the accountant should receive. The agent could remain inside every technical boundary and still disclose something irrelevant or private.

Or suppose a travel agent has permission to spend £500. A £450 booking is authorised in amount, but perhaps not if it departs from the wrong airport or cannot be cancelled. Formal access rules capture resources and actions more easily than the meaning of the user’s request.

This is where the language of being “in control” can become misleading. A person may technically grant every permission while lacking a realistic understanding of the actions that permission enables. Repeated confirmation prompts can make matters worse: people learn to approve interruptions so that work can continue.

A workable system will need graduated delegation. Routine, reversible actions can proceed quietly. Irreversible, unusual or expensive actions should require clearer consent. The agent’s authority should narrow when it encounters uncertainty rather than expand because another tool appears useful.

The design challenge is not to ask the user about everything. It is to recognise when the agent is about to cross from completing the task into redefining it.

Evidence after the action

Delegation also changes what people need from activity history.

A conventional audit log might record that a file was opened at 10:42 and an email was sent at 10:44. An agentic record needs to preserve more context: the user’s original objective, the authority granted, the information consulted, the tools invoked, the points at which the agent changed course and whether a person approved the final action.

Without this chain, a detailed log can still fail to answer the most important question: why did the system do that?

This does not mean recording every hidden calculation inside a model. Such records may be neither reliable explanations nor sensible things to retain. The useful evidence is operational: what the agent received, what it attempted, which policy allowed or blocked it and what changed in the external world.

That evidence supports more than cybersecurity. It allows a person to review a completed task, an organisation to investigate a mistake and a customer to contest an action made in their name.

Recovery matters equally. If an agent reorganises a folder incorrectly, the changes should be reversible. If it sends confidential information, reversal is impossible and prevention must be stronger. If it makes a purchase, the transaction may need an established cancellation or dispute process.

The acceptable degree of autonomy should therefore depend partly on how recoverable the action is.

The operating system becomes an institution

Microsoft’s new machines are expensive. The Surface Laptop Ultra starts at $2,599, and configurations capable of running the largest local models cost considerably more. This will initially limit the technology to developers, organisations and affluent enthusiasts.

The institutional change may spread more widely than the hardware.

Operating systems have always mediated authority. They decide which process can use the camera, which account can change a setting and which application may connect to a network. Agentic computing makes that role visible because permission is no longer attached only to a person or an application. It must follow a temporary delegation through a sequence of partly self-directed decisions.

The companies controlling operating systems will consequently shape the practical grammar of agency. They will decide how consent is requested, how agent identities appear, what activity is logged and which actions require interruption. A small design choice—whether an agent may reuse a permission tomorrow, for example—can determine how much authority people surrender through convenience.

Interoperability will matter. If agent identity and delegation work only within one company’s products, organisations may gain security while acquiring a deeper platform dependency. A credible permission system should be able to govern agents from different developers and communicate limited authority across services without sharing the user’s main credentials.

Microsoft says its containment layer can be used by agents from Anthropic, OpenAI, Nvidia and others. That is useful evidence of a platform approach. Whether identity, policy and audit records become genuinely portable remains unsettled.

The release of Microsoft Execution Containers will probably be remembered, if at all, as part of an October hardware announcement. The more revealing sentence appeared in its technical explanation: the agent must operate inside a boundary it does not control.

That boundary is where personal computing is now being redesigned.

The next computer will not merely hold a person’s information and execute their commands. It will interpret objectives and act through their authority. Its most important feature may therefore be neither the size of the model nor whether the model runs locally.

It will be whether the computer can tell the difference between what you are able to do, what you asked the agent to do and what the agent decided to do next.