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.
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.- August 2026. Six permissions moved off the
runtime_security.prefix, which named the wrong product, to adlp.prefix. - 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.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.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.- 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. - 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.
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.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.

