Safeguard.sh Documentation Center

Identity Threat Detection (ITDR) & DLP

Roadmap — identity-attack detection (MFA fatigue, impossible travel, token theft, privilege escalation) with approval-gated response, plus data-loss prevention that reuses the DSPM classifier at the AI gateway, API, and export paths.

Identity Threat Detection (ITDR) & DLP

Roadmap — not yet available. ITDR and DLP are planned capabilities documented here for direction. They extend the shipped detection/response spine, DSPM classifier, and safety kernel, but the engines themselves are not yet available.

Two pillars on one spine. ITDR detects identity attacks and responds only through policy, approval, and the safety kernel — never auto-disabling an account. DLP prevents sensitive data in motion, reusing the DSPM classifier and enforcing at the AI gateway, API, and export paths without ever persisting raw content.

ITDR — identity threat detection (planned)

ITDR detectors will consume identity signals materialized from the SecOps event store and emit identity_threat findings. Planned detections:

CategorySignal
Impossible travelTwo logins whose implied velocity exceeds a physical threshold
Anomalous loginNew geo, ASN, device, or atypical time versus the identity's behavioral baseline
MFA fatigue / bombingA burst of denied/ignored MFA pushes — critical if immediately followed by an approval (post-fatigue success)
Privilege escalationAdmin-role assignment, elevated group adds, policy widening, new keys on privileged principals
Dormant / over-privilegedReactivated idle accounts; behaviorally over-broad privileges (via reused CIEM)
Service-account anomalyA non-human principal deviating from its narrow baseline
Token theft / session hijackA session or refresh token replayed from a new device/ASN/geo; concurrent geo-disjoint sessions
Risky OAuthHigh-scope consent to an unverified app; illicit-consent-grant patterns

Response (planned, gated)

Every ITDR response will be a SOAR connector action executed only through the safety kernel — never a direct identity-provider call from detection code. High-impact actions (disable account, revoke token, disable session) never auto-execute — they are held for human approval. Low-impact actions (force re-auth, require step-up) may auto-run per policy. Rate and blast caps prevent mass-disable, a kill-switch aborts everything in flight, and reversible actions are preferred.

DLP — data-loss prevention (planned)

DLP is deliberately designed not to be a second classifier — it is a set of enforcement points that call the shipped DSPM classifier on data in motion:

ChannelWhat it inspects
AI gatewayPrompts, responses, and tool I/O (extends the AI Gateway egress path)
API responsesSensitive data in API output
Export / bulk downloadSensitive data leaving through export paths
SaaS sharingOver-broad shares and public links containing sensitive data

Each channel supports monitor, redact, and block modes (enforce modes default-off), with policy defined per channel and category. Classification and redaction always route through the DSPM classifier — never a second implementation.

Safety model (planned)

  • Fail-open DLP. On any classifier or enforce error, traffic is allowed and an alert is raised — a DLP failure never breaks the protected app.
  • Never persist raw sensitive content. Violations record the matched category and a DSPM-redacted span only; there is no raw-content field by construction.
  • Elevated access control. ITDR/DLP findings are highly sensitive — tenant-scoped with tighter ACLs than normal findings, and every read is audited.

When it ships

ITDR findings (identity_threat) and DLP violations (dlp_violation) will flow into the single findings store under elevated ACL, fuse into SecOps XDR incidents, and map to SOC 2 / ISO / PCI / HIPAA controls. Gated by the ff.itdr and ff.dlp feature flags.

On this page