Lilly, MopokeHQ's AI

Lilly is the AI inside MopokeHQ. She explains alerts in plain words, estimates whether a match really applies to you, answers questions about your fix list, drafts one paragraph of a client notice, and, on projects that opt in, reviews merge request diffs.

Lilly informs. She never decides. Priorities, deadlines, alerts, escalations and closing work all follow fixed rules that use no AI (see Priorities), so they work the same with Lilly on, off, or unavailable.

What Lilly does

Feature	What you get
Alert notes	A few plain sentences on each advisory: what it means for this package, at this version, where it runs. With it, an estimate of whether the match applies, shown as “Applies: very likely (0.94)” on a scale of very likely, likely, unclear and unlikely.
“Not affected” suggestions	For a P2 or P3 that Lilly is confident does not apply, she marks it “Lilly suggests not affected” and keeps it out of the digest emails until a person confirms or overrides it. See Lilly’s suggestions.
Secret notes	For a secret the scanners found: what the credential most likely is, what someone holding it could do, how exposed it is, and the first thing to do. See Rotating a leaked secret.
Ask Lilly	Short questions about your organisation’s own Now list, from the search box (⌘K, Ctrl K, or /). Up to ten questions a minute per person.
Client notices	When MopokeHQ drafts a notice to one of your clients, Lilly writes its “What was found” paragraph. Everything else comes from the record, and only an owner or admin sends it.
Code review	On projects that opt in: a review of each merge request’s diff for security problems and quality signals, with at most five inline comments and one summary. See Code review.

What Lilly sees

Lilly gets the minimum each feature needs. She never sees source code for alert notes, never sees a secret’s value, and never gets your project, client or people’s names.

Feature	Sent	Never sent
Alert notes and suggestions	The public advisory text, whether it is known exploited, its EPSS score, and for each match: the package, installed and fixed versions, the environment name and the confidence	Source code, repository, project, client or people’s names
Secret notes	The scanner rule, the file and line, the variable’s name, other files that mention that name, whether it is on the default branch, how long it has been in the history	The secret’s value, who committed it
Ask Lilly	Your question, and your Now list’s action titles, advisory ids, priorities, tiers and due dates, and the decisions on dismissed advisories	Repository, project or people’s names, and anything people wrote
Client notice paragraph	The advisory and the package names	Everything else; names and dates come from the record
Code review (opted-in projects only)	The merge request’s diff, with secrets removed	Repository, project or customer names, files that hold secrets

Lilly’s requests go to AI providers that run with zero data retention: they keep nothing after answering. Those providers sit outside your data region. See Data and security.

What Lilly can and never does

Lilly can:

• write a note on an advisory or a secret,
• estimate how likely a match is to apply,
• hold a P2 or P3 out of the digests while it waits for a person, when she is at least as sure as your threshold that it does not apply,
• answer questions about your fix list,
• draft one paragraph of a client notice,
• comment on merge requests in projects that opted in to code review.

Lilly never:

• holds back, silences or dismisses a P1,
• dismisses or closes anything herself; “Confirm not affected” is a person’s click, and it is logged with their name,
• changes a priority or a deadline,
• sends anything to a client; a person approves and sends every notice,
• blocks a merge; review comments are quality signals and never fail a pipeline,
• sees a secret’s value.

If Lilly is unavailable, or a note fails, the alert goes out without the note.

Turn AI off

Each organisation has one switch: AI settings, Lilly notes, suggestions, Ask Lilly and AI code review. Anyone can see it; owners and admins can change it.

With it off, nothing about your organisation goes to an AI model:

• no alert or secret notes, and no “not affected” suggestions,
• Ask Lilly says it needs AI switched on,
• no code review on any project, whatever its owner chose,
• client notices use the plain template.

Alerts, escalations, digests, priorities and deadlines carry on as before. Every change to AI settings is recorded in the evidence log with who made it.

The same page sets the hold-back threshold: how sure Lilly must be that a P2 or P3 does not apply before she holds it out of the digests. It runs from 0.50 to 1.00, 0.90 by default. Raise it to hold back only what Lilly is certain about.

AI credits

Lilly’s work draws on your organisation’s pooled AI credits. On AI settings, owners and admins can also set a monthly AI spending cap, and the page shows what this month has used so far.

When the month’s use reaches the cap, Lilly stops until the 1st of the next month (UTC): notes, Ask Lilly and code review wait, and client notices use the plain template. Alerts still go out, just without notes.

Viewers cannot use Ask Lilly, because it spends the organisation’s credits.

Code review

Code review sends code out of your data region, so it is a per-project choice.

• Each project is marked internal or client by an owner or admin. Internal projects start with code review on; client projects start with it off.
• To turn it on for a client project, a project owner, owner or admin confirms that the client’s contract allows code diffs to be sent for review. That confirmation is recorded in the evidence log.
• The organisation’s AI switch overrides every project: off means no code goes anywhere.
• A merge request that touches several projects is reviewed only when every one of them has review on.

What is sent, and what is not:

• only the files worth reviewing: lockfiles, vendored and built code, binaries, images and generated files are left out,
• never files that hold secrets by convention (.env files, keys, files named like secret or credential, .npmrc, auth.json),
• anything in the diff that looks like a credential (cloud, Git platform, payment and other service tokens, private keys, JWTs, passwords in URLs or settings) is redacted first,
• no repository, project or customer names.

The diff is deleted as soon as the review is done, and within a day if a review never runs.

The review looks for security problems and quality signals: tests that assert nothing or mock what they test, duplicate helpers, swallowed errors, comments that narrate the code, needless abstraction, and plain bugs. A second check keeps only comments likely to be correct and worth a reviewer’s time, at most five, highest severity first, and never one an earlier review of the same merge request already made. Comments never say who or what wrote the code.

Code review runs on GitLab merge requests today.