Copilot Cowork: how to safely delegate actions to AI

A regular chatbot suggests text. Agent mode can open a website, edit a file, send a message, or run a chain of actions on the user's behalf. An error in a response is unpleasant, but an error in an action changes an external system. So the main question for Copilot Cowork and similar tools is not “how smart is the model?” but “where will it stop and ask for approval?”

Microsoft explicitly describes Cowork as a preview and warns about misinterpreted instructions, prompt injection, and financial and privacy risks. It is useful to translate these limitations from documentation language into working rules.

How an agent differs from a draft generator

With a text assistant, the boundary is simple: the model responds, and the person transfers the result into an email, spreadsheet, or document. An agent is connected to tools and can take the next step itself. It has the account's context, the user's permissions, and access to the data available to that user.

According to Microsoft documentation, Cowork does not receive new permissions and operates within existing Microsoft 365 permissions. This is a useful boundary, but it does not protect against an incorrect action within an already accessible space. A user with permission to edit a document can accidentally damage it themselves; an agent acting on their behalf inherits the same capability.

This leads to the first principle: an operation being available and an operation being appropriate are two different things. The system may be technically able to send a message, but it should separately make sure that the user has seen the recipients and the final text.

Which actions require a stop

In Cowork, sensitive operations are accompanied by an approval dialog. These include sending an email or Teams post, changing a file, and other actions that leave a trace in an external system. For some operations, the interface shows a preview. The user can approve the action once, cancel it, or turn off repeated prompts for similar actions in the current conversation.

The last option saves time, but broadens the scope of trust. If the task changes context as it proceeds, a previous approval may turn out to be too broad. It is safer to keep separate approvals at least for these categories:

• messages, emails, and posts on a person's behalf;
• payments, purchases, and any financial commitments;
• sharing personal or confidential data;
• deleting, overwriting, and moving files;
• changing access rights, account settings, and security rules;
• actions that cannot be fully undone.

Microsoft classifies multifactor authentication, CAPTCHA, and payment confirmation as steps that the agent should hand over to a person. This is not an obstacle to automation, but an explicit decision point.

Why approval does not solve everything

A dialog with a button protects you only when the person understands exactly what they are approving. The wording “continue task” is almost useless. A good approval prompt shows the action, object, recipient, and data being changed: “send an email to these three recipients,” “replace this file,” “share the name and phone number with this website.”

A preview is also needed. A draft may contain correct facts, but the wrong tone, an extra recipient, or a fragment of internal text. Microsoft advises treating generated documents and messages as drafts until they have been reviewed. This is especially important when the agent has assembled a response from incomplete or outdated corporate data.

Don't turn approval into a mechanical click. A series of ten identical dialogs quickly creates the habit of approving without reading. It is better to group safe, similar steps into a plan and show a concise summary before an external action.

Prompt injection comes from ordinary content

An agent reads more than just the user's request. It sees web pages, emails, documents, and messages. These may contain a hidden or convincingly worded command: ignore the original task, open another address, copy data, or request unexpected permission.

In its security recommendations for Cowork Microsoft advises stopping work if the agent goes to an unexpected website, asks for an unfamiliar approval, or is about to perform an action the user did not request. This is a good indicator of an attack, but not the only one. A change of recipient, a sudden file download, a request for secrets, and an attempt to expand the scope of the task should also raise concern.

Page content should be treated as data, not as a new instruction. Architecturally, this means separating channels: the user's instruction has one level of trust, and text from an external document has another. The model can use external text as a fact for analysis, but should not automatically turn it into a command.

How to phrase a task for an agent

A vague goal leaves too many decisions up to the system. “Sort out the correspondence” doesn't explain whether it may reply, to whom, or on whose behalf. A useful request sets the boundaries in advance:

• which sources it is allowed to read;
• what result it needs to prepare;
• what it can change without asking another question;
• which actions require it to stop;
• which data must not be shared externally;
• how the user will check the finished result.

For example: “Compile a list of overdue replies from these emails. Prepare drafts, but don't send anything. Don't open links in the emails. In the final table, include the sender, subject, and recommended action.” Such a request does not guarantee there will be no errors, but it makes them easier to spot.

Practical control matrix

Who is responsible for the result

The phrase “the agent did it” does not shift responsibility to the model. The user or organization chose the tool, granted access, and approved the action. So the log should answer four questions: who set the task, which sources were used, what the agent changed, and who approved the external step.

For work processes, this is not enough without recovery options. Documents are best changed using version history, code through separate branches, and bulk operations through a test run on a small sample. Pause and cancel buttons help during execution, but do not replace a backup and a change log.

Agentic work is safe not when the system never makes mistakes, but when a mistake remains a draft instead of becoming a sent email, deleted file, or approved payment.