DLP: `patterns get` and `profiles get` blocked by upstream API 400

[cdot65]

Summary

`airs runtime dlp patterns get ` and `airs runtime dlp profiles get ` return `AISEC_CLIENT_SIDE_ERROR:API error 400` against live tenants. Root cause is server-side at `https://api.dlp.paloaltonetworks.com\` — reproducible via raw `curl` with the same OAuth token. Filed upstream: cdot65/prisma-airs-sdk#162.

Workaround

Use `list` and filter client-side:
```bash
airs runtime dlp patterns list --output json | jq '.content[] | select(.id == "...")'
airs runtime dlp profiles list --output json | jq '.content[] | select(.id == "...")'
```

Tracking

• Upstream: cdot65/prisma-airs-sdk#162
• Surfaced during PR #78 live validation matrix
• Known-issue notes added to `docs/runtime/dlp/{patterns,profiles}.md`

Close once SDK#162 resolves and the CLI commands work end-to-end again.

[cdot65]

Update 2026-05-23 — scope is broader than GET-by-id

Smoke test against the same tenant (CLI v2.9.0, SDK v0.9.2) found three additional DLP endpoints returning the same generic 400 Bad Request with empty problem-detail body. Same fingerprint as the originally-filed GET issue ({type: about:blank, title: Bad Request, status: 400, instance: <path>, timestamp: ...} — no field-level detail).

Expanded matrix

Endpoint	Status	Notes
GET /v2/api/data-patterns/{id}	400	Original report. Also affects custom patterns, not only predefined.
GET /v2/api/data-profiles/{id}	400	Original report.
POST /v2/api/data-profiles	400	New. Reproduced with three body variants (minimal multi_profile, expression_tree with 3-level nesting, verbatim clone of an existing working custom profile). Direct curl repro below.
PATCH /v2/api/data-patterns/{id}	400	New. PATCH against a freshly-created custom pattern (CREATE returned 201; PATCH then returns 400).

What works

• LIST on all four resources (patterns, profiles, dictionaries, filtering-profiles)
• GET on dictionaries and filtering-profiles
• POST on data-patterns ✓
• DELETE (soft-archive) on data-patterns ✓

curl repro for POST /v2/api/data-profiles

Body is a stripped clone of the existing working profile asdfafdsadsa (server-assigned fields removed, new name):

curl -sS -X POST 'https://api.dlp.paloaltonetworks.com/v2/api/data-profiles' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{
    "name": "cli-smoke-clone-20260523-200415",
    "description": "throwaway clone",
    "profile_type": "advanced",
    "detection_rules": [
      {
        "rule_type": "multi_profile",
        "multi_profile": {
          "data_profile_ids": [11995018, 11995012, 11995029],
          "operator_type": "or"
        }
      }
    ]
  }'

Response:

HTTP/1.1 400
content-type: application/problem+json

{
  "type": "about:blank",
  "title": "Bad Request",
  "status": 400,
  "instance": "/v2/api/data-profiles",
  "timestamp": "2026-05-23T20:04:37.106241916Z"
}

Hypothesis

Same root cause as GET-by-id: a validator (or middleware) on this tenant rejecting requests without surfacing the failing constraint. Suggest pulling server logs for instance: /v2/api/data-profiles at the timestamp above to identify the rejecting validator and have it return errors[] per RFC 7807.

Impact

• runtime dlp profiles create|patch|replace all blocked → effectively read-only for profiles via API
• runtime dlp patterns get|patch|replace all blocked → effectively LIST + CREATE + DELETE only

Workarounds (CLI-side)

• profiles list --output json | jq '...' — filter client-side
• Mutations via Strata Cloud Manager UI

@claude — please track the expanded scope here; no SDK/CLI change required.