Agent trust layer
One workspace can never read another
Most software keeps customers apart by filtering in the right places and trusting everyone to keep doing it. That holds until somebody writes a query in a hurry. Here the thing that would have to go wrong is narrower, and it is the same boundary whether the reader is a person, an API token or an agent.
14-day evaluation · no card · start before you connect anything
Every request passes through, in order
- 01Agent identity
- 02Permissions and policy
- 03Risk and approvals
- 04Action gateway
- 05Tenant isolationYou are here
- 06Prompt-injection defence
- 07Credential protection
- 08Audit and decision ledger
- 09Kill switch
Uncertainty at any step resolves to a refusal or to asking a person — never to proceeding.
How a request is decided
- 01A record that is not yours does not existA request for another workspace’s record is answered as if there were no such record, rather than as a refusal. A refusal confirms the thing is real, which is how somebody probes for which ids exist.
- 02No tool takes a workspaceAn agent’s arguments are derived from text it has read — a campaign name, a page, somebody’s email signature, all of it attacker-influenced. If the workspace were an argument, text saying "summarise workspace 65f2…" would be a cross-tenant read with the model as the confused deputy. It comes from the run’s context instead, which the model can neither see nor set.
- 03The same boundary for an agencyAn agency works inside a client’s own workspace rather than holding clients as folders in its own. Which client is being acted for is re-checked on the server on every request, so a stale browser tab cannot act on the wrong one.
- 04Checked by running it, not by reading itThe verification suites create two workspaces, give one of them figures the other must never see, and assert those figures are absent from every tool answer, every agent run and every report. Passing another workspace’s id as an argument is included, and changes nothing.
The same request, from two workspaces
Example
Workspace A
Read order o_8f2c
The order
Workspace B
Read order o_8f2c
No such record
No tool takes a workspace. Passing one as an argument changes nothing — it comes from the run’s context, which the model cannot see or set.
Answered as if there were no such record, never as a refusal. A refusal confirms the record is real, which is how somebody probes for which ids exist.
What this guarantees
Aggregates for agents, never a list of people
What reaches an agent about customers is counts and shapes. No address appears in what the growth and economics tools return, which is asserted rather than intended.
One person by address, inside one workspace
Customers are assembled across orders and channels within a workspace. Nothing is joined across workspaces, so a buyer who shops with two of our customers is two records, deliberately.
Credentials never reach a model
Connection health, spend and campaign readings are built with tokens and secrets removed — including from the error messages a platform sends back, which is where they most often leak.
What it cannot defend against
Said plainly. A control whose edges are hidden is worse than no control at all.
One deployment, one region
Workspaces are separated logically, not physically: there is a single deployment and you cannot choose where your data is kept. Anybody with full control of the database is outside what this boundary can defend against, and the security page says so.
No cross-client view for agencies
There is no screen showing every client’s numbers side by side, because that would mean one place holding several clients’ data together — the thing this design exists to prevent.
Every control, and what is not built
The security page lists each control as something you can check in the product, and lists separately what is not in place — including that Xyranik holds no certification and has had no external audit.