Your AI Assistant Can Leak Company Data Using Permissions You Already Approved.

For further context, see SPF Readiness Is an Operating Model Problem and From Scam Signal to Reasonable Steps Evidence.

Click to view full size

Consider a finance assistant introduced to make month-end reporting less painful. It needs email to find invoices, documents to check contracts and a CRM connection to identify customers. Someone adds a messaging connector so it can resolve questions without interrupting the team. Later it gains the ability to prepare replies. Each decision has a reasonable explanation. The access review contains no obvious rogue administrator account. Yet the combined system can now assemble a picture of customers, pricing, disputes and payment arrangements that used to require effort across several applications. If untrusted content redirects that assistant towards an external recipient, the resulting activity may consist of ordinary searches, permitted reads and an approved communication tool. The organisation has an insider-risk problem even if nobody stole an employee’s password.

This is what makes connected AI different from a writing tool sitting in an empty chat window. Its practical power comes from the sources it can reach, the context it retains and the actions its surrounding software permits. A model can become more consequential without becoming more capable: connect the same model to another repository or give it a send function, and its potential impact changes immediately. On 19 October 2026, Microsoft’s Securing the agentic insider made the problem explicit, arguing that enterprise agents require continuous monitoring and limits on their ability to act as risk changes.^[1] The question for a security team is concrete. Which assistant already has enough approved access to cause damage if somebody else starts steering it?

The link can be genuine. The instructions can belong to somebody else.

SearchLeak offers a particularly uncomfortable example. In research published in June 2026, Varonis described a one-click attack chain against Microsoft 365 Copilot Enterprise Search. Attacker-controlled instructions reached the assistant through a link, and the chain combined prompt injection with a rendering race condition and server-side request forgery to expose data available in the victim’s context. Microsoft remediated the vulnerability.^[2] This was more than a model saying something inappropriate. It was a route from an externally supplied instruction to enterprise information and then to an outbound disclosure. The familiar appearance of the service carrying the link did not establish who had written the task it caused the assistant to perform.

Varonis’ August RovoBlast disclosure described a related failure in Atlassian’s Rovo. A crafted link seeded instructions into a user’s existing session, drawing on the assistant’s access to Jira, Confluence and connected sources. The researchers reported that Atlassian fixed the issue following disclosure.^[3] The scope depended on the environment and the permissions available to that user; the assistant did not acquire unlimited access to every company using the product. That distinction is central to the risk. Respecting the user’s access rights can still leave a dangerous path from hostile input to sensitive information. The attacker can exploit an authority already present, rather than persuade the organisation to grant a new one.

Some failures sit lower in the software stack. Microsoft’s May 2026 research on Semantic Kernel documented two subsequently fixed vulnerabilities through which model-controlled tool inputs could lead to code execution or host-side file writes. One affected a particular Python search configuration; the other involved an exposed .NET helper function.^[4] These cases require patching affected implementations as well as improving agent governance. They also show why “the model refused our test prompt” is an incomplete security assessment. The tool parameters, output handling and host permissions determine what a successful bypass can do. An assistant’s reassuring answer is not a substitute for validating the code paths it can invoke.

The dangerous permission is often the combination

There is a temptation to treat each connector approval as an isolated question. Can this employee read the contract? Yes. Can they see the customer record? Yes. Can they search a mailbox? Yes. The agent may inherit those answers through legitimate delegated access. But an assistant changes the cost of using those permissions together. Material that a person would have to locate, read and reconcile can become available within one task. An access boundary has not necessarily been bypassed, yet the speed and breadth of synthesis have changed. Security reviews should therefore examine the combinations a workflow enables, including what can leave the environment after those sources have been joined.

Take a sales forecast, a list of unsettled invoices and internal correspondence about an unusually large customer. None needs to contain a document titled “Confidential acquisition plan” for an assistant to propose a commercially sensitive conclusion when the sources are combined. The conclusion might be accurate, mistaken or partly supported. Each possibility creates a different risk if it is retained or circulated as fact. Calling this an “inference permission” highlights a legitimate governance concern, but it should not imply that a company can reliably grant or deny each thought inside a language model. The enforceable controls are around eligible sources, permitted combinations, sensitive outputs, retention and subsequent actions. Those are the places where an organisation can test whether policy actually holds.

