Security & Privacy
This page collects the product's security properties in one place — written for the person doing a security or privacy review before (or after) deploying an agent. The architecture behind these properties is described on How it works.
Where your data lives
On the appliance at your facility. Conversations, memory, workspace files, wiki, personality, skills, and schedules are stored on the device you own and physically control. They are not held in a shared cloud service.
Two things leave the device, both under your control:
- Encrypted backups — hourly, to cloud storage in the region(s) you select (or the nearest region on Automatic). Encrypted on the device before upload; the storage provider holds ciphertext only. See Backups.
- AI model requests — the content the agent needs a model to think about is sent to models via your facility's AI Models & Access account for processing. Model traffic is metered and governed by that module's arrangements; it is not used to train models.
Encryption
| Path | Protection |
|---|---|
| Browser ↔ device (all three connection paths) | Encrypted end to end (TLS) |
| Device ↔ Performance Hub (management, models, data access) | Outbound TLS with short-lived signed tokens |
| Backups at rest | Encrypted on-device before upload; per-facility key |
The backup encryption key is generated at pairing and held by Performance Hub on behalf of your facility — it is never stored inside the backups themselves, and never exposed in the browser.
Credentials and what a stolen device is worth
The device holds no long-lived secrets to your data:
- It authenticates to Performance Hub services with short-lived tokens derived from a per-device secret issued at pairing.
- There is no standing API key for AI models on the device.
- Removing the device from Performance Hub (Remove & reset) revokes its credentials immediately — a removed device can no longer reach your Performance Hub data, models, or notification channels, whatever state it's in.
What a physically stolen device does contain is its local data (conversations, files, memory). Mitigations: place the device in a secure area (placement guidance), and on theft, remove the device in Performance Hub at once to cut its credentials, then stand up a replacement from backups.
Network exposure
- The device makes outbound connections only — no inbound ports, no port-forwarding, no firewall exceptions. Its attack surface from the internet is nil beyond the outbound channels it initiates.
- Remote access to the agent flows through authenticated, tokenised tunnels — there is no direct public endpoint on the device.
- On your LAN, the direct-access path is likewise TLS-protected and requires a valid Performance Hub session token.
Who can do what
Three separate controls, enforced centrally on the Performance Hub side (not on device trust):
| Control | Governs | Page |
|---|---|---|
| Access control | Which people can open and chat with the agent | Access control |
| MCP access | Which Performance Hub data and capabilities the agent can reach | Connecting to Performance Hub |
| Budgets & limits | How much the agent can spend on models, and how fast | Budgets & limits |
Notable properties:
- Every chat message carries the signed-in user's identity — actions and conversations are attributable.
- Grants are attenuated to the granter: no one can give the agent more scope than they themselves hold.
- Performance Hub support access (on by default) can be switched off, after which support staff cannot open the agent without owner approval. See Access control.
- Command execution on the device is governed by the approvals setting.
What Performance Hub can see
- Operational telemetry — online status, health metrics (CPU, memory, temperature, disk), software version, connection state. This is what powers the device drawer.
- Backup metadata — that restore points exist, when, their sizes and regions. Restore-point contents are only decrypted when you browse or restore them through the module.
- Spend metering — model usage against the agent's key.
- Not a live feed of your conversations. Conversation content lives on the device; it transits Performance Hub infrastructure only as part of delivering the interface to your browser and is not warehoused as content.
Data lifecycle
| Event | Effect on data |
|---|---|
| Software update | No effect — data persists across all updates |
| Full restore | Device state replaced by chosen restore point (automatic safety backup taken first) |
| Remove & reset | Device storage erased (factory reset); credentials revoked; cloud backups retained under your facility and retention policy |
| Retention expiry | Restore points removed automatically past your retention window (7 days–5 years; pinned points exempt) |
| Move to another facility | Device data moves with the device; backup history remains at the original facility |
For data-residency requirements, pin backups to specific storage regions rather than Automatic.
Sensible deployment posture
For a high-sensitivity deployment, the tight configuration is: restricted access with a named allowlist and admins-only visibility, support access off, MCP scope limited to the facility with capability exclusions for anything the agent shouldn't touch, specific backup regions matching your residency needs, and the device in a locked comms area on wired Ethernet. Every one of those is a setting documented on the pages above — the defaults are deliberately more open (organisation-wide access, all capabilities) because most facilities want a shared, fully-capable agent.
Related pages
- How it works — the same architecture, explained constructively
- Access control · Connecting to Performance Hub · Backups
- Common questions