DLP profiles: legacy `runtime dlp-profiles list` and new `runtime dlp profiles list` return divergent sets — blocks legacy removal

[cdot65]

Summary

Removal of the legacy airs runtime dlp-profiles list command is blocked pending product/API clarification: live verification shows it does not return the same data as the new airs runtime dlp profiles list (DLP namespace) command.

Context

Handoff (handoff-remove-runtime-dlp-profiles-cmd-2026-05-28.md) called for deleting the legacy command on the assertion it was fully superseded by the new namespace command. The handoff included an explicit gate: run both against the same tenant, diff the profile sets, and STOP if divergent. Diff is divergent.

Two distinct SDK paths

• Legacy runtime dlp-profiles list → src/airs/management.ts:385 → this.client.dlpProfiles.list() (SDK Management client, dlp_profiles flat array)
• New runtime dlp profiles list → src/cli/commands/dlp/profiles.ts:50 → SdkDataProfilesService → client.dlp.dataProfiles.list() (SDK DLP namespace, paginated PageDataProfileResponse)

These hit different backend endpoints.

Live diff (single tenant, same .env)

Commands run from ~/development/cdot65/prisma-airs-cli:

pnpm dev runtime dlp-profiles list --output json > /tmp/legacy.json
pnpm dev runtime dlp profiles list --output json > /tmp/new.json

	Legacy	New
Endpoint	Management dlpProfiles	DLP namespace dlp.dataProfiles
Returned	25	25 of 26 (paginated)
Profile IDs	empty strings	populated (e.g. 11995027)
Extra fields	none (name only)	type, profile_type, status, version
Shape	[{id,name}]	{items:[...], page:{number,size,total,returned}}

Set diff by name:

• Common: 24
• Legacy only: PII Basic Block All Data
• New only: Malware
• New reports total: 26 / returned: 25 — at least one more profile is unfetched in the first page.

Why this blocks removal

The two commands return overlapping but not identical profile sets and materially different shapes. Removing the legacy command without product clarification risks data loss for users who depend on it to see profiles not surfaced by the namespace API (e.g. PII Basic Block All Data).

Asks

• Product/API: confirm whether the Management dlpProfiles endpoint and the DLP namespace dataProfiles endpoint are intended to be equivalent, and if so why their results diverge for this tenant.
• If they are intentionally distinct (e.g. legacy lists predefined/built-in DLP profiles vs the namespace listing tenant-managed data profiles), the legacy command should stay and be retitled/redocumented rather than removed.
• If they are intended to converge, file an SDK/server bug for the missing/extra entries and the empty IDs in the legacy response, then revisit removal.

Out of scope for this issue

• No code changes proposed here; this is a verification block, not a fix.
• Companion docs handoff (handoff-docs-remove-dlp-profiles-refs-2026-05-28.md) should also be paused.

References

• Handoff (gate definition): handoff-remove-runtime-dlp-profiles-cmd-2026-05-28.md
• Related (merged): docs(mkdocs): flatten DLP entries in CLI Reference sidebar #225 (mkdocs-flatten-dlp)

[cdot65]

Decision: proceed with removal

Per maintainer (@cdot65) — override the equivalence gate. Ship the removal.

Resolution: the new runtime dlp profiles list (DLP namespace) is the canonical command going forward. We want a single command and that is the answer. Accepted trade-offs:

• PII Basic Block All Data (legacy-only): acceptable loss — appears to be a Management-side artifact, not a tenant-managed data profile.
• Malware (new-only): bonus — argues FOR the new command.
• Pagination 25/26: the new command's renderer should be checked to ensure it surfaces the full set (follow-up if needed, not a blocker).
• Empty legacy IDs vs populated new IDs: argues FOR the new command.
• Shape differences: documented in the migration note.

Next steps:

1. agent-primary proceeds with the deletion per the original handoff.
2. Migration note in docs/about/release-notes.md should call out the divergence so users who relied on legacy-only profile names know what to look for.
3. Closing this issue as resolved.