Policy Auto-Tuner

The Policy Auto-Tuner analyses learning-mode telemetry nightly and proposes evidence-backed candidate DLP, credential, and GenAI policy rules for administrator review. Instead of authoring rules by hand, administrators see what their users actually do -- which sites, content types, and data categories appear consistently across teams -- and can accept, reject, or snooze each proposal with a single click.

The system never applies rules automatically. Every proposal requires a human decision before it takes effect.

How Proposals Are Generated

Each night, the tuner:

1. Aggregates the last 28 days of learning-mode events (DLP, GenAI, and credential attempts) from all enrolled devices, weighting recent events more heavily with a 14-day exponential decay.
2. Groups events by cohort (the user's group from your directory sync) and mines frequent patterns: origin domains and content signatures that appear together for a large fraction of a cohort.
3. Synthesizes candidate allow or warn rules from those patterns. A rule is an allow candidate when the activity was predominantly allowed in learning mode; otherwise warn.
4. Scores each candidate with a deterministic counterfactual: replays the last 7 days to estimate how many redundant warnings would be suppressed and what residual risk remains.
5. Routes the candidate through a safety guard (see Safety guarantees) and ranks the list by combined score.

Proposals appear under Policy Review in the admin dashboard (/dashboard/policy-review).

Cold-Start Period

The tuner requires at least 10,000 learning-mode signal events before it generates proposals for a tenant. New tenants or tenants in early rollout will see the run status as "cold start -- skipped" until enough activity has accumulated. This typically takes a few weeks with a full organisation enrolled in learning mode.

Until the threshold is met, the run is logged (status skipped_cold_start) but no proposals are written.

Reading a Proposal

Each proposal card on the Policy Review page shows:

Element	Description
Proposed rule	The candidate rule diff: origin domain, conditions (content type, sensitive-data types), and the proposed action (allow or warn)
Cohort	The group the rule is targeted at; "all users" when no cohort label is known or the cohort has no matching group
Predicted impact	Estimated events affected, warns that would be suppressed per week, distinct users, and residual risk (sensitive-type events that would now be allowed)
Evidence	Top origin domains by volume, content signature breakdown, and redacted sample events (metadata only -- no file content, no user names)
Rationale	A plain-language explanation, e.g. "39 of 50 engineering users (78%) repeatedly used copilot.microsoft.com in learning mode."
Model card	The scorer type, window parameters, and min-support threshold used for this run

Proposals flagged for manual review are shown in a separate red-bannered section (see Safety guarantees).

Accepting a Proposal

Click Accept on a proposal card. The system:

1. Resolves or creates a managed policy named "Auto-tuned -- {cohort}" scoped to the cohort's directory group (or "all users" when the cohort is unknown).
2. Appends the candidate rule to that policy.
3. Publishes the policy through the standard policy pipeline with a full audit-log entry.
4. Records the decision in the proposal timeline.

You can override the target policy: expand the Accept dropdown and choose Add to existing policy to append the rule to any policy you select instead of the managed auto-tuned policy. This is useful when you want to consolidate several proposals into a single policy you already manage.

Policy changes propagate to enrolled extension instances within the normal policy sync interval (default 60 minutes).

Rejecting a Proposal

Click Reject to dismiss a proposal. You may optionally add a note explaining why. Rejected proposals are retained in the timeline for audit purposes but will not appear in future runs unless the underlying telemetry changes significantly.

Snoozing a Proposal

Click Snooze and choose a date to temporarily hide a proposal. On that date it will reappear in the pending queue for review. Use snooze when a proposal is correct in principle but you are not ready to apply it yet -- for example, while a migration or access-review cycle is in progress.

The Auto-Tuned Policy

When you accept a proposal, the rule is appended to the Auto-tuned -- {cohort} managed policy for that cohort. This policy is created automatically on first accept and is owned by the auto-tuner.

You can view, edit, or delete this policy from the standard Policies settings page like any other policy. If you delete the managed policy, the next accepted proposal for that cohort will create a new one.

Evidence and Privacy Model

The evidence shown alongside each proposal is aggregate metadata only:

• Origin domains and event counts.
• Content type and sensitive-data-category breakdowns (e.g. "email", "ssn").
• Redacted sample event rows -- file extensions only, no file names; timestamps; no user names or identities.

Per-user detail is available through a Show users link that is gated on the events:read permission and is separately audit-logged, consistent with other per-user activity views in the dashboard.

Raw file content is never stored by Surface Security -- only metadata and HMAC fingerprints reach the server.

Safety Guarantees

The auto-tuner never proposes block rules. Candidates are always allow or warn. Block decisions remain exclusively under administrator control.

Two categories of proposals are automatically routed to the red-bannered Flagged for manual review section and require explicit admin attention before any action can be taken:

Flag	Trigger	Why it requires review
Regulated PII	The candidate rule's coverage includes a regulated-data category (SSN or credit-card data)	Allowing or downgrading warnings on regulated data carries compliance risk
Weakens existing block	The candidate allow/warn rule overlaps with an origin already covered by an active block rule	The proposal would effectively weaken an administrator-set block

Proposals in the manual-review section are never automatically accepted; they require an administrator to explicitly read the flag reason and click Accept or Reject.

Data Shared with the Vendor Portal

When a tenant has enabled the Remote debug / support opt-in (available on supported license tiers), Surface Security sends a daily aggregate metrics payload to the vendor portal. This payload is used for fleet-wide tuner health monitoring and continuous improvement.

This send only occurs when the opt-in is explicitly enabled. Air-gapped and offline deployments never send. Customers who have not enabled the opt-in receive no change in behaviour.

The payload contains only aggregate operational counters. The following fields are transmitted:

Field	Description
submissionId	UUID v4, unique per send (idempotency key)
schemaVersion	Protocol version (currently 1)
tenantId	Your tenant UUID
generatedAt	Timestamp when the payload was assembled
windowStart / windowEnd	The tuner's analysis window boundaries
lastRunStatus	succeeded, failed, or skipped_cold_start
coldStart	Whether the cold-start threshold was not yet met
eventsConsidered	Total learning-mode events in the window (count only)
proposalsGenerated	Number of proposals produced in the latest run
proposalsByKind	Count of allow, warn, and manual_review proposals
decisions	Count by decision status (accepted, rejected, snoozed, pending)
acceptanceRate	Fraction of decided proposals that were accepted
manualReviewCount	Number of proposals routed to manual review
regulatedPiiFlagged	Number of proposals flagged for regulated-PII coverage
blockWeakeningFlagged	Number of proposals flagged for weakening a block
warnedEventVolumeWeekly	Count of warned events in the last 7 days
warnedEventVolumeBaseline	Count of warned events in the prior 7-day window (baseline)
adminReviewDwellSeconds	Average admin review dwell time in seconds (currently 0; follow-up)
scorerType	Ranking model in use (heuristic or lightgbm)
scorerVersion	Version identifier for the scorer
modelTrained	Whether a per-tenant LightGBM model was trained and loaded
pipelineDurationMs	Pipeline wall-clock time in milliseconds
errorCount	Count of pipeline errors (currently 0; follow-up)

No rule content, origin domains, content signatures, file names, or user identities are transmitted. The payload is strictly aggregate operational counters.

Related

• Security Policies -- the policy system that auto-tuner proposals feed into
• AI Usage Dashboard -- the closest dashboard analog for reviewing and acting on AI-activity signals