Lewati ke konten utama
Halaman ini belum tersedia dalam bahasa Anda, atau terjemahannya sedang menunggu tinjauan teknis. Teks asli dalam bahasa Inggris ditampilkan di bawah. Buka halaman berbahasa Inggris

Set up DLP rules for my team

Surfaces used: dashboard DLP Rules Editor (source of truth) + any enforcement surface (gateway, hooks, browser extension, SDK) Modes supported: Hosted Hybrid Tiers: Solo Teams

What you'll do​

Choose built-in detectors or write a custom regex, test it against sample inputs, publish, attach it where required, and verify delivery using Using DLP.

Why this is the right path for you​

  • If you want one canonical place where "what is sensitive" is defined, this is it. You do not maintain parallel lists in multiple tools.
  • The editor is the source. Deployment surfaces (gateway, coding hooks / SDK, browser extension) enforce it -- you author one ruleset, not a per-surface copy.
  • Check surface behavior and coding-agent coverage before relying on masking or a deny: support depends on the surface, event, and host mode.

When NOT to use this approach​

waspada

If you only need detection on one surface and do not care about consistency, the built-in default ruleset already covers most cases. The editor is for teams that want to add custom patterns or tune defaults.

5-minute setup​

Follow the DLP setup steps for availability, detectors, publication, and project attachment. Use the DLP Rules Editor to test your pattern before publishing.

Example custom rule (internal project code):

Name: Internal project codenames
Pattern: \b(BLUEBIRD|NIGHTHAWK|REDFIN)-[A-Z0-9]{4,}\b
Action: mask
Scopes: sdk
Attach to: Project "engineering"

Verifying it's working​

Use the delivery and audit checks. Test with synthetic data on the intended surface and confirm the actual outcome, including host enforcement when a mask match returns a deny.

Common follow-ups​

Reference​