Why Your Team Needs an AI Safety Score (And How to Build One)

A VP of Engineering at a 700-person org asked us a question last month that every engineering leader is now asking on some Monday: "Are we getting better or worse at this?" By "this" he meant the daily volume of secrets, customer data, and proprietary code his engineers were pasting into Cursor, Claude Code, and Copilot. He had nothing to point at.

Every VP Eng and CISO we have spoken to has the same gap. They know AI coding adoption crossed from curiosity to critical path in 2025. They know there is a leak surface. They have no number on a Monday dashboard that tells them whether the surface is widening or narrowing. They are running engineering orgs the way SRE teams ran services in 2018, before SLOs: with vibes.

A safety score closes the gap. Here is how we build one, and the four traps that turn a good metric into a bad one.

What a safety score actually is

A safety score is a 0 to 100 weekly composite, per engineer and per team, that collapses several inputs into one number a manager can watch trend over time. Incident counts are lagging indicators of harm that already left the building. A safety score is a leading indicator of where harm is concentrating, before it ends up in a postmortem.

The shape we landed on has four ingredients:

1. Severity-weighted event volume. An AWS root key paste is not the same as a leaked email address. We weight Secret > PII > ProprietaryCode > CustomerData > Other, with severity multipliers (Info, Low, Medium, High, Critical) on top of category weight. One Critical Secret event counts more than fifty Low Other events.
2. Tool surface coverage. A team using one sanctioned tool reads differently from a team using four AI tools across three personal accounts. The score penalizes surface diversity in proportion to how much of it is unmanaged.
3. Temporal trend. Raw weekly counts are noisy. We apply exponential decay on event age across a rolling four-week window so a single bad week does not poison the trend, and sustained drift becomes visible by week two.
4. Per-engineer-week normalization. A team of 80 always produces more events than a team of 8. We normalize on active engineer-weeks so the score compares across squads of different sizes.

In rough pseudocode, the composition looks like this:

weekly_raw   = sum(event.severity * event.category_weight * decay(event.age))
coverage_pen = penalty_for_unsanctioned_surface(team.tool_distribution)
weekly_norm  = (weekly_raw + coverage_pen) / active_engineer_weeks
score        = clamp(100 - rescale(weekly_norm, p10, p90), 0, 100)

The rescale step is calibrated against a rolling cohort baseline, not a fixed threshold. A score of 80 is not "good" in some absolute sense; it means this team sits in the better half of the cohort distribution this week. The only number that matters is the trend on your own team, not the absolute value on a vendor poster.

Why a composite beats raw counts

Pick any two teams. Team A: 50 Low-severity events last week, all on sanctioned tools, in business hours. Team B: one Critical AWS root-key paste at 02:14 on a personal-account Cursor session. Which team had the worse week?

Raw count says Team A. Common sense says Team B. A safety score says Team B by a wide margin: severity weight, off-hours flag, and unsanctioned-tool penalty all stack on a single Critical event while Team A's 50 Low pastes barely move the rescaled total. The composite collapses the trade-off into one number a VP can scan in a Monday email. If a squad's score drops 12 points across two weeks, that is a coaching conversation. If it gains five, that is policy working as intended.

The four traps

Every metric gets gamed, and every metric gets misread by smart people in good faith. Four traps a safety score lands in if you build it lazily.

Trap 1: gaming. If engineers know "Secret" weighs more than "Other," they will route secret-shaped pastes through uninstrumented tools or a personal laptop. The defense is breadth of detection, not depth on one tool. We instrument every AI coding tool we can reach, personal-account sessions included.

Trap 2: false negatives reading as good behavior. A score that drops is supposed to mean fewer leaks. It can also mean the agent stopped detecting them, the engineer found a tool we do not yet cover, or a rule went silent. We render detection coverage in a panel next to the score so a gain alongside a coverage drop is a flag to investigate, not celebrate.

Trap 3: cross-team comparison. The number that shows your own trend is a terrible one for ranking squads. A platform team paste-drives a different baseline than a data team handling production records all day. We expose intra-team trends prominently and inter-team comparison only with a "different baselines" caveat next to the chart.

Trap 4: performance review. This is the one that breaks the premise if you get it wrong.

Not for performance review

The safety score is an operational signal, not a performance signal. It tells a manager where to focus this week, not which engineer to give a worse rating in December.

This principle is written into every customer contract HeimWall ships. The MSA prohibits use of safety scores or flag history in performance reviews, promotion decisions, or compensation decisions. Every page of the manager dashboard carries a non-dismissible banner restating the clause. If a customer uses HeimWall data for an HR decision, they are in material breach.

We did not add this clause for marketing reasons. The alternative is a product engineers sabotage within a week. If they believe the number will show up in their next review, they will paste on a phone, on a personal laptop, or use a tool we have not yet covered. Detection coverage collapses, the score goes up, the manager sees a friendly line on a chart, and the leak surface widens behind it.

A safety score that cannot be weaponized is one engineers will let work. A safety score that can be weaponized is one they will defeat. There is no middle ground.

Where this goes

This is the metric we built HeimWall around. Detection runs locally on the engineer's machine in under 50 ms p95. Categorization travels to our cloud; prompt content does not. The manager sees a weekly score, a category breakdown, and a trend, with no path to read prompt bodies outside an audit-logged Investigation Mode (second-factor step-up, written justification, employee notification within an hour, 24-hour time-box).

Manager sees signal, not content. That phrase is load-bearing for the architecture, and a safety score is the surface where it shows up first.

If you run SLOs on your services and want the same shape of leading indicator on your AI tooling:

1. Join the waitlist at heimwall.ai. We reach out personally to the first cohort of design partners.
2. To talk safety score weighting, on-prem, or BYOK, email founders@heimwall.ai. The design partner program is open.

The number is not the product. The conversation the number prompts is the product. A safety score is the difference between a Monday where a VP guesses and a Monday where they know what to ask their tech leads.