본문으로 건너뛰기
이 페이지는 아직 사용자의 언어로 번역되지 않았거나 번역이 기술 검토를 기다리고 있습니다. 아래에는 영어 원문이 표시됩니다. 영어 페이지 열기

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​

주의

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​