​

Understanding Results

After an analysis completes, Flare presents findings in a ranked list with explanations and evidence. Here’s how to read them.

​

AI summary

At the top of the results page, Flare provides a narrative summary of the overall patterns detected. This gives you the big picture before diving into individual anomalies - for example, whether the findings suggest a coordinated attack, routine administrative activity, or a misconfiguration.

​

Anomaly scores

Every anomaly receives a score from 0 to 100 based on Flare’s assessment of the available evidence and context, including historical observations when available. Higher scores mean the finding is ranked as more anomalous. Scores are relative to your environment. A GCP SetIamPolicy call or AWS CreateAccessKey event scores differently where that behavior happens daily versus where it has never occurred.

​

Anomaly details

Each anomaly card shows:

• Rank - position in the severity-ordered list (#1 is the most anomalous)
• Field name and anomalous value - what was detected (e.g., protoPayload.methodName -> SetIamPolicy)
• Explanation - a plain English description of why this is anomalous and what it could mean
• Severity badge - Critical, High, Medium, or Low

​

Expanded view

Click an anomaly to expand it and see additional detail:

• Baseline frequency - how often this value appears in your historical analyses (e.g., “0.4% of events”)
• Query frequency - how often it appeared in this analysis (e.g., “67% of events”)
• Source evidence - up to five selected source-event excerpts that support the finding

The gap between baseline and query frequency can be a strong signal, but it is one part of the evidence used to assess a finding. For example, a value that normally appears in 0.4% of events but appears in 67% of a given window deserves closer review. When you have multiple prior analyses, Flare also shows 30-day deviation data — how the current frequency compares to the rolling 30-day average. See 30-Day Baseline for details.

​

First Seen badge

Anomalies involving field values that have never appeared in any previous analysis for the environment get a “First Seen” badge. This is a strong indicator of genuinely new activity, such as a new service account, IAM identity, IP address, or API action.

​

Source log evidence

For each anomaly, Flare shows selected excerpts from the source events that contributed to the finding, displayed as JSON. These can come from GCP, AWS, or an enabled Workspace or GitHub audit connector. Use them to:

• Verify the finding - confirm that the raw data matches Flare’s explanation
• Investigate further - extract IP addresses, identities, account or project identifiers, API actions, and resources for deeper analysis in the relevant cloud console
• Copy evidence - use the Copy button to save specific log entries for incident reports

​

Copy as Markdown

Click the Copy as Markdown button in the analysis header to copy the full results (summary, all anomalies, and explanations) as formatted Markdown. This is useful for pasting into Slack, Notion, or incident tickets.

​

Interpreting results

A few patterns to look for:

• Multiple Critical/High findings in one analysis - may indicate a coordinated attack or significant incident
• First Seen values on sensitive fields (IAM, service accounts, network) - worth investigating even at lower scores
• Recurring patterns across analyses - if the same anomaly appears in multiple scheduled runs, it may be an ongoing issue or a new normal that needs to be acknowledged
• No findings in observed evidence - Flare did not identify unusual patterns in the evidence it successfully analyzed. Review coverage, authorization, zero-event, and truncation notices before drawing a conclusion about the full environment or requested window

​

Workspace and GitHub coverage

The audit coverage panel names the report streams queried and shows retained record/event counts, truncation and limitations. These counts exclude duplicate and out-of-window records read during collection. Workspace reports login, admin and token activity separately; GitHub reports web audit events. Provider delays, permission scope and request limits affect what is observed. Empty results mean no events were observed in this bounded query. Follow-up answers use the saved summary, findings and conversation history; they do not receive source-event excerpts or fetch additional audit history.