guide
Oct 20, 2026Developers can remove local AI controls. Measure AI DLP coverage per team, catch removed hooks, DLP-off and silent devices, and fix drift without MDM.
Every AI data loss prevention control that lives on a developer laptop can be turned off by the person using that laptop. They can delete a hook, pass a flag that disables redaction, or point a tool straight at the model provider.
That does not make the control useless. It means "we installed it in onboarding" is not a status report. AI DLP coverage is the ongoing check: which machines still have the hooks, which have DLP off, and which have gone quiet. This article is about measuring that. It is not about locking the laptop.
MDM (mobile device management) is the system that pushes profiles and can restrict settings on a company-owned computer. Many 10 to 100 person teams do not have it on every Mac, Linux box, and contractor laptop. You can still measure AI coding assistant security without it. You cannot honestly claim the control cannot be removed.
rclm-hooks-install --no-dlp keeps the hooks and turns redaction off.A hook is a program the assistant runs from a config file the user can edit. Claude Code, VS Code agent hooks, and Codex all document hooks as local configuration. GitGuardian's AI hooks docs describe the same category. None of that is a kernel lock.
Unapproved tools are a separate inventory problem. That checklist is shadow AI coding tools. This page starts after you have decided which tools you intend to control.
Prevention means the machine refuses the change. MDM or an endpoint agent that the user cannot uninstall can do that. ReclaimLLM does not.
Detection means you learn about the change and can show when it was fixed.
Hook DLP still prevents one thing when it is running: recognized secrets are replaced before the model request. Coverage is only the question "is that hook still running?" ReclaimLLM coverage is detection, not MDM.
A check-in is sent by software the user can edit. A signed policy helps you notice a bad cached policy. It does not stop someone from changing the program on disk. If they remove the client and the heartbeat, the main signal is silence, and only when some other activity shows the person is still around.
These detectors exist on Business and Enterprise plans. They are not on the free plan. AD-013c, which compares provider usage with gateway tokens, is Enterprise only.
| Code | What you see | When it fires | |---|---|---| | AD-010 | Hooks are no longer in the installed state, or the client sent an uninstall | On a later check-in, after the first one. The first check-in is a baseline, not an alert. Statuses that count: missing, partial, disabled, modified. An invalid policy signature is also recorded if a check-in reports one | | AD-011 | DLP is off and there is no active exception | On check-in. Warning by default. High if the org has turned on Require DLP | | AD-012 | A device that had been active stopped checking in | Once a day. It stays a warning, and it is meant to be read together with other activity. Short-lived environments such as Codespaces and dev containers are classified as ephemeral and do not send this email | | AD-013a | Gateway traffic from someone with no hook sessions | Once a day, and only if there is gateway traffic to compare | | AD-013b | A required provider is being called directly | On check-in, only for providers you marked as gateway-required. "Unknown" is not treated as a bypass. If you have not set required providers, this alert stays off | | AD-013c | Provider-reported usage and gateway tokens do not line up | Once a day, Enterprise only |
AD-011 rises to high when Require DLP is on. The other rows in this table stay at warning. The check-in reports what the client sent.
In the console, Enterprise → Coverage shows:
Filters include Uncovered, DLP off, Silent, and Direct routing. You can export CSV for an evidence folder. The export shows posture. It does not prove a developer could not have disabled the hook five minutes later.
Docs: coverage and the coverage dashboard.
Require DLP, set in the admin console, makes a check-in with DLP off a high finding unless an exception is active.
An exception has an expiry date you choose, up to 12 months, plus a written reason. It is not a fixed menu of 1 hour, 4 hours, and 24 hours. While it is active, AD-011 does not fire for that subject. When the date passes, the finding can fire again if DLP is still off.
Developers can see their own row under Settings → Device health. The repair command, which the console can copy, is:
rclm-hooks-install --repair
That reinstalls hooks and sends a fresh check-in. It is a terminal command, not a button that fixes the laptop remotely.
Optional heartbeat: rclm-hooks-install --heartbeat installs a user-level timer so a machine can check in even when nobody starts an assistant. If the org requires heartbeat, the installer adds that timer on its own. A heartbeat is still user-level software. An admin on the laptop can remove it.
A check-in is a small JSON post. It includes:
~/.reclaimllm/device.json), not a hash of the person's nameIt does not include source code, prompts, secret values, or the plaintext hostname.
Session capture is a different channel. If hooks are installed and a session is uploaded, that upload can contain prompts and tool output, with DLP replacements already applied. Do not read "check-in" as "we never receive project text." The check-in is the posture ping. The session upload is the work log.
Alert email for AD-010 and AD-011 follows the same rule as other ReclaimLLM security mail: detector, severity, client, and a link. Not the secret, the prompt, or source code. Immediate mail is not promised for every coverage row. Many of these findings are warnings and show up in digests. See Signals and the Signals walkthrough.
What is AI DLP? splits controls into four layers: tool settings, hooks, a gateway, and detection. Coverage answers a narrower question about layer 2: are the hooks still installed, and is DLP still on?
Findings land in Signals, where you can acknowledge, resolve, or dismiss them. Resolve is appropriate after the developer has run rclm-hooks-install --repair and a new check-in shows hooks installed. Dismiss is for a false positive, with a note. The wider control-plane picture is in the enterprise AI coding security control plane. Session analytics, which is a different screen, is enterprise observability.
This is a sequence, not a result we measured.
Week 1. Ask each developer to run rclm-hooks-install and sign in to the team workspace. DLP is on unless someone passes --no-dlp.
Week 2. Open Coverage. Anything still uncovered gets rclm-hooks-install --repair. This week is the baseline. Expect holes.
Week 3. Turn on Require DLP after the baseline is mostly green. Agree how exceptions are requested and how long they last. Name who receives the high findings.
Week 4. Put the coverage percentage in the monthly security note and export the CSV. Keep the weekly digest. A percentage with no owner will go stale.
NIST's AI Risk Management Framework is the general "measure, then manage" language if you need a framework citation. It does not require this product.
A coverage percentage is a management metric. It tells you whether the hook you depend on is still present. It does not, by itself, prove that secrets cannot leave, and it does not replace MDM if you need a setting the user cannot change.
AI coding assistant DLP describes the hook layer. The coverage docs describe the console. A 20-minute demo is the right next step if you want to see the device table on a workspace that already has data.
Yes. They can edit or delete the hook config, or reinstall with --no-dlp. ReclaimLLM reports the change on a later check-in. It does not prevent the edit.
On a Business or Enterprise plan, open Enterprise → Coverage. Each enrolled device shows assistant, DLP on or off, and last check-in. Filter to DLP off or Uncovered. Free plans do not include these alerts.
You need MDM if you want the operating system to block the change. You do not need MDM to measure whether hooks are still installed. Measurement is the option when the fleet includes personal or contractor machines you do not fully manage.
Posture only: device id, hostname hash, OS, client version, hook status (including a settings-file hint), DLP on or off, routing class, and heartbeat. Not source code, prompts, secrets, or the plaintext hostname. Session upload is separate and can contain the work log.
AD-012 flags a previously active device that stopped checking in. It is a daily warning, not proof the person disabled anything. Look for a reimage, a departure, or a removed client. Ephemeral build environments are excluded.
Yes. An admin or team lead can create a DLP exception with a reason and an expiry date, up to 12 months. AD-011 stays quiet for that subject until the exception expires or is revoked.