Deckard: an empty inventory is not a clean scan.
Arthur's new agent scanner makes coverage failures visible. A fresh scan timestamp still needs fresh evidence.

Concept photo: programming code on a screen, by luis gomes / Pexels. Not a screenshot of Deckard. Used under the Pexels license, which permits article, RSS and social reuse. No endorsement implied.
A laptop can stop appearing in a security inventory for two very different reasons: its AI tools are gone, or the scanner can no longer read it. A dashboard that treats both as an empty list can make a blind spot look like progress.
That distinction is the useful part of Arthur's November 3 launch of Deckard, a scanner for finding AI agents across endpoints, cloud platforms, network logs and security telemetry. The headline promises a hunt for rogue agents. The documentation describes something narrower and more practical: read-only discovery that sends findings to a security team's existing tools.
The missing result needs its own record
According to the event documentation, Deckard emits an agent record for each agent found on each scan. With emit_scan_outcomes: true, it also emits a scan-outcome record. That second record matters even when the first produces nothing.
The documented alert conditions include a failed source, a cloud account or project that denied access, and devices the collector could not read. Those are coverage failures, not evidence that the environment contains no agents. A sensible first review therefore asks two questions: what appeared, and which parts of the search were actually completed?
Repeated findings are expected. The docs tell downstream systems to deduplicate using the agent's external ID together with the source ID. Counting every incoming event as a newly discovered agent would inflate the inventory.
A recurring scan can still read old evidence
The quickstart makes another boundary unusually visible. Its local script gathers installed-tool evidence into a folder. Deckard re-reads that folder on each scan, but the operator must run the collection script again to refresh it. A fresh scan timestamp is not automatically a fresh observation of the machine.
The architecture guide also warns that a log source's lookback window must cover at least the scan interval; otherwise activity can fall into a gap. Inventory sources work differently. These are configuration details worth checking before treating a quiet dashboard as reassurance.
Discovery is not a verdict
Deckard's repository describes a headless, read-only service. It lists and searches sources, then sends results to Elasticsearch, Splunk or an HTTPS webhook. It does not turn an unfamiliar installation into proof of malicious behavior, and finding an agent does not by itself disable it.
There is a packaging distinction too: the Deckard repository holds deployment files and documentation; the discovery code lives in Arthur Engine. Teams reviewing the software need to follow that boundary rather than assume this repository is the entire implementation.
Arthur's product page presents a broader integration picture than the current quickstart table. Check the configuration and permissions for the particular source you need, rather than treating every marketing logo as a verified deployment path.
GigSoul has not run Deckard or measured its detection coverage. This is a documentation-led assessment, not a benchmark. The practical adoption test is simple: make one known agent visible, make one source unreadable in a controlled evaluation, and check that the two outcomes cannot be mistaken for each other. An inventory earns trust by showing where it cannot see.


