The AI Employee Has Your Keys. Who Answers When It Opens the Wrong Door?

By Diplomat AI Editor | Document-based investigation | 2 November 2026

An AI assistant that can read your inbox is convenient. An AI assistant that can send messages, retrieve company files and act across applications holds something more consequential: delegated authority. The sales demonstration shows the work disappearing. The security question is where the authority goes.

A review of public research reports and vendors’ own documentation reveals three distinct weaknesses in this arrangement: people can be persuaded to authorise malicious applications through a credible-looking agent; hostile content can redirect an otherwise legitimate agent; and gaps in audit records can make changes to an agent harder to reconstruct.

These are different mechanisms, with different preconditions. None establishes that every workplace agent is compromised. Together, however, they expose a procurement question that a productivity demonstration cannot answer: when software acts in an employee’s name, can the organisation prove who authorised the action, what access was available and which controls actually intervened?

The permission behind the personality

Microsoft’s documentation on granting agents access distinguishes delegated permissions, used when an agent acts for a signed-in person, from application permissions, used without a user present. Examples include accessing a user’s mail or files, or reading user profiles through app-only access.

The documentation also explains that approved delegated scopes can appear in future tokens without another consent prompt unless consent changes. Access packages can bundle several kinds of rights, with access lasting until revocation or expiry.

This is legitimate infrastructure, not evidence of wrongdoing. It does explain why “I approved the assistant” is an inadequate account of what happened. Approval has an object, a scope and a lifetime. The human-friendly name of an agent tells an employee remarkably little about those three things.

For a buyer, the relevant evidence is therefore the permission record. Which application received access? To which resources? Could it only read, or also change and transmit information? What ends its authority?

Case one: a trusted address, an untrusted request

On 20 October 2025, Datadog Security Labs published CoPhish, a demonstration of Microsoft Copilot Studio being used as a wrapper for OAuth consent phishing.

The researchers showed that configurable agent sign-in behaviour could direct users into a malicious consent flow. A legitimate Microsoft-hosted interface could lend credibility to the request; after authorisation, a token could enable access within the permissions granted. Their demonstration also used agent automation to transfer the resulting token.

This was a researcher-developed technique, not a disclosed count of victims or proof of a particular employer’s breach. It depended on consent and applicable identity-policy conditions. Datadog discussed remaining scenarios involving internal applications and administrators, rather than claiming every user could approve every permission.

The distinction matters. The documented problem was not a model spontaneously stealing credentials. It was familiar permission abuse packaged in a newer, reassuring interface.

A corporate domain authenticates a location. It does not establish that every workflow hosted there deserves the authority it requests.

Case two: what happens when the record is incomplete?

On 10 March 2026, Datadog published a separate investigation into Copilot Studio logging. It reported missing audit events for sensitive administrative changes, including authentication, logging, sharing and publication.

According to its disclosure account, Microsoft initially remediated reported events. Subsequent retesting found inconsistent logging for two event types. Datadog’s timeline records Microsoft’s engineering team saying on 2 March 2026 that it could not reproduce the anomalous behaviour.

The report describes a potential chain involving an attacker who already had agent-management access. That prerequisite is important: the finding did not give any internet visitor administrative powers. Nor does the report establish that the same gaps remain present in November 2026.

Its significance is evidential. A security policy can say a change is logged, while an investigator still needs proof that the expected record was generated in practice.

Datadog sells monitoring products and links its research to commercial detections. That interest should be visible alongside the technical findings. It does not invalidate the reported testing; it is a reason to seek reproducible evidence rather than purchase on the strength of the warning alone.

Case three: the instruction hidden in the work

A different attack does not ask the employee to approve a malicious application. It places instructions inside material that a legitimate agent has been told to process.

NIST’s 23 March 2026 account of a public red-teaming competition describes more than 250,000 attempts by over 400 participants against 13 frontier models. At least one successful attack was found against each target model.

NIST also reported substantial differences in robustness. Those findings do not mean that all models fail equally, that every deployment is exposed, or that the competition’s results predict the breach rate of a particular business.

They do challenge a simpler purchasing assumption: that a capable model will reliably recognise which text deserves obedience. An agent reading email, websites or code must distinguish material it should analyse from instructions it should follow. An attacker tries to collapse that distinction.

A lab success is not a customer incident. It is evidence that the boundary needs enforcement beyond confidence in the model.

