Skip to main content
Endpoint is the desktop agent fleet on people’s machines. Runtime Security is the API firewall that sits in front of your models. They are different products with different blast radiuses, so they have different permission namespaces: endpoint. for the fleet and runtime_security. for the firewall. Roles are composed from these keys in Settings → Roles & permissions.

Built-in endpoint roles

Two roles exist for a workspace that runs the device fleet apart from everything else. Both can read Runtime Security (Apps, events, analytics) without changing it, and neither holds any write outside Endpoint. The viewer holds runtime_security.view, endpoint.view, endpoint.discovery.view, endpoint.devices.view and endpoint.device_errors.view. Diagnostics bundles stay out of its reach because they name hosts, accounts and infrastructure, and so do requests, because that key both sees and decides. endpoint-admin holds every endpoint key except five groups, which stay with the workspace admin because each one lets inspection stop or widens who may stop it:
  • Which devices may be paused at all (endpoint.protection.pause_policy).
  • Switching a workspace rule off on one device (endpoint.rules.override_workspace).
  • Uninstall codes, for one machine or the whole workspace.
  • Which roles count as a device’s owner (endpoint.device_owner_trust.configure).
  • Identity reveals, which are granted to a named person and never to a role.
The endpoint.desktop.* keys belong to the person who owns a device, not to whoever runs the fleet. See What people see in the desktop app.

Devices have their own keys

Reading the fleet and changing it are separate grants. These two used to ride on runtime_security.apps.manage. A migration copied them once to everyone who held that key, so nobody lost access. New roles should grant them directly. The developer role holds both by default.

The rename

The endpoint permissions have been renamed twice, and every older name still resolves to the current one.
  1. August 2026. Six permissions moved off the runtime_security. prefix, which named the wrong product, to a dlp. prefix.
  2. October 2026. The whole namespace became endpoint., to match the product name. A migration rewrote every stored role definition and per-person override in place.
Every other key that began with dlp. now begins with endpoint. and keeps the rest of its name.
You do not have to do anything. Nobody gained or lost a capability. What changed is the name you write when you define a new role, or when you read a key out of the audit trail. The API returns both spellings from /me/permissions for one release, so existing integrations keep working while they move over.
The firewall keys did not move. runtime_security.scan, runtime_security.view, runtime_security.view_latency, runtime_security.apps.manage, runtime_security.firewall.configure, runtime_security.mcp.manage, runtime_security.label, and runtime_security.delete keep their names.

One key became two

endpoint.manage used to cover the MCP tool profiles devices obey as well as the policies themselves. Approving a tool for laptops and accepting a changed tool definition on the firewall are not the same decision, so the device-side half is now endpoint.mcp.manage, split out of endpoint.manage. Anyone who held endpoint.manage (under any of its names) kept the split-out key, so nothing was taken away. New roles should grant the two separately if you want them separate.

The catalog

The nine endpoint.desktop.* keys are listed below.

The ones that lower a floor

Several keys let someone reduce protection rather than configure it, so none of them is implied by the older umbrella grants and each writes an audit record on every use.
The pause, override and uninstall keys were deliberately left out of the alias expansion for runtime_security.policy.manage and runtime_security.manage. Folding them in would have handed every existing policy editor the ability to switch protection off, which is a hole opened by a refactor rather than a decision anyone made. If you want someone to hold them, grant them explicitly.

Reading the inventory is not reading the policies

endpoint.discovery.view is separate from endpoint.view on purpose. Seeing which AI services people use says nothing about the company’s endpoint policies, so it is granted to every role that can see Runtime Security at all, while endpoint.view stays with the people who manage policy.

What people see in the desktop app

What the desktop app shows the person using a device is decided in two layers, and both have to allow it.
  1. The workspace switches. Endpoint → Configurations → Install → What people see in the desktop app has one switch per surface, Shown or Hidden. The Sign out switch also has Default, explained below. A switch is the most any device in the workspace shows. Changing them needs endpoint.device_ui.configure, which only admin holds by default, and every change is recorded in the audit trail.
  2. The person’s own permissions. For the rest of the surfaces below, the person who owns the device also needs the matching endpoint.desktop.* permission.
The nine endpoint.desktop.* permissions apply on a device the person owns. Admin holds all nine by default; no other built-in role holds any. Grant them to a role or to one person like any other permission. The Activity tab has no permission. Every person sees it unless the workspace switch hides it for the whole fleet. Hiding it is a decision for the workspace, not something a person is granted.
A device counts only with an owner that has been proved. The owner is the person the device is bound to, by the SSO sign-in or because an admin confirmed it with Confirm owner. An auto match, a pending device, a revoked binding, a device nobody has claimed, and a deactivated owner all count as no owner, and then none of the nine surfaces is shown. See Identity binding.
A person who is missing a surface is told that their organisation does not show it, never that something failed. Devices enrolled with a fleet token hide Sign out by default, because the organisation enrolled them. Devices a person signed in on show it. Set the switch explicitly to override either. An MSP operator working inside a client never holds the nine permissions. See Team & permissions.

Where each one is enforced

Where to next

Policies & agent API

What a policy controls, host rules and their actions, and the endpoints the agent calls.

Shadow AI triage

The four decisions you can reach for on a discovered service.

Devices & enrollment

The fleet console, enrollment tokens, and per-device actions.

Access management

Roles, invitations, keys, and the permission catalog.