Security and trust Access inside Oxelone
Access inside Oxelone
Three groups can act in your workspace: your own members, platform admins who run the Oxelone deployment, and, for a single machine, whoever holds a removal key or a break-glass key. This page says what each can do and what is recorded.
Your members
What a member can do comes from their role, and nothing else. See Roles and permissions. Permissions are checked on every call, so a member you remove is refused on their very next one.
Two permissions are held back on purpose:
- Read interaction content is separate from View machines. A Fleet operator, a Policy author and a Compliance reader see machines without reading prompts.
- Reveal held values opens the original text kept under the Restricted redaction mode, one block of one interaction at a time. Only Owner and Admin hold it. The console writes an audit entry before it shows the content, and the view lasts only while it is open.
Every sign-in, change of role, key and reveal is in the audit log, which Owner, Admin and Compliance reader can read.
Platform admins
A platform admin is an operator of the Oxelone deployment. The workspace's permission checks know nothing about platform admins: inside a workspace, what you may do comes from a role you hold there. A platform admin who is not a member holds no role in your workspace.
They can still enter it, and that is recorded. Each time a platform admin switches into a workspace, the audit log gets a workspace.platform_admin_access entry in the Access category, with the page they reached and whether they are also a member. An admin who is a member of your workspace is recorded too. Repeated calls into the same workspace within 15 minutes collapse into one entry, and a failed write is retried rather than skipped.
Entries for a platform admin entering a workspace, and for a reveal of held content, are kept for seven years by default. Their window cannot be shortened below that on Retention.
Two of your single sign-on rules treat platform admins differently: Require SSO does not stop their password, and single sign-on never signs one in. See Single sign-on.
The legal page says what operators see: service health and counts, not your content.
Break-glass and removal keys
Two different credentials can remove an agent from a machine. The console keeps them apart because they do different things.
| Removal key | Break-glass key | |
|---|---|---|
| Minted by | A member with Manage the fleet, on one machine's page | A platform admin, against a whole workspace |
| Works on | That one machine | One machine in the workspace |
| Effect | Authorises the uninstall. The machine's record is unchanged. | Removes the agent, and deletes that machine's record and everything collected from it. It works once. |
| Lifetime | Until another key replaces it, or the machine is uninstalled or deleted | Expires within 24 hours |
A break-glass key is for the incident nobody planned, when the machine to remove is not known in advance. It is stored only as a SHA-256 hash and shown once. No route reads one back. Minting, spending and revoking one are recorded in the audit log under Access, and a spent key stays visible with the machine it was used on.
See Deployment for removing a machine with its own key.
Reporting a problem
To report a security problem, write privately to security@oxelone.com. See Legal.