What We Learned Watching 50 Engineers Use Cursor for a Month

Eight risky pastes per engineer per week, dropping to 1.5 by week three. Zero hard blocks fired in thirty days. A team safety score that started at 60 and finished at 85. Those are the three numbers that came out of one cohort of 52 engineers across three US engineering teams running HeimWall in a private design partner study during April.

We expected to see API keys. We did, but they were not the story. The story was customer data and proprietary code, and the shape of behavior change once a manager actually had a signal to act on.

All numbers below are based on early HeimWall design partner data, n equals 52 engineers across three US engineering teams (one Series-B fintech, one Series-C developer-tools company, one mid-stage healthcare data startup). All three teams signed off on this writeup; no engineer or company is named.

Setup

The cohort ran HeimWall agents on macOS for thirty workdays. Cursor was the dominant tool across all three teams; two layered on Claude Code and Copilot Chat. The agent ran in soft-notify mode the entire month: 3-second toast on a flagged paste, no workflow break, no manager ping in real time. The Friday digest summarized the week. We watched only what the agent emits (category, severity, tool, hashed fingerprint, character count); no prompt content reached our cloud. Behavior observations came from post-study interviews. 84% of engineers used at least one AI coding tool in a given week, steady across all four weeks.

The pattern we expected

We expected secrets to dominate. API keys pasted accidentally, AWS credentials in a "why is this Lambda failing" question, OAuth client secrets in a stack trace. Every security vendor's pitch deck centers this category; Samsung 2023 still anchors how engineering leaders think about AI coding risk.

Secrets did show up. They were 22% of flags. Mostly staging access tokens, a few production connection strings, one AWS root key (the engineer rotated it inside the hour). On strict severity weighting, secrets contributed a disproportionate share of the score drag because Critical events compound. But 22% came in third.

The pattern we actually saw

Customer data was 41% of flags. Proprietary code was 28%. PII was 9%. Secrets was 22%.

The customer-data flags were the surprise. They were not dramatic. A senior engineer pasting a support ticket body into Cursor with "concise summary I can send to the on-call rotation." A junior pasting three rows of a production analytics export into Claude Code with "what is this column doing." A tech lead pasting an enterprise customer's reported bug, including the customer's name and dollar amount, with "draft a postmortem outline."

By classical DLP definitions, none were secrets. Not API keys, not credentials, not regulated PII fields the redaction rules were built to catch. They were trust violations. The customer expected their ticket to live in Zendesk, not in a third-party model's context window. The engineer, doing good work fast, did not connect the two thoughts in the four seconds between paste and send.

Proprietary code at 28% concentrated on engineers pasting algorithms they considered "the interesting part" of the codebase into Cursor for refactoring. Pricing logic. Risk-scoring functions. The matching algorithm at the core of the developer-tools company's product. None of it is a secret in the password sense. All of it is the company's competitive moat typed into a tool the company has no contract with, on a personal account in the median case.

AI coding observability is not Symantec for prompts. It is a different category of risk that the existing DLP shelf does not see.

What changed for the manager

The VP Engineering at the fintech had no signal at the start of the month. The Cursor admin pane covered roughly half the team. Copilot's compliance surface covered a different overlapping subset. Claude Code's enterprise logging covered nobody, because engineers were on individual accounts. Our pre-study question: "How many of your engineers leaked something this week?" His answer: "I have no idea."

By day thirty he had a Friday digest: weekly safety score, category breakdown, four-week trend, three engineer-level conversations worth having. Not a wall of prompts. Not a leaderboard. A signal.

Two of those three first-week conversations were about customer-data pastes from the same on-call rotation. He did not read a prompt. He sent a one-line Slack to the rotation lead asking whether they had a redaction step on the staging seed script. They did not. They added one. That category fell 70% the following week.

The team safety score moved from 60 to 85 over four weeks. The score is a 0 to 100 composite, weighted by severity (Secret > PII > ProprietaryCode > Other) and normalized per active engineer-week. 60 to 85 is a structural improvement, not a noise band.

The safety score is an operational signal, not a performance signal. None of this data appeared in any performance review at any of the three companies, by contract. The improvement was three coaching conversations and one tooling change, not punishment.

What changed for the engineer

The behavior shift on the engineer side was the cleanest finding. Flag rate started at a mean of 8 paste events per engineer per week. By the end of week three, the mean was 1.5, a drop of 81%.

The drop was driven almost entirely by the soft notification: a 3-second toast at the moment of paste, category badge, one-line policy reference, no workflow break. Engineers described it the same way half the time in interviews: "It made me notice what I was about to do." They did not need a block. They needed a beat of awareness.

Zero hard blocks fired in thirty days. The product ships with hard-block thresholds for the highest-severity categories (production credentials, AWS root keys), but no event in the cohort triggered them. This validates an invariant we built the architecture around: soft notifications by default. If hard blocks fired on more than a few percent of pastes, engineers would route around the tool within a week.

Behavior change held within category. A soft notification on a customer-data flag changed customer-data behavior; it did not transfer to secret-shaped pastes from the same engineer.

What this means for the category

For a decade DLP has been a block-count product. AI coding observability is a different shape. The metric to optimize is not block count. It is behavior change: do engineers paste fewer risky things over a four-week window, holding detection coverage constant. Block count goes to zero in a healthy month, because a healthy month is one where engineers catch themselves before the agent has to.

This is closer to security awareness training than to traditional DLP. The output of a good awareness program is not "we caught more phish," it is "click-through dropped under 2%." The output of a good AI coding observability program is not "we blocked more pastes," it is "the safety score is trending up and the Friday digest is shorter every week." The product is the conversation the signal prompts, not the alert volume.

Where this goes

We are opening an alpha for design partners. macOS first, US engineering teams, 200 to 5,000 engineers. The first cohort of three was small enough to interview every participant; the next will be larger.

If you recognized your team in any of the patterns above:

1. Join the waitlist at heimwall.ai. We reach out personally to the design partner cohort.
2. To talk about the early-access program, on-prem, or BYOK before public launch, email founders@heimwall.ai. We read every reply.

Thirty days, 52 engineers. Eight pastes a week to one and a half. Sixty to eighty-five. Zero hard blocks. Manager sees signal, not content. Not for performance review. That is the shape of the product, and the cohort confirmed it works.