The scale of deployment makes those reviews harder to postpone. Microsoft’s 2026 Work Trend Index reported 15-fold year-on-year growth in active agents in its Microsoft 365 ecosystem, rising to 18-fold in large enterprises. Its published telemetry covers March 2025 to March 2026 and expresses growth as ratios, rather than absolute agent counts.^[5] That does not tell us how many agents in any particular organisation are unsafe. It does mean that an inventory based on last year’s approved chatbot list can miss a changing population of operators, connectors and owners. Count the deployed agents, then inspect their effective reach. Ten assistants with narrow access can create less exposure than one assistant connecting finance, HR, internal chat and unrestricted outbound tools.

Closing the chat may leave the risky context behind

Memory adds another dimension to the access review. An assistant may use a conversation history, a persistent notes store, a retrieval index or a cache of previous tool results. Those mechanisms are not interchangeable, but they can all carry information into later work. A finding collected for one task can become background context for another. If its source and uncertainty disappear during summarisation, an allegation can return as an apparent fact. Microsoft’s guidance on memory and context poisoning describes how manipulative material in persistent context can influence future responses and actions.^[6] A system that rejects an instruction when it first appears can still need protection when related content is stored, rewritten and retrieved later.

For a practical example, imagine a support assistant reading an external message that claims a supplier’s new bank details have already been verified. The assistant should be able to record that somebody made the claim without promoting it into a trusted organisational fact. If the statement is saved as “supplier payment details verified”, the next task may begin with the crucial distinction already lost. A useful memory record keeps the source, date, status and scope beside the content. Customer A’s conversation should not quietly become authority in Customer B’s case, and a temporary investigation should not become an indefinite source of personal information simply because retaining everything makes retrieval easier.

Forgetting therefore needs an operational design. Decide which stores may retain task material, who can inspect them and what invalidates an entry. When a claim is corrected or a source becomes unavailable, determine whether derived summaries also need review. Deleting a visible chat should not be assumed to remove every persistent copy or downstream artefact; test the product’s actual behaviour. Equally, disabling retrieval does not erase material already exported into another system. Revocation has to consider the credential, the running task and the retained context separately. A control that stops tomorrow’s source query may leave yesterday’s summary available to an assistant that still has authority to send it elsewhere.

The approval button can quietly transfer the decision

Click to view full size

The next failure does not require a clever injection. An assistant drafts a recommendation, labels the case, routes it to the right queue and supplies a confident explanation. A busy reviewer accepts it. After enough routine successes, the review becomes a click. Formally, the human remains responsible. Operationally, the assistant’s recommendation has become the decision. This is a useful way to understand authority laundering: a generated assessment acquires institutional force through a workflow that no longer subjects it to meaningful scrutiny. The software did not need to gain an administrator role. It needed its output to become the normal basis for an action that somebody else was authorised to take.

The remedy is more specific than putting “human in the loop” on an architecture slide. The reviewer needs to see the proposed action, its affected recipient or resource and the evidence relevant to that consequence. Approval should attach to the action reviewed, with another check if material details change before execution. A permission to send one report to a named recipient should not cover a different attachment or a replacement address introduced later. For high-consequence decisions, track whether reviewers actually correct, narrow or reject recommendations. A queue with thousands of approvals and no recorded disagreements may indicate excellent work, but it can also indicate that the review stage has stopped operating as a control.

Recommendation and execution should therefore be distinct capabilities in the system. An assistant can be good at finding suspicious activity while still needing separate authority to notify customers, restrict accounts or disclose evidence to another organisation. Those decisions have different effects and often belong to different owners. Deterministic rules can authorise bounded, lower-risk actions without making a person approve every step. What should not happen is an agent expanding its own action scope because its explanation sounds persuasive. A second model repeating the first model’s conclusion is also weak evidence of independence if both rely on the same corrupted source or inherit the same permission mistake.

