Skip to main content

First findings

Once a machine is enrolled, its AI activity appears in the console within about a minute of the first heartbeat. Everything on this page is read there — no command line, no log files. (Running the agent yourself, offline or on a machine that was never enrolled? See Reading findings on the endpoint.)

Start on the Overview​

The Overview is the day's picture: how much AI your organization used, how much of it matched something, and what Lumen did about it.

The Lumen console Overview: interactions, findings, blocked and redacted counts, a 30-day trend, detections by class, top firing rules and recent findings

The six figures across the top each link through to the records behind them, with the filter already applied:

  • Interactions today — every inspected prompt and response since 00:00 UTC.
  • Findings today — what Lumen counted as a finding since 00:00 UTC. A repeat of something already reported in the conversation is not counted; see Service limits.
  • Blocked and Redacted — what enforcement did since 00:00 UTC.
  • Endpoints — machines reporting out of machines enrolled.
  • Capture coverage — how much of the AI tooling Lumen found is actually routed through it.

Below them, a 30-day trend, a breakdown by detection class, and the rules doing the most work.

An interaction is not a finding​

Every inspection produces an interaction record, whether anything matched or not. The two lists in the sidebar follow from that: Interactions holds everything; Findings holds every record where at least one detector matched.

What Lumen counts as a finding, in Findings today and on Billing, differs slightly from that list. A match on text already reported earlier in the conversation, or in an earlier turn that an AI coding tool re-sends, is not counted, and Hide repeats on the Findings list hides it. A Block or Redact that no detection explains, such as an access rule denying an application, is counted but matched nothing, so it is on Interactions and not on Findings. See Service limits.

The Findings list: severity, detection class, the captured text, score, the rule that decided, endpoint and action

Read one finding​

Select any row to open the whole record. This is a leaked credential that a policy with its sensitive-data rule promoted to Redact caught in a prompt and redacted before it left the machine. On Local default, which only logs, the same finding reads Log and the prompt goes through as typed:

A finding detail: the verdict, the captured text with the redacted span highlighted, the decision in the engine's words, the detection, and the full context

The detail view shows the verdict (here Redact, on a prompt), the captured text with the redacted span highlighted, the decision in the engine's own words (rule pr_secrets: sensitive_data score 0.92 >= 0.50), each detection that matched, and the context — time, endpoint, user, application, provider and model, the collector that captured it, and the policy and rule that decided. Storage happens after the action, so the raw secret was never written: only the placeholder and the span survive.

Your first findings are recorded, not acted on​

A fresh deployment runs in monitor mode: every detector your policy references runs, every match is recorded, and nothing is redacted or blocked, because the built-in policy every endpoint starts on, Local default, sets every rule to Log. Severity still reflects what was found, so a leaked credential or a prompt injection reads High even though nothing was redacted or blocked, and a toxicity or topic match reads Low. See how severity is derived. The credential coming back untouched is expected: the agent saw it, classified it, and recorded it. The intended path is collect, tune, then enforce. See From monitor to enforce.

Next steps​