Trust model
Seven promises that are properties of how the system is built rather than settings somebody can change.
On this page
Seven promises. Each is a property of how the system is built rather than a setting somebody can change, which is why they come this early — a control that can be switched off is a control a reviewer has to audit the configuration of.
| The agent never elevates | It runs as the device user. Some controls therefore report unknown rather than guessing, which is the honest answer |
| The agent never executes what it finds | Discovering that an AI coding agent is installed does not involve running it |
| Delivery is off until configured | With no remote URL, nothing leaves the machine at all |
| There is no way to disable certificate verification | No config key, no environment variable, no flag — and there never will be |
| The credential is not in the config file | There is deliberately no token key in the configuration, and no --token argument |
| A device belongs to exactly one organisation | And only somebody inside that organisation can release it |
| Conversation content is off by default | Enabling it takes a deliberate act, records who did it and on what lawful basis, and is auditable per read |
On the device
Two writers, one of them policy
Your deployment
Two paths that share no code
People
Reading, not writing
Devices never touch the identity provider, and no human credential can reach a device's surface. The organisation a request belongs to always comes from the verified token, never from a parameter.
Why "never elevates" is the load-bearing one
An agent that asked for administrator rights would be able to answer more questions, and would be a
new privileged process on every machine in the estate — installed to reduce risk. So it runs
unprivileged, as the person whose machine it is, and where that means it cannot read something, the
signal comes back unknown and the console shows unknown.
That is a worse-looking dashboard and a better product. The alternative is a green tick derived from a measurement nobody took.
How a device proves who it is
Enrolment never puts a shared secret on a machine as its identity. Two paths, and both end with the machine holding a credential of its own:
- One machine. The agent prints a short claim code and waits. Somebody signed into the target organisation types it into the console. There is deliberately no way to name an organisation from the command line — the tenant is always the approver's choice, not the installer's.
- A fleet. One enrolment secret with a device ceiling and an expiry, delivered by your management tool in a file, never as a command-line argument — because install commands are visible to anything that can read the local process list.
A leaked fleet secret can create fake devices and read nothing. Revoking it blocks new devices and leaves every enrolled device reporting, because each holds its own credential — so rotation is not a fleet outage.
Tenant isolation
The organisation a query runs against is never taken from an argument. It is derived from the authenticated caller, on the server, every time — so there is no request shape that asks for another tenant's data, rather than a check that could be forgotten on one endpoint.
What is not built, and matters for a review
- One control, not a control layer. endlayer measures and grades, and stops one thing: sensitive data in a prompt, which the agent warns on, redacts or blocks on the device before it leaves. It does not quarantine a file or stop an agent's action; the rest of the designed control layer is explicitly not shipped.
- No findings routing. Nothing is sent to a SIEM or a ticketing system yet.
- Self-hosting is a supported shape rather than a self-serve download. See where it runs.
The full trust model, including the two authentication paths in detail and the structural argument for each promise above, is in the full documentation.