Ship AI edits users trust: five-part contract
A trustworthy AI editor is a host-app contract: scope the read, ask by default, name the always-ask actions, stop irreversible actions, and make undo native.
| By | Prompt & Product — Newsroom |
|---|---|
| Filed | 10 October 2026 |
| Read | 3 MIN |
The sidebar is the interface, not the model
You are about to let an AI edit a document your team owns. The Claude add-on for Google Workspace reached public beta on 6 October. The useful question is what the host app can show, test, and enforce before the file changes. A model can produce a plausible paragraph; the host app decides whether that paragraph can enter the file, who can see it, and how the user gets it back.
Designers often treat the model as the product. The model is the engine; the host app is the contract. If the assistant can read a spreadsheet, the user needs to know whether it can also read the email that explains it. If it can rewrite a slide, the user needs to know whether it can also share the file. The answer has to be visible before the first edit, so the user can stop the assistant before anything changes. A settings page after the fact does not do that work. The boundary needs to be part of the editing moment.
Five tests make an agent a co-editor
A trustworthy in-app editor should pass five checks before it touches user-owned content. Each check is small enough to test in a minute, and each one protects a different kind of user loss. Run them in the order a user meets them: what the assistant can see, how it asks, what it always asks, what it cannot do, and how the user recovers.
- Scoped read: the sidebar reads only the open file and enabled connectors, not the user's other Drive files, email, or calendar.
- Default-ask mode: ask-before-edits is the default, and accept-all-edits is the other mode.
- Named always-ask actions: Claude requires approval before inserting an image from a web address, adding a link, or removing a person's access.
- Hard stops: it cannot share the file, grant access, change ownership, create menus, or create scheduled automations.
- Native undo: each edit appears in Google's version history under the user's name, making Claude's undo equivalent to the user's own undo.
Scope keeps the assistant inside the file. That boundary is what makes the rest of the contract legible. If the user can say the assistant is in the file, not in the account, the user can reason about risk without auditing the whole workspace. The assistant becomes a tool with a known room, not a background process with unknown reach.
Default-ask makes speed a choice. The safe mode should be the starting state, and a faster mode should be opt-in. That ordering matters because a user can always choose more speed, but a user cannot easily choose back into caution after a bad edit. The default is the first promise the product makes.
Always-ask catches edits that create new dependencies. A new image can break when its source changes. A new link can point somewhere the user never chose. A new access change can lock a teammate out of a file they still need. Those are permission problems, and the model's confidence does not settle them. The pause is the design.
Hard stops keep ownership with the user. The user should decide who can access the file and what the file can do after the user leaves. An assistant that can edit text but cannot change who can enter the file or schedule its own actions stays inside the user's control. The boundary is visible even when the assistant is idle.
Undo makes recovery normal. Trust survives the first bad edit only if the user can reverse it without a support ticket. A recovery path that feels like the host app's normal editing behavior is easier to trust than a special AI recovery flow. The user should not need to remember that the change came from the assistant; the undo should simply work.
The edit surface is where trust is won
In Google Docs, Claude can propose text changes as cards that the user accepts or rejects one at a time. That pattern turns a model output into a reviewable object: the change is visible, with a name, a boundary, and a way out. The user does not have to imagine what changed. The card is the decision point where trust is built.
Copy that pattern on the edit surface. Show the proposed change before it becomes part of the file. Keep the user's cursor, selection, and ownership visible. Make the assistant's action a card, a diff, or a version-history entry, not an invisible change. If the user can reject one card, they can reject the next one; if they cannot, the feature has become an uncontrolled writer.