Give the operator boundaries that survive a bad instruction

Start with identity and attribution. The organisation should be able to distinguish the person who requested a task from the agent and application carrying it out. Where a platform supports dedicated agent identities, use them with appropriate grants. Where it relies on delegated user access, retain the application identity, user context and task attribution, and narrow the connector’s reach as far as the platform allows. A separate name in an inventory is not enough if the assistant still receives every capability available in the employee’s session. Test whether security can stop the agent’s access independently, how long issued credentials remain useful and whether work already queued can continue after the stop request.

The tool layer deserves the same attention as the connector layer. A tool should expose the smallest operation needed for its job, validate its inputs and enforce the caller’s scope outside the model. An assistant that only needs to prepare a reply does not need a general-purpose shell or an unrestricted HTTP client. A task that needs a known business endpoint does not need permission to contact every destination named in an email. Review tool metadata and changes to integrations as part of the application’s supply chain. Language can suggest an action, but the code receiving that suggestion must still decide whether the operation is permitted and whether the supplied parameters are safe.

Watch the whole sequence as well as individual events. A legitimate read can be followed by an inappropriate export. An external message can introduce a new recipient after the original task was approved. A retrieved document can be transformed into an attachment whose sensitivity is no longer obvious from its filename. Correlate the task, accessed sources, transformations and outbound operation at the point where consequences occur. Conventional identity controls, endpoint protection and data loss prevention remain useful here. They need to cover the actual execution path, including rendering, connectors and trusted intermediary services, rather than assume that controlling a model’s direct internet access closes every possible route out.

An action needs a record that someone can challenge

After an incident, “the AI decided” is an expensive dead end. Keep a reviewable record of who initiated the task, which agent version ran it, what sources it used, which tools it called and what authorised the final action. Where persistent memory influenced the task, preserve the relevant entry identifiers and versions, subject to the organisation’s data controls. This does not require recording private chain-of-thought or accepting the model’s retrospective explanation as a faithful account. The valuable evidence is the observable work: source references, actual tool arguments, policy results, approvals and returned outcomes. A polished narrative generated after the event can help navigate that evidence, but it cannot replace it.

Scam investigation makes this distinction especially clear. An AI may identify a suspicious message with no malware and no obviously malicious URL. Its conclusion becomes useful when an analyst can inspect the observed impersonation, payment request or pressure tactic. If analysis later links several identifiers, the evidence for each relationship matters more than the confidence of the summary. One supported connection does not establish common control of every related account. The investigation can scale while authority remains bounded: gather more evidence, propose a link and prepare an escalation, then apply the decision rules appropriate to the action. A false positive can expose a victim’s private information or damage a legitimate business if the last step runs without adequate scrutiny.

Cyberoo’s service areas sit close to that boundary. Scams.Report supports explainable verification and reporting; NothingPhishy focuses on digital risk and infrastructure disruption; MuleHunt focuses on evidence-supported intelligence about scam-linked payment destinations.^[7] As findings move between these functions and the organisations able to act, the source evidence and scope of the request should travel with them. An explainable assessment can support an investigation without becoming automatic permission to block, disclose or restrict. The same principle applies inside an enterprise assistant connecting email, documents and business tools: better analysis should improve the authorised decision, rather than quietly take ownership of it.

For the next access review, pick one agent that people already find useful. Map its effective sources and tools, inspect what it stores between tasks and trace a real recommendation through to execution. In a controlled test, change the proposed recipient after review, revoke a source the agent has already summarised and insert an external claim that contradicts the authoritative record. Check whether the controls stop the consequential action, whether the running task can be interrupted and whether an investigator can reconstruct the result. These are practical tests of delegated power. They reveal more than another demonstration that the assistant can refuse an obviously hostile sentence.

The question to leave with the owner is uncomfortable for a reason: if somebody steered this assistant while it retained all its legitimate access, what could they make it do before the organisation noticed? The answer should identify enforced limits and the evidence that those limits hold. It should also identify who can intervene when the task changes. You already know why the assistant was given access. Can you show where that access stops becoming authority?

FAQ