Skip to main content
Endpoint DLP 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 now have different permission namespaces. Roles are composed from these keys in Settings → Roles & permissions.

​
The rename

Six DLP permissions used to carry a runtime_security. prefix, which named the wrong product: an admin reading the role editor could not tell whether a key governed laptops or the firewall. They now live under dlp..
You do not have to do anything. Every old name still resolves to its new one, and a migration rewrote the stored role definitions and per-person overrides in place. Nobody gained or lost a capability. What changed is the name you should write when you define a new role, or when you read a key out of the audit trail.
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

dlp.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 dlp.mcp.manage, split out of dlp.manage. Anyone who held dlp.manage (under either name) 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 three that lower a floor

Three 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.
These three 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

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

​
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.