Half of this page is who may reach what. The other half is where the bytes actually go.
Every tool call passes a gate on the server, then a scope check whose arguments can subtract from what the caller may see and can never add to it. And everything the gateway builds stays at rest in a cloud account you own, while what a tool returns travels to your assistant's vendor. Both halves are true at once, and they are always said together.
Policy is not one list of permissions. It is three independent allow-lists, and a call has to clear all three. They are enforced on the server, inside each tool, on every invocation. The tool menu your assistant displays is a usability feature and deliberately fails open; it is not the boundary, and we do not describe it as one.
An operations lead reaching the readiness and analysis families; a junior analyst reaching search and document reading only; nobody reaching a tool their role does not name. A call to an ungranted tool stops at the gate, before anything is read.
Groups, records or subfolders. This is the dimension that lets one team see its own matters and not another team's, and it is the one an adversarial probe is aimed at first.
A classification over the content itself, so that a role with access to a record still does not see the class of material it has no business seeing. Classification is derived partly from your folder conventions, which is why the taxonomy is a prerequisite rather than a nicety.
A person's effective policy is resolved in a fixed order every time, from their verified identity rather than from anything the assistant sends. An unrecognized person does not get a limited view. They get nothing.
In the one real build, an adversarial cross-scope probe returned zero forbidden rows. That is a real result, and it is one test on one deployment where every live user holds a full grant. It is evidence that the control works, not a record of restricted users exercising it in production. The rest of that accounting is on what the gateway does not claim.
Enterprise search products often carry native permission fidelity from the source system. That is a genuine strength of theirs.
We make no residency claim for this product, anywhere, in any wording. What we can do is tell you precisely which things live in the account you own, which things cross to your assistant's vendor on every tool call, and whose agreement governs each leg. Read the third column as carefully as the first two: most of this boundary is made of contracts you already hold.
| The thing | At rest, in the account you own | Travels to your assistant's vendor | Whose agreement governs it |
|---|---|---|---|
| The mirrored documents | ✓Yes, in your storage | △Only the passage or page range a tool returns | Yours, with your cloud provider |
| The vector index | ✓Yes | ✕Never. Vectors are not returned | Yours, with your cloud provider |
| Confirmed facts and canonical tables | ✓Yes | △The values a tool returns, with their citations | Yours, with your cloud provider |
| Generated artifacts, such as a workbook | ✓Yes, written in your account | △Links, and whatever the assistant is shown | Yours, with your cloud provider |
| The read-only source credential | ✓In a secret store, nowhere else | ✕Never | Yours, with your document platform |
| What a tool returns: passage, figure, scaffold | △Produced there | ✓Yes, on every call. This is the trade | Yours, with your assistant's vendor |
| The arguments the assistant sends | ✓Received and checked there | △Composed there, by the assistant | Yours, with your assistant's vendor |
| The conversation and the assistant's prose | ✕Never in your account | ✓Lives there. We never see it | Yours, with your assistant's vendor |
| Anything at all, on our infrastructure | ✕Not applicable | ✕No | Contractually forbidden. We host none of it |
Judgment, not measurement, in one place: "only the passage a tool returns" depends on what your people ask for. A person who asks the assistant to read a whole document will send that whole document's text to their assistant. The control is the scope, not the size.
Everything at rest stays in your account, and what a tool returns travels to your assistant's vendor under your existing agreement with them. The two clauses are said in the same breath, every time. Compare with the platform, where no third-party assistant vendor is in the path at all: platform or gateway.
Every tool belongs to exactly one of four classes, and the classes are not interchangeable. This separation is the safety model, so it is worth a diagram rather than a paragraph.
A person confirms a fact under their own sign-in, and the decision is stored with who and when.
A workflow stage will not advance while its entry criteria are unmet. Forcing one requires a written reason, stored and shown from then on.
A workbook writes nothing when reconciliation fails, and there is no override for anybody.
What is missing comes back as a named gap with the action that closes it and the owner it belongs to, rather than as a silence a reader has to notice.
Exactly, because this is the easiest place on the site to write a sentence that is not quite true: writes are attributed, with who and when. Reads and tool calls are not individually recorded today. A firewall log, a role-assignment log and a cloud administrative trail all exist, but there is no per-invocation decision receipt, and because calls arrive from your assistant vendor's servers, a source address identifies the vendor rather than the person.
Today the answer is the one in the section above: writes are attributed, reads and tool calls are not. We publish no roadmap for this product, because a dated promise on a marketing page is made by somebody who will not be in the room when it slips. If per-invocation receipts are a condition of your sign-off, say so in the assessment and we will scope it as work rather than imply it as a feature.
Through your identity provider, as you would for anything else: remove them from the corporate directory and sign-in stops. Policy changes themselves are an operator task today. There is no client-facing administration screen for the gateway, so an access change is a request to us rather than a screen you drive.
What the server enforces is structural: scope is intersected server-side, so no instruction sitting inside a retrieved document can grant a tool the caller's role does not hold, and a denied scope never reaches retrieval. That is the server's guarantee, and it is the only one we make: the assistant side is not ours to harden, and we claim nothing about it.
Yes. Policy is a set of explicit allow-lists, and we walk through the resolved effect for each named role during the connect workshop rather than handing over a file and hoping. A policy change is a release we make, so what is in force is visible in the version you are running. That is the same posture as everything else we build: glass box, not black box.
Bring your security owner. The data-boundary conversation is the first one we have, and it is the one that decides which product you should be buying.