Radar Researcher beta: shareable links and history
Radar Researcher opens from the header on any Radar page. That matters because the assistant is not a separate sandbox bolted on later, it sits on top of Radar data and page context. Users can ask questions by voice or text and get explanations with interactive charts built from Radar API data.
The beta also includes searchable conversation history and shareable links. That is convenient for passing around an answer, but it also turns an AI chat into a portable object. Once a conversation can be searched and forwarded, the natural habit becomes to reuse the output without checking which page, chart, or time window produced it.
Treat shared conversations like cached analysis, not proof. A link can carry the words, but it does not carry the assumption that the same question will still resolve the same way after the data changes.
Keep the conversation tied to the underlying Radar page
The safest habit is boring: keep the chat close to the Radar page it came from. If the question is about traffic trends, record the page, the chart, and the date range before handing the result to anyone else. A neat-looking conversation with no source page is just polished uncertainty.
Explain with AI follows the same pattern at chart level. It uses the selected chart’s underlying data and context, which is useful when the ask is narrow and the chart is already the right source of truth. It is much less useful when people start asking open-ended questions that drift away from the chart they started from.
For security work, that boundary matters. A shareable link to a chart-aware conversation is fine for review, but it should not become the only artefact people keep. Keep the underlying Radar page in the loop or the chat becomes a very convincing wrapper around whatever happened to be visible at the time.
WebMCP pushes the same data into browser agents and lookup tools
WebMCP extends Radar into browser-based AI agents, so the same data can be searched, navigated, and queried from outside the normal page flow. That is useful for automation, but it widens the trust boundary. An agent that can move through Radar and call lookup tools can also be steered into places where the user did not mean to go.
The included security-oriented tools are URL scanning and domain lookup. Both are only sensible when treated as bounded queries. URL scanning is a specific check against a specific URL. Domain lookup is a specific lookup for a specific domain. Neither should be treated as a vague invitation to trust a browser agent with arbitrary web input and hope for the best.
Guardrails should be plain:
- restrict agent access to known Radar pages and expected query paths
- treat URL scanning as input validation plus lookup, not free-form browsing
- treat domain lookup as a fixed query against a known domain
- do not let shared chat history stand in for provenance
- review what the agent can export, save, or pass on through a shareable link
Radar Researcher, Explain with AI, and WebMCP all make the same trade-off in different places. They make Radar easier to interrogate, and they make the resulting answers easier to move around. That combination is handy, and it is also how a neat-looking conversation starts acting like an unchecked report.
