How Deckard Works

You can't govern AI agents you don't know about. Most organizations already run more agents
than anyone has accounted for: agents deployed on cloud AI platforms, agents that teams built
and never registered, and agentic tools on employee laptops that have shell, filesystem or
browser access. Deckard finds them and sends them to the SIEM (security information and event
management system) your security team already works in.

Discovery classes

Deckard finds AI agents by asking the systems that already know about them. Those systems fall
into four classes, and each class sees agents a different way:

Class	What Deckard reads	What it finds
Cloud AI platforms	The platform's own inventory of deployed agents and workloads and its audit trail, and, for VMs, what Arthur's open-source endpoint collector reports through your cloud tooling	Every agent deployed in a project, account and region, the identities that call hosted models, and agentic tools on cloud VMs
Employee endpoints	What the endpoint collector reports through your MDM (mobile device management)	Agentic coding tools, autonomous local agents, AI browsers and extensions on laptops and dev boxes
Security telemetry (SIEM)	Your SIEM, through your own SPL or ES\|QL search	Agents that show up in the logs and events you already collect
Network and gateway logs	DNS query logs, flow logs and gateway logs	Internal workloads making requests to GenAI providers or your own LLM gateway, whether or not anyone registered them

No single security tool sees all four. Endpoint tools see laptops, network tools see traffic,
each cloud console sees what's deployed in it. Deckard reads across them, so you get one view
of your AI workloads instead of a sliver of each.

Integrations

Class	Integration	`vendor`	What it reads
Cloud AI platforms	Google Cloud Vertex AI Agent Engine	`gcp_vertex`	Every Agent Engine in a project and region
	Google Cloud Compute Engine	`gcp_compute_engine`	The endpoint collector's inventory on VMs across projects, folders or an organization
	Amazon EC2	`aws_ec2`	The endpoint collector's inventory on instances across regions and accounts, through AWS Systems Manager (SSM)
	Google Cloud Run and GKE	`gcp_containers`	Cloud Run services and jobs and GKE workloads that run an agent's image or call Vertex AI models
	Amazon Bedrock	`aws_bedrock`	Bedrock agents and AgentCore runtimes, and the IAM roles CloudTrail shows calling Bedrock models
	Vercel	`vercel_ai`	A Vercel team's deployed projects that call an LLM or run an agent, by their keys, integrations and traffic
	Amazon ECS and EKS	`aws_containers`	ECS services and tasks and EKS workloads that run an agent's image or run as a role that calls Bedrock models
Employee endpoints	Jamf Pro	`jamf_pro`	The endpoint collector's inventory on each managed Mac
	This machine	`local`	The same, on the machine running Deckard, read from the folder that the Docker Compose quickstart's `scan-local.sh` script writes (see Quickstart). Available only with Docker Compose
Security telemetry (SIEM)	Splunk Enterprise	`splunk_enterprise`	Your SPL search
	Elastic Security	`elastic_security`	Your ES\|QL query
Network and gateway logs	AWS Network Logs	`aws_network`	Route 53 Resolver query logs, VPC flow logs, or your own format
	Google Cloud Network Logs	`gcp_network`	Cloud DNS query logs and VPC flow logs

Vercel is a hosting platform rather than an AI platform, so Deckard reads it the way it reads
Cloud Run or ECS: as a host for workloads that run agents. Its vendor key in the config
is vercel_ai.

Jamf Pro, Compute Engine and EC2 read what Arthur's open-source
endpoint collector
writes to each machine. The signatures it detects agents by are open source too, so coverage
keeps up with new tools as they appear.

You deploy the collector through the MDM or cloud tooling you already use. Its
quick start
covers Jamf Pro, Compute Engine and EC2. Wherever the quick start says to
add a discovery source in the Arthur Platform, add that source to Deckard's config file instead.

Sources, scans and the destination

You give Deckard one config file, which names three things:

Sources: each one is a system in one of the classes above. It has fields that say
how to connect (a URL, a project or account, a credential) and one or more scan configs
that say what each scan does: a query for a SIEM, or an agent catalog for an endpoint
source. Inventory sources, such as Vertex AI, list everything they hold, so their scan config
has an empty query. Every source is optional; configure only the ones you use.
A schedule: how often each scan runs. Deckard scans once at startup, then on the
interval.
One destination: Elasticsearch, Splunk HTTP Event Collector (HEC) or any HTTPS webhook. Every scan sends one
event per agent found, plus one event saying how the scan went. See
Events and alerting.

${NAME} in the config reads an environment variable and {file: path} reads a file beside
it, so no secret has to live in the config itself.

Each scan config can set lookback_window_seconds: how far back that scan reads logs,
rounded up to whole hours. Keep it at least as long as the scan interval. If it is shorter,
activity in the gap between one scan's window and the next is never read. Inventory sources,
like Vertex AI, ignore it.

The configuration reference,
in the Arthur Engine repository because Deckard runs the engine's ML Engine (see
Deckard and the Arthur Engine), documents every source's fields and the permissions its credential needs, the destination
options, and exactly how scans are scheduled.

Design principles

Read-only. Deckard only lists and searches. It never changes anything it reads, each
source needs only read permission, and its credentials are kept out of every log, error and
event.
Runs in your environment. Deckard is one container with no database, and talks only to
your sources and your destination. Your inventory never leaves your network.
Stateless. Nothing is kept between scans; each scan sends what the source reports now.
A restarted Deckard just scans again.
Blind spots are reported, not hidden. A source that fails, a cloud account the scan was
refused, or a machine it could not read each shows up in the scan's outcome, so a gap in
coverage raises an alert of its own instead of going quiet.

Deckard and the Arthur Engine

Deckard is an operating mode of the Arthur Engine:
its ML Engine, running in standalone discovery mode. Each Deckard release is one engine
release under Deckard's name: arthurplatform/deckard:<version> is that release's
arthurplatform/ml-engine image, unchanged: both tags point to the same image digest. The GitHub release and the
arthur.ai/engine-version annotation in the Deckard Helm chart's Chart.yaml say which engine
release it is.

When you want more than an inventory, the Arthur Platform runs the
same scans and adds what comes next: triage of every agent found, then policies, monitoring
and guardrails for the ones you bring under governance.