The browser is another workplace door

Google’s June 2026 WebMCP security guidance identifies malicious tool descriptions and contaminated tool outputs as attack surfaces. It notes that browser agents can operate within an authenticated user session.

The guidance recommends controls including restrictions on destinations and user confirmation. It also distinguishes deterministic safeguards from model-based ones and warns against relying on the model itself for a safety guarantee.

This extends the question beyond a single vendor. Moving an agent into a browser does not make its authority disappear; the logged-in session may already contain it.

Consider a hypothetical expense workflow. Reading a supplier’s invoice and sending a payment instruction are different acts. If hostile text in the invoice influences the second act, the decisive control is whether the payment action has an independently enforced boundary. Asking the same assistant whether its own proposed action looks sensible is a weaker form of separation.

This example illustrates the mechanism. It is not an allegation that a named company’s expense system has been exploited.

The supplier’s answer—and its commercial interest

Microsoft’s 19 October 2026 security announcement explicitly treats agents as a potential insider risk. It describes independent controls, task-scoped authority, separate agent identities and responses that can restrict or stop risky actions.

The announcement connects this approach to Project Perception, Microsoft Agent 365 and its wider security infrastructure. These are the supplier’s descriptions of its architecture and offerings, not independent measurements of protection in a customer environment.

The principle is defensible: a model should not control the boundary that constrains it. The commercial consequence also deserves scrutiny. A company offering agent deployment is simultaneously positioning its security ecosystem to govern that deployment.

That is not evidence that the vendor deliberately creates vulnerabilities or that its safeguards are ineffective. It is a structural interest buyers should examine when assessing total cost and dependence. A demonstration of useful automation is not a demonstration that the proposed governance package is necessary, sufficient or the best available choice.

The same scrutiny belongs on outside security vendors. Fear is also a sales channel.

Follow the bill, but do not invent it

The reviewed documents establish technical mechanisms and vendor responses. They do not supply an independently verified total for agent-related corporate losses, the additional security spending attributable to these deployments, or the price paid by a typical employer.

Without those figures, a dramatic claim about billions lost would be theatre.

A useful financial investigation starts instead with contracts and itemised costs: deployment licences, identity administration, logging, retention, incident response and integration work. Buyers should ask which controls are included, which require additional products and which obligations remain with their own teams.

The question of who pays after an incident cannot be settled from a product blog. It requires the actual service agreement, deployment facts and applicable rules. This investigation did not obtain a customer contract or determine liability in an individual case.

What can be said is narrower: the value case is incomplete if it counts time saved while leaving the cost of governing delegated authority unmeasured.

The employee should not become the explanation of last resort

For employees, an opaque approval request creates a practical accountability problem. If the interface invites a person to delegate work, but conceals the duration or breadth of access in unfamiliar language, a subsequent click is a poor substitute for informed organisational control.

That is an analytical conclusion, not a finding about a specific employer’s conduct.

Microsoft’s own risk guidance recognises weak user visibility, inadequate intervention points, excessive permissions and agent hijacking as relevant risks. It recommends system-enforced boundaries, minimal authority and reliable interruption mechanisms.

The procurement implication is concrete. Ask the supplier to demonstrate refusal as carefully as completion. Can the agent read an invoice while being prevented from sending unrelated files? Can an administrator revoke access and verify the result? Can the company distinguish the employee’s action from the agent’s action?

These are acceptance tests with observable outcomes. “Our AI understands your intent” is not one.

What this investigation establishes—and what remains missing

The evidence reviewed here supports three conclusions: credible interfaces can carry malicious permission requests; sophisticated models can be redirected in adversarial tests; and audit coverage must be verified rather than assumed.

It does not establish the prevalence of these problems across all workplaces, a continuing unremediated flaw in a particular customer deployment, or that any named vendor caused a specific loss.

POLONICO conducted a documentary investigation, not a penetration test. No private systems were accessed and no interviews were conducted. Microsoft’s published guidance and responses recorded in the researchers’ disclosure timeline are represented here; POLONICO did not obtain a fresh company response.

The unanswered questions belong in the next purchasing meeting: show the permission inventory, the expiry rules, the independent action boundary, the tested audit trail and the full governance bill.

The AI employee can be useful. Before giving it the keys, somebody should be able to produce the key register.