Introduction

Your OVRSEA data is reachable by software in three ways. They differ in who is driving, how the caller signs in, and — most importantly — who is accountable for a write.

​

Pick the one that matches who is driving

​

How they differ

Every channel resolves permissions server-side against the account that signed in, so an agent works inside the same authorisation as the person it acts for — the same checks the equivalent Hermès screen runs, not a separate agent-only rule set.

​

Who approves a write, precisely

This is the part worth reading twice, because the answer is genuinely different per channel. REST API. There is no approval step. A call with a valid token performs the write immediately. Your code is the control. Purchase orders are the only thing it can write. MCP server. Every tool is published with the standard MCP annotations — readOnlyHint, destructiveHint, idempotentHint — so an assistant can tell a read from a write. We publish those signals, but we do not control how your assistant acts on them. Most assistants ask the user before running a tool that is not read-only; that behaviour belongs to the assistant, not to OVRSEA. Do not read destructiveHint as “everything you cannot undo”: it marks the clearest cases, and declining a quotation is not among them even though its prices do not come back. If you are wiring the MCP server into something unattended, gate on the action, not only on the flag. Ask Zach. Zach states what it is about to change before changing it, and waits for the person to agree — on a card for the most common actions, in the conversation for the rest. Confirming a change describes what that does and does not guarantee.

​

Where to go next