Set a DLP profile on a rule

An access and data rule can enforce an Enterprise DLP (data loss prevention) data profile through the rule's dlp object (dlp.profileId). The profile itself is defined in Enterprise DLP, a separate service, so this is a two-part task: look up the profile ID in the DLP API, then attach it to your rule.

Use this when: you want a rule in the Prisma Browser to apply an existing Enterprise DLP data profile (for example, to detect and block sensitive content on upload or in the clipboard).

Prerequisites: a Super User service account and the environment variables from Getting started. Access to Enterprise DLP for the same tenant.

1. Find available DLP profile IDs

DLP data profiles are managed by Enterprise DLP, on a different host (https://api.dlp.paloaltonetworks.com) and documented at pan.dev/dlp/api/. List the profiles to discover valid IDs; the profile ID is content[].id.

GET https://api.dlp.paloaltonetworks.com/v2/api/data-profiles

curl -sS "https://api.dlp.paloaltonetworks.com/v2/api/data-profiles?page=0&size=50" \
  -H "Authorization: Bearer $PB_TOKEN"

Response (shape)

{
  "content": [
    { "id": "11995044", "name": "PII - strict" },
    { "id": "11995051", "name": "PCI - block upload" }
  ]
}

Fetch one profile by ID with GET /v2/api/data-profiles/{resourceId}.

note

The DLP API is a separate service. It uses a different host and its own access. The Prisma Browser does not list DLP profiles; it only references them by ID. The token must be authorized for both services on the same tenant.

2. Attach the profile to your rule

Set dlp.profileId on the access and data rule. Use the id value from the DLP API (the same string shown in the Enterprise DLP UI).

export RULE_ID='0RLEXAMPLEACCESSRULEXXXXXXX'

curl -sS -X PATCH "$PB_API_BASE/policy/access-and-data/rules/$RULE_ID" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "dlp": { "profileId": "11995044" },
        "dataControls": {
          "fileProtection": {
            "fileUpload": { "action": "block" }
          }
        }
      }'

Response (200):

{ "id": "0RLEXAMPLEACCESSRULEXXXXXXX" }

caution

Pair the profile with data controls. The profile defines what sensitive content is; the rule's data controls (here, fileProtection) decide what happens when content matches. dlp.profileId needs at least one inline data control on the rule; a profile on its own returns 400.

caution

dataControls.dlpProfileId is deprecated. Use dlp.profileId; the same applies to dataControls.dlpProfile (now dlp.profile) and dataControls.bypassDlpProfileValidation (now dlp.bypassProfileValidation). The old locations still work during the deprecation window and will then be removed.

caution

The ID is validated. It must reference a data profile that already exists in Enterprise DLP for the same tenant, or the rule write returns 400. The Policy API resolves it to an internal reference at write time; you never supply or see that internal ID.

3. Confirm and publish

Reads return the profile as an expanded object rather than the flat ID:

"dlp": { "profile": { "id": "11995044", "name": "PII - strict" } }

To unlink the profile, send "dlp": { "profileId": null } in a PATCH.

Publish to enforce it:

curl -sS -X POST "$PB_API_BASE/configuration-management/draft/publish" \
  -H "Authorization: Bearer $PB_TOKEN" -H "Content-Type: application/json" \
  -d '{"description": "Attach DLP profile to finance rule"}'

Returns 201 when a new active version is created.

Tips and gotchas

• Profile-control compatibility is validated. Some controls only work with certain profile types; an incompatible pairing is rejected with 400. To save anyway (the incompatible control becomes a runtime no-op), set dlp.bypassProfileValidation: true. Use this deliberately. Controls that are entirely unsupported for the profile's content type are rejected even with bypass on.
• Detection confidence (on-device profiles). dlp.detectionConfidence is relaxed (the default, more matches) or strict (uses the profile's own confidence, fewer matches). It is valid only when the rule links an on-device data profile; a rule with no profile, a cloud-assisted profile, or a block action rejects it with 400, and bypass does not change that. Changing the profile resets it to relaxed.
• Same tenant, both services. The DLP profile and the Browser rule must belong to the same tenant.

Related

• Manage login and data controls, Access and data rules
• Reference: Enterprise DLP API