AI in the Tools You Already Use: Reading the Permission Model Behind Claude in Excel and Chrome

Embedded AI assistants like Claude in Excel and Claude in Chrome operate inside an existing application, reading its content and, increasingly, taking actions within it. The capability that genuinely changed is the shift from a model you visit to a model that works inside your existing tools, with the context and the permissions those tools already hold. That is a real gain in usefulness. It is also a quiet expansion of what the model can reach, and the enterprise story lives entirely in that expansion.

What embedding actually changes about access

A standalone assistant has the access you deliberately give it, a pasted document, an uploaded file, a typed question. The boundary is explicit and the user controls it. An embedded assistant operates inside an application that already has its own access, to the open workbook, to the data connections behind it, to the browser session and everything authenticated within it, and the assistant inherits that reach by virtue of where it lives.

This is the property that matters, and it is easy to miss. An assistant in the spreadsheet can read the financial model open in front of the user, including the sensitive assumptions and figures it contains, and an assistant in the browser can see the authenticated sessions, the internal applications, and the data on the pages the user has open. The convenience is exactly this inheritance. So is the exposure, and the two arrive together.

The action surface raises the stakes

Reading is one thing. The more significant shift is that these assistants increasingly act, filling cells, transforming data, navigating pages, filling forms, clicking through a workflow, and an assistant that acts inside an application can do consequential things within that application’s permissions.

A browser assistant that can navigate and submit is operating with the user’s full authenticated reach across every internal system that session can touch, and a wrong action there is not a wrong answer to re-read. It is a form submitted, a record changed, a transaction initiated, inside systems that assumed a human was driving. The failure mode is no longer a bad suggestion the user can ignore. It is an action taken on the user’s behalf, under the user’s identity, that someone has to notice and unwind.

The trade-off is worth naming plainly. Embedding the assistant in the tools people already use removes friction and multiplies usefulness, and it does so by granting the assistant the reach of those tools, which is far broader than the reach anyone would grant a standalone model deliberately. The usefulness and the exposure are the same property, and an organisation that adopts the first without governing the second has expanded its attack and error surface without recording that it did.

Operationalising embedded AI

The governance question for embedded assistants is different from the one for standalone tools, and treating them the same is the common mistake.

Scope of access is the first thing to establish. What can the assistant in the spreadsheet actually read, does it stay within the open file or reach the data connections behind it, and what can the browser assistant see across tabs, sessions, and authenticated applications. These are questions to answer before deployment, because the default reach is often broader than anyone assumed, and the answer determines the real exposure.

Action governance is the second and more urgent control. Consequential actions, anything that submits, changes a record, moves money, or alters a system of record, belong behind a human confirmation step regardless of the assistant’s confidence, so the assistant proposes and a person commits. An embedded assistant with unrestricted authority to act inside authenticated enterprise systems is an ungoverned actor operating under a real user’s identity, and no demonstrated helpfulness compensates for that. This is the same bounded-action discipline behind FORGE, where automation operates with scoped permissions and human approval gates on consequential steps rather than open authority. Data handling is the third, since embedded assistants process whatever they can see, which is frequently the most sensitive content in the organisation, and the retention, training-exclusion, and residency terms have to cover that content, not just the prompts a user types deliberately. Teams working through governance for AI embedded in enterprise tools should map the real access scope before enabling these assistants, because the reach they inherit is the exposure they create.

Where it fits

Strong fit for read-and-assist work inside the tools where it adds obvious value, analysis and transformation in the spreadsheet, research and summarisation in the browser, where the assistant helps and a human remains the one who acts on anything consequential.

Weaker fit for unrestricted autonomous action inside authenticated enterprise systems, for environments where the assistant’s access scope has not been established, and for any workflow where a wrong action carries real consequence and no confirmation gate sits between the assistant and the commit. Those need the access mapped and the gates built before adoption, not after an incident reveals the reach.

Embedded AI is genuinely useful precisely because it works inside the tools people already trust with sensitive data and authenticated access, and that is exactly why its governance deserves more scrutiny than a standalone tool, not less. The organisations adopting it well mapped what the assistant could actually reach and gated what it could actually do before turning it on. If embedded AI is spreading through your organisation, the exercise worth conducting is establishing what a browser assistant can see and submit across an authenticated session, because that reach is your real exposure and it is rarely as narrow as it looks.