Public breach research
An optional public-web check can help reviewers find reported breaches and security incidents associated with a vendor. It provides source links and short evidence excerpts for human review. A report about an employee's exposure at another service is distinguished from a compromise of the vendor itself.
Start research
- Open the vendor and edit its official company website. You can also save a public legal company name and up to three public aliases.
- Choose Start Review or Start Re-Review, set Vendor relationship to New vendor or Existing vendor, and select Research publicly reported breaches for this review.
- Check the provider availability notice and confirm that the saved website is the official site.
- Upload your review documents and start the review.
The first review defaults to research off. The web form copies your most recent review's selection for a new re-review. API clients must explicitly send public_research_enabled=true; omission stays off. The relationship defaults to New for pending or denied vendors and Existing for approved or no-longer-in-use vendors; you can override it. This choice is saved with the review and is separate from whether it is a re-review.
Research runs at the review cycle only. Re-review reminders, ordinary page visits, and vendor response rounds do not start fresh searches. Document analysis and public research have separate statuses; a research failure does not consume another document-review allowance or prevent the document assessment.
BYOK and included usage
For BYOK accounts, discovery uses Anthropic native web search and extraction uses the same customer's effective Anthropic key. An organization-specific key takes precedence over the parent account's key; client and MSP BYOK settings are respected. Search and token usage are billed to the customer's Anthropic API account. A Claude chat subscription is separate.
There is no automatic fallback to a platform key for BYOK accounts. Missing keys, credits, model support, or web-search access produce an explicit unavailable/failed state. A payer change during a review stops further research and assessment use of that snapshot. An administrator can set a Public research page limit from 1 to 200 in Settings for a customer-key scope. The default is 12. It applies to future reviews and is an upper bound: the search may find fewer usable sources. Higher limits take longer and use more of the customer's search and token allowance.
Included-usage accounts use the platform's Anthropic key for native web search and extraction when the deployment is configured. Search and token usage are included within the review limits. Research is bounded per review.
The deployment's ANTHROPIC_IMPACT_MODEL handles public search, incident extraction, concern suggestions, and recommendations based on research. A retry of an older research run uses the current impact model while keeping that run's original payer and page limit.
Only public company identifiers go to discovery. Private documents, reviewer notes, contact information, and organization instructions are not added to public search queries. Accepted findings can later be assessed alongside private review evidence in the ordinary authenticated vendor-response analysis.
Review findings
Each incident card shows its current Concern level beside the title, with the editable rating and AI suggestion below. It also has a category, identity-match confidence, evidence status, source excerpts, and a separate reviewer disposition. AI suggests an initial concern level and explanation based on supported evidence, data sensitivity, and the saved vendor relationship. Levels are Unknown, None, Low, Moderate, High, and Critical. A reviewer can change the level and explain why. If the automated rating cannot be produced, the card says it is unavailable and leaves the concern level at Unknown for reviewer assessment. Unknown impact, incident date, and remediation stay unknown when evidence is missing; a concern rating does not confirm that your data was affected. A supported month without a supported day appears as a month and year, such as July 2023, rather than an invented exact date. The date can be supported by a date-labeled excerpt or by the retained incident excerpt itself when it states the same date. An article's publication or update date alone does not establish the incident date.
Reports of the same attack may use different dates for initial access, detection, and customer impact, or describe different affected products. Research groups reports when their timelines and attack details strongly overlap, while keeping their distinct source excerpts. Reports without enough overlap remain separate for reviewer assessment. Existing saved results are not silently regrouped; a new research result applies the current grouping rules.
- Relevant accepts the incident for the next user-initiated response assessment.
- Unrelated, Duplicate, Needs clarification, Reviewed, and Pending do not feed that assessment.
- Confirmed is assigned to a reported compromise of the vendor when a retained incident excerpt from a successfully retrieved HTTPS page on the vendor's saved official domain directly acknowledges it, even if the AI initially labeled the report provisional. Incident details such as stolen tokens can support that disclosure; they are not separate victims. Allegations, denials, disclosures about a customer, supplier, or another company, third-party reports, and search snippets remain provisional. Reviewers can change the status; manually selecting Confirmed requires a cited supporting source and a written rationale identifying the authoritative acknowledgement. The citation may be reviewer-provided, and the card will keep that provenance visible. No separate source picker is needed. Existing saved results do not change automatically.
An administrator can add an unsent question from an incident after analysis finishes. If a sent question round is awaiting vendor responses, submit those responses before adding another question.
- Unrelated/duplicate decisions and evidence-status overrides require a rationale. Selecting Duplicate reveals a Duplicate of picker; the target must be another incident in the same result.
If you can read a breach source that automated research could not access, expand Add a breach from a source you can access on the current review. Enter a public HTTPS source URL, an exact excerpt from that page, and the incident details you can support. The platform does not fetch the URL. The new card is labeled Reviewer added, and its excerpt is identified as reviewer-provided rather than automatically retrieved. Review its concern and disposition like any other incident. A reviewer-provided citation and written rationale can support a manual Confirmed decision. Up to 10 reviewer-added incidents can be kept in one review; they remain available if research is retried, while historical research versions stay unchanged. Adding an incident makes the saved recommendation out of date; select Update recommendation to include it. Reviewer-provided claims remain distinguishable from fetched evidence in that recommendation.
The saved New/Existing choice also guides questions in the initial document assessment and later vendor-response rounds. Administrators can edit a public-incident question draft and add it to the ordinary unsent vendor questions. For a New vendor, the draft asks about cause, remediation, prevention, and the proposed service. For an Existing vendor, it asks first whether your data, accounts, or services were affected, then about notice, containment, and remediation. No question is sent automatically. Decisions are audited; concurrent edits require reloading instead of overwriting another reviewer's work.
Every time a recommendation is generated, it considers the research available at that moment, including incident candidates that have not yet been accepted by a reviewer. The recommendation receives each candidate's current disposition, evidence status, and concern level. When no incidents were found, it also receives whether research coverage was complete so it does not infer that no breach occurred. Its rationale focuses on incident evidence, risk, and follow-up rather than search mechanics. Only accepted incidents can become established public-evidence findings in response analysis. A completed search or changed reviewer decision does not automatically regenerate a recommendation; the page shows when the saved recommendation predates the current research state and lets an administrator select Update recommendation.
Accepted evidence is frozen when a vendor response is submitted. A later decision or research version can make the assessment out of date. The application shows that state rather than silently rerunning analysis. The next response assessment uses the original document assessment, recorded answers, and the newly accepted evidence, preserving explicit human status overrides. It does not search again.
Comparisons and limitations
New reviews compare with the latest preceding published research snapshot available when they were created, including a partial result with stated coverage gaps. New to review means newly discovered by this product, even if the incident is old. Not rediscovered means absent from this limited search, not resolved. Each cycle requires its own acceptance. A changed company domain prevents automatic comparison.
The scope is English-language public web research. Included usage remains limited to 12 selected HTML/text pages. Customer-key research defaults to 12 and can be configured up to 200 selected pages. If broad discovery does not find a vendor disclosure, the system makes one targeted search of the official domain when search limits permit. Discovered incident reports, especially the vendor's own disclosures, are prioritized before the selected-page limit; a disclosure absent from all search results still cannot be assessed. The system processes larger runs in bounded batches and reports actual selected and checked sources. Robots checks and redirects use request capacity; the byte allowance now accounts for those checks so they do not prevent an otherwise available selected page from being fetched. Each extraction request is limited to 12,000 input and 4,000 output tokens. Source windows, blocked pages, PDFs, and other unsupported content can leave explicit coverage gaps. Up to 50 distinct incident candidates are published per result; if more qualify, the coverage section reports how many were omitted.
At the default 12-page limit, Anthropic native search is limited to three Messages requests and 10 search uses across retries. Higher BYOK limits permit up to 40 search uses in two requests. Each request has a 4,000-output-token limit; server-added search-result tokens cannot be hard-capped before an already-running request finishes. Search and extraction limits can stop a run before the selected page cap is reached, and the coverage section names those limits.
No findings means no relevant incidents were found in the sources checked. It never establishes that no breach occurred. The coverage section shows when the search was incomplete. The application keeps short excerpts and metadata with review history, not full website archives or leaked datasets.
Troubleshooting
Assessment citation links open the saved research version they reference. Citations without a saved version open the current research result and scroll to the incident.
Key, permission, or model errors during incident extraction require correcting the provider configuration before retrying. Temporary rate limits respect the provider's retry delay; other temporary extraction failures remain retryable.
Unavailable: Review the availability notice. An operator may need to enable the feature or configure Anthropic web-search access. A BYOK organization must fix its own Anthropic access; it will not use the platform key as a fallback.
Partial or failed: Expand Search coverage and limitations to see unavailable sources or other limits. If some sources were assessed but others refused automated access, the page says Research complete; some sources could not be accessed programmatically. If none of the selected sources could be accessed, it says No selected sources could be accessed programmatically. These are coverage limits, not temporary failures; use the manual breach entry above if you have a relevant source. The page offers Retry research only for a recoverable temporary error on the latest review, within its original 24-hour window and at most three failed execution attempts. Reaching provider or review limits does not offer a retry. Other research stages remain within their lifetime usage limits. Normal batch continuation does not use another retry attempt. A completed run is final; fresh research requires a new review. A retry retains earlier result versions and decisions, and a new result requires fresh acceptance. Reviewer-added incidents remain on the current review across retries.
Assessment context too large: The full history cannot be silently shortened. Start a new review with consolidated evidence when the complete response history exceeds the analysis limit.
Recommendation unavailable: The analysis retries a truncated result with a larger output limit. If the model's recommendation fails validation, the retry names the invalid fields and required values while using the same current research snapshot. Transient provider errors are also retried once. If it still fails, an administrator can use Retry recommendation in the Public breach research section when a saved assessment is available. This uses current reviewer findings and public research without uploading documents or searching again. The action is hidden for older response reviews that lack a reusable assessment. A review with more than 80 findings cannot be updated this way; no findings are silently omitted, so contact support if that limit is reached. If the update times out, no new recommendation is saved; try again later. If it still fails, contact support with the review number so the provider failure can be checked in server logs.