trionTalk to Trion
GovernanceRelease notes

Arthur adds Splunk and Elastic agent discovery

An AI inventory is only as credible as the systems it can inspect. Arthur’s latest engine release adds discovery connections and clearer diagnostics, making source coverage part of the operational story.

Trion editorialReported 2 min read

Discovery through existing security systems

The official Arthur Engine 2.1.995 release notes, dated 11 October, add Splunk Enterprise and Elastic Security discovery connectors. Elastic uses customer-authored ES|QL queries. A standalone runner can scan on a schedule and send discovered agents to Splunk HEC or a webhook. The release also improves connection and configuration error classification.

Arthur Engine 2.1.995 adds Splunk Enterprise and Elastic Security discovery connectors plus a standalone discovery runner. The release also improves diagnostics, making connection failure easier to distinguish from a scan with no findings.
Trion

An inventory with evidence

  1. Configured sources

    Only systems actually connected

  2. Successful scan

    Connection errors stay visible

  3. Discovered records

    Retain source and observation time

  4. Named owner

    Review access and intended use

An empty inventory is meaningful only when the relevant sources were reachable and successfully scanned.
  1. Configured sourcesOnly systems actually connected
  2. Successful scanConnection errors stay visible
  3. Discovered recordsRetain source and observation time
  4. Named ownerReview access and intended use

Arthur · published 2026-10-11.

These additions provide routes for collecting evidence; they do not prove that every agent in an organization is known. Coverage still depends on configured sources, available records and working access. A result with no discoveries needs a different interpretation from a source that could not be read.

Make coverage visible

A practical inventory should help an owner answer three questions: where was this agent observed, when was it last seen, and what is it allowed to do? A long list of names is less useful if it cannot distinguish a retired experiment from a live service with production credentials.

Keep a separate list of expected sources and their scan state. That allows a reviewer to spot a missing business unit or a broken connector before treating the inventory as complete. Do not turn a successful scan of one system into a claim about systems outside its scope.

Test the gaps before expanding

A suggested pilot can start with one source and a small, known set of agents. The goal is to verify coverage and failure handling before scaling the collection process.

  1. Start with known records

    List the agents you expect the selected source to reveal, including an inactive one if available. Compare the returned records with that list and investigate both missing and duplicate entries.

  2. Create a controlled connection failure

    In a test environment, use an invalid credential or unreachable endpoint. Confirm the scan reports a failure rather than a reassuring empty result. Verify that the responsible operator receives enough context to repair it.

  3. Assign an accountable owner

    For each live agent, record who can explain its purpose, review its access and retire it. Keep discovery separate from approval: finding an agent should not automatically authorize its existing permissions.

Original sources

  1. Arthur: original release notesgithub.com