Reference
A glossary of the words this site uses. And what each means here, specifically.
Every term this site uses, defined once and used consistently everywhere else. Where a word has a loose industry meaning and a precise one here, both are given, because the gap between them is usually where a misunderstanding starts.
Each entry ends with the page that explains it properly. If you are reading a page elsewhere on this site and a term is linked, it points back here.
Most of this vocabulary was invented in the last two years. Which is why nobody agrees yet what any of it means.
The protocol
Assistants and tools.
The plumbing layer. None of these words say anything about permission, which is exactly the gap the rest of this glossary describes.
| Term | Definition |
|---|---|
| MCP | The Model Context Protocol: an open standard that lets an AI assistant call tools you run. It standardises how a tool is described and invoked, and deliberately says nothing about who may call it. That silence is not an oversight, it is a layering decision, and it is why a protocol-compliant server can still be wide open. See what is MCP. |
| Host | The assistant application the person is actually using, and the thing that decides which servers to connect to. Claude, Microsoft Copilot and ChatGPT are hosts. The host is chosen by your company, not by us, and nothing in this platform assumes a particular one. See which assistants. |
| Server | The service that advertises tools and answers calls to them. Here one hosted service serves every client, and isolation is by grant rather than by deployment, so a request reaches exactly the one project the caller holds a live grant on. If your review requires process isolation instead, the same code runs as a dedicated instance. See the security model. |
| Tool | One named operation with typed arguments: "describe the model", "read a slice", "search documents". It is the unit a grant permits or withholds, which is why permission here is finer than "can this person reach that system". A person can hold the tool that reads a summary and not the one that reads every record. See permission gates. |
| Connector | The adapter for one category of system: CRM, documents, tasks, planning model. Tools are named per category rather than per product, so a second adapter for the same category answers the same tool names and nothing downstream changes. Four connectors work today against twenty-six systems modelled, and that ratio is published rather than rounded. See what it cannot do. |
Permission
Who may reach what.
The words in this section are the product. If you only read one group, read this one, because every claim the site makes about safety resolves to something defined here.
| Term | Definition |
|---|---|
| Organization | A client, treated as an isolation class rather than as a label. A customer organization may only ever reach its own projects, and that is enforced both where grants are created and again where they are used, so a provisioning mistake cannot become a leak. A partner organization may hold grants across organizations, which is a different class and is named as one. See the security model. |
| Project | Exactly one database or environment, with its own connection secret held separately from every other. Nothing in the platform binds a project except the guard: not a tool argument, not a URL, not a claim inside a token. That single rule is what makes the rest of this list checkable rather than aspirational. See how it works. |
| Environment | Development, test, production. Each is a separate project with its own secret, which is why every answer names where it came from instead of leaving you to assume. An unlabelled number from the wrong environment is worse than no answer, and a request that could mean two environments is refused rather than guessed. See how it works. |
| Person | One row per human, platform-wide, keyed by verified email. Belonging to several projects is normal and governed rather than an error, which matters more than it sounds: the older design keyed access to a single tenant, so anybody working across two clients was ambiguous and failed closed. See how it works. |
| Grant | One person, one project, one set of skills. The only path to any system, with no second route and no runtime override that widens it. Revoking one takes effect on that person's next call, because the token they hold carries no permissions of its own to go stale. See permission gates. |
| Skill | A named capability a grant may include, expanding to a set of tools. An empty skill list grants nothing, and an unrecognised skill expands to nothing rather than to a sensible default. Both are deliberate: the safe reading of an unknown is the restrictive one. See permission gates. |
| Narrowing gate | One of four checks applied in turn to what a grant offers: the grant itself, ownership, what your administrator has switched on, and whether the system a tool reads is actually connected. Each can only remove a tool, never add one, so their order changes the reason given but never the outcome. See permission gates. |
| Deny by default | Every unknown is a refusal: no email, no grant, no project, an ambiguous project, an unreachable control plane. Outside development the server refuses to start at all when its authentication or its control plane is missing, rather than starting in a permissive state that looks healthy. See the security model. |
| Least privilege | The reviewer's term for giving somebody the narrowest access that lets them do the work. Most systems implement it at the level of a role or a database login; here the unit is a tool on one environment for one named person, which is a finer grain than a role and a much finer one than a shared credential. See permission gates. |
| Standing access | Access that persists because it was configured once, rather than being decided each time it is used. A read-only database login is standing access; so is an installed connector holding its own credential. There is none here: every call is decided against the live grant at the moment of the call. See what it cannot do. |
Identity
How a person is established.
Identity and permission are two different jobs, done by two different systems on purpose. Your directory answers who somebody is. Nothing else here does.
| Term | Definition |
|---|---|
| Identity provider | Your own directory, which answers who somebody is. It stays the only such list: we hold no directory, no passwords, no group memberships and no roles. What crosses to us after a sign-in is a verified email address and nothing else, so your joiners and leavers process stays the one you already run. See how it works. |
| Delegated access | Calling a third-party system as the person asking, using their own sign-in, so that system applies its own permissions to the request. It is the strongest arrangement available, because the narrowing is done by the system that owns the data rather than by us. It is also not available everywhere, and the table naming where it is available is published. See whose permissions apply. |
| Application credential | A single credential the service holds for a whole system. Convenient, and it means the system on the other end cannot tell your people apart, so every request looks identical regardless of who asked and any per-person narrowing has to be done by us. Where that is the case we say so rather than describing it as respecting your permissions. See whose permissions apply. |
| Admin consent | The approval a directory administrator gives before a third-party application may sign your people in. At enterprise size it is a process rather than a click, and it is usually the longest step in getting started, which is why it is the first one we ask you to begin. See what it takes. |
The record
What happened, afterwards.
The part most systems add after their first incident. Anybody can log what a system did; the row that matters in a review is the one where it said no.
| Term | Definition |
|---|---|
| Audit trail | The record of every call, allowed or refused, with who, when, which environment, which tool and why. It never contains the figures or document contents that came back, which is a deliberate limit rather than an omission: an audit trail that carries the data is a second copy of the data. Yours to read and export. See the audit trail. |
| Reason code | A stable name for why a call was refused, rather than a sentence somebody rephrased. Seventeen exist across identity, entitlement, state and dispatch, and a test freezes them, because this is data somebody reads three years later and it has to still mean the same thing then. Only three of them may ever be described as a breach. See the audit trail. |
| Append-only | Rows are added and never changed or deleted by the running application, and the job that eventually prunes old rows runs as a different database principal, so a compromised web process cannot erase what it did. Stated precisely because it matters: this is an application guarantee, not write-once storage. If your review requires the cryptographic version, say so early. See the audit trail. |
| Control plane | Our database, which holds organizations, projects, people, grants and the audit trail, and no business data of yours at all. Your figures stay in your systems and are read per request. Anything that would put client numbers in our database is a deliberate decision rather than an optimisation, because that boundary is the whole security story. See what we hold. |
Your own words
The rules you write. And who approved them.
| Term | Definition |
|---|---|
| Knowledge | Your written rules, vocabulary and guidance, approved by a named person before anything uses them, with version history and a revert. It arrives after every access decision and after the read, is carried and labelled as untrusted data, and cannot widen anything. It is deliberately not filtered for "injection phrasing": that filter is unwinnable, and one that appears to work is worse than none because everything after it assumes the text is safe. |
| Governed vocabulary | Your own phrase mapped to an approved set of members, so a question about "the centres" or "the core range" means what your people mean by it rather than what a model guesses. The mapping is written by you, approved by a named person, and versioned, so an answer given last quarter can be checked against what the words meant then. |
The alternatives
Words for the other ways of doing this.
Defined here without argument, because a comparison is only useful once both sides are named accurately. The argument is on its own page.
| Term | Definition |
|---|---|
| Retrieval-augmented generation | Usually shortened to RAG. Content is copied into a search store ahead of time, and at question time the relevant pieces are retrieved and given to the model. It is the right answer for a large body of text nobody needs permissioned per person, and the wrong one for numbers that change and access that has to be narrowed. See reading against copying. |
| Index | The copy that RAG retrieves from. The thing to ask about an index is not how fresh it is but whose permission model it applies, because it necessarily re-implements your access rules in another system. When that re-implementation drifts from the original, nothing fails: the answer is simply wider than it should have been, and it is confident. See reading against copying. |
| Write-back | Sending a change into the source system. Available through enabled workflows such as a planning upload or a record update, with a named target, appropriate permissions and a preview and approval step for important changes. Reading a system does not automatically grant permission to change it. See tools and actions. |
In your paperwork
The words your legal team will use.
| Term | Definition |
|---|---|
| Data processor | The party that handles personal data on instruction from the party that decides why it is handled. In this arrangement you are the controller and we are the processor, and the practical consequence is that we act on your instructions rather than our own judgement about your data. See the data processing terms. |
| Sub-processor | Anybody we use who could in principle touch data covered by that arrangement: hosting, the identity broker, error reporting. A serious review asks for the list before it asks anything else, so the list is published rather than sent on request. See sub-processors. |
| Retention | How long a record is kept before it is removed. Two different answers apply here and conflating them is the usual mistake: your business data has no retention period with us because no copy of it is kept, and the audit trail does, because a record of access is only useful if it outlives the access. See what we hold. |
The distinction
Two words that get used interchangeably and should not be.
Reading
- The query runs against your system at the moment somebody asks.
- Your permissions are whatever they are right now.
- Nothing exists to fall out of step, because nothing was stored.
Indexing
- Your content is copied into another store, once.
- That store re-applies a model of your permissions.
- When the model drifts from reality, the failure is silent and looks like a confident answer.
Neither is better in the abstract. Reading costs you a round trip to a live system and cannot answer questions about text nobody has structured; indexing is fast and cheap and re-permissions your content into somebody else's model of your access rules. The full argument, including when the copy is the right answer, is on reading against copying.