What leaves the tenant, and what never does
The question a security reviewer asks about AI is not how good it is. It is which bytes leave, where they go, how long they stay, and what would happen if the answer changed.
What it is, and what it is not
A statement of exactly which data crosses which boundary when an agent runs, backed by the mechanism that enforces it rather than by a policy document.
It is not a promise to be careful. Every commitment here is either a contractual term with a model provider, a term in our own contract with you, or a property of the code — and each one is identified as which.
It is also not an argument that you should trust us. The useful version of this page tells a reviewer what to verify, including the parts where the honest answer is that a third party is involved.
The three boundaries
Tenant to tenant: nothing crosses, ever. Agents read through the same data-layer predicate as every other query, so an agent acting for one tenant cannot reach another's objects. This is code, not configuration — there is no setting that relaxes it and no administrator who can.
User to user, within a tenant: agents inherit permissions. An agent runs inside the acting user's access, so it cannot surface a part, document or programme that person could not open. Refusals are shaped so they do not reveal that something exists, because leaking existence through a refusal is still leaking.
Tenant to model provider: only what a specific request needs. When an agent runs, the objects relevant to that question are sent to produce that answer and are then discarded. Requests are made under a zero-retention arrangement: prompts and completions are not retained and are not used to train any model. That is a contractual term with the provider, mirrored as a contractual term to you rather than a setting.
The commitment that matters most
Your tenant content is never used to train, fine-tune or improve any model — ours or anybody else's. Not with anonymisation, not with aggregation, not on an opt-out basis you have to find and disable.
It is worth being precise about why that phrasing is chosen. Anonymised training on product data is not meaningfully anonymous: a bill of materials is a fingerprint, and a structure with your part numbers stripped is still your structure. An opt-out is worse than no promise at all, because it converts a commitment into a default that somebody has to notice.
Aggregate operational statistics — request volumes, error rates, which screens are slow — are used to run the service. Those contain no tenant content, no part numbers and no document text, and we will not publish them in a form that identifies you.
How it meets the rest of the product
Two controls reduce the surface further, and both are yours rather than ours. Bring your own key: requests go to your provider account under your contract, and Manufacturing PLM never holds the content. Disable agents at tenant level: no content reaches a model provider at all, agent features stop, and nothing else in the product is affected.
Embeddings for semantic search are computed and stored within the tenant, carry the object revision they were made from, and are invalidated when a revision supersedes. They are subject to the same predicate as everything else — a permission change takes effect immediately because filtering happens at query time rather than by index partition.
Every agent action is a hash-chained audit row naming the agent, the tier, the tools called and the revisions read. That is what makes a boundary claim checkable after the fact rather than only assertable in advance.
Cost governance is a boundary of a different kind: per-tenant budgets and per-agent caps, with stated degradation when a budget is reached rather than silent failure.
How it meets your ERP
ERP-sourced values reach agents as ordinary context, and they cross to a model provider under the same zero-retention terms as anything else when a question needs them. A cost figure in an agent's reasoning is a cached read of your ERP, and it is cited as such.
Nothing an agent does writes to your ERP. ERP-mastered fields are read-only beneath every agent, and outbound publication sits at the Execute tier as a stated constraint in the connector configuration rather than a toggle.
If your policy is that ERP-sourced data must not leave your infrastructure at all, the answer is bring your own key or disable the agents that read it. We would rather name that trade-off than describe a configuration that does not exist.
Where the boundary is
A model provider is a sub-processor, and that is a real dependency. It is named on the sub-processors page with its location and terms, and thirty days' notice applies before any change. A reviewer who cannot accept a third-party inference provider should use bring-your-own-key or run without agents.
Data residency is not yet regionalised. Production data is held in the EU by default with transfers under the standard clauses, but pinning a tenant to a named jurisdiction is a tracked commitment rather than a current capability. Nor is there single-tenant, on-premise or ITAR-segregated deployment.
Facts
| Tenant to tenant | Nothing crosses — enforced in code, not configuration |
| Within a tenant | Agents inherit the acting user's permissions exactly |
| To a model provider | Only what a request needs, then discarded |
| Retention | Zero — a contractual term, not a setting |
| Training | Never, on any basis, with or without anonymisation |
| Bring your own key | Requests go to your account; we never hold the content |
| Disable agents | Per tenant — nothing reaches a provider at all |
| Not offered | Data residency · single-tenant · on-premise · ITAR |
Frequently asked
Is our data used to train models?
No — not ours, not a provider's, not with anonymisation, not with aggregation, and not on an opt-out basis. It is a contractual term rather than a policy we may revise. Anonymised training on product data is not meaningfully anonymous: a BOM is a fingerprint.
What actually leaves the tenant?
Only the objects a specific agent request needs, sent to produce that answer and then discarded under zero-retention terms. Aggregate operational statistics — request volumes, error rates — also leave, and contain no tenant content, part numbers or document text.
Can an agent read another tenant's data?
No. Agents read through exactly the same data-layer predicate as every other query, enforced in code rather than in configuration. There is no setting that relaxes it and no administrator who can override it, because the predicate is injected below the query builder itself.
How do we reduce the surface further?
Two ways, both yours. Bring your own model key, so requests go to your provider account under your contract and we never hold the content. Or disable agents at tenant level entirely — nothing reaches a provider, and nothing else in the product changes.
Where are embeddings stored?
Within the tenant, carrying the object revision they were made from, and invalidated whenever a revision supersedes. They are subject to the same query-time permission filtering as everything else, so an access change takes effect immediately rather than waiting for any re-indexing.
Is the model provider a sub-processor?
Yes, and that is a real dependency rather than something to gloss over. It is named on the sub-processors page with its location and terms, and thirty days' notice applies before any change, with a right to object on data-protection grounds.
Can we keep data in a specific region?
Not yet. Production data is held in the EU by default with transfers under the standard clauses, but pinning a tenant to a named jurisdiction is a tracked commitment rather than a capability. Single-tenant, on-premise and ITAR deployment are out of scope.