← Back to blog Product

Inside Anomity Discovery: How We Inventory Every AI Artifact on the Endpoint

Priya Nair Engineering Lead, Anomity · May 14, 2026 · 6 min read

Anomity Discovery is the engine that builds a complete, continuously updated inventory of the AI layer running on each managed endpoint. A lightweight, unprivileged daemon on every Windows, macOS, and Linux machine reads the local configuration that AI agents and their tooling leave behind, classifies what it finds, and reports metadata to Anomity Cloud over HTTPS. The result is a fleet-wide picture of which agents are installed, which MCP servers they can reach, what those servers are allowed to do, and where secrets are sitting in plaintext. This post is an engineering walkthrough of how that works, from the daemon on the box to the alert that lands in your SIEM.

The reason this layer needs its own discovery engine is simple: it lives on the endpoint, in dotfiles and per-user config, not on the network or in a SaaS admin console. Your gateway sees egress, your EDR sees processes, your DLP sees files in motion. None of them parse an agent's permission grants or notice that a teammate added an unvetted MCP server to their settings last Thursday. That is the gap Discovery closes.

The eight artifact types we inventory

AI tooling is not one thing. A single developer laptop can run several agents, each extended by servers, plugins, and scripts that change what the agent can touch. Discovery classifies everything it finds into eight pillars, and coverage expands as the ecosystem does:

AI Agents — Claude, ChatGPT, Cursor, Copilot, Gemini, Cline, Windsurf, and their peers.
MCP Servers — the Model Context Protocol servers an agent is configured to call.
Extensions — VS Code, Cursor, and JetBrains extensions that ride alongside agents.
Skills — packaged capabilities an agent can load and invoke.
Plugins — third-party add-ons that extend an agent or its host application.
Secrets — API keys, database URLs, JWTs, and private keys found in agent config.
Hooks — pre-prompt, post-tool, and event hooks that run code around agent actions.
CLIs — command-line agents and helpers installed on the machine.

Treating each as a first-class object matters because risk usually emerges from the relationships between them: an unknown MCP server with shell access, granted to an agent that holds a blanket write permission, configured next to a plaintext key. You cannot reason about that unless you have inventoried all of it.

From endpoint to security team

The data path is deliberately boring, which is what makes it trustworthy. There is no kernel module and no elevated privilege requirement.

Endpoint — the daemon reads local AI configuration as the logged-in user and fingerprints each artifact.
Anomity Daemon — it normalizes findings, redacts any secret values before they leave the machine, and ships metadata over HTTPS.
Anomity Cloud — classifies trust, infers capabilities, evaluates policy, and stores the inventory and audit trail under strict tenant isolation.
Security team — sees the live fleet inventory, and violations route to SIEM, Slack, email, or Jira.

Only metadata travels: configuration shape, server identities, permission grants, fingerprints. Never your source code, never your prompts. Secret material is redacted on the endpoint, so the daemon can tell you a plaintext key exists in a file without that key ever crossing the wire.

Classifying trust with multiple signals

Knowing an MCP server is configured is not enough; you need to know whether to trust it. Discovery runs a multi-signal trust classifier that weighs the declared vendor, the launch command, and a fingerprint of the server itself, then labels each MCP server as official, community, or unknown. A server published by a recognized vendor and launched through its canonical command lands as official. A popular open-source server resolves as community. Something pulled from a public registry that nobody can vouch for resolves as unknown — and unknown plus broad capability is exactly the pattern worth a second look.

Here is a discovered MCP entry as Discovery records it, with capability inference and trust classification attached:

{
  "artifact": "mcp_server",
  "name": "mcp-sqlite-cloud",
  "agent": "claude",
  "source": "~/.claude/settings.json",
  "command": "npx mcp-sqlite-cloud --db $PROD_DB_URL",
  "trust": {
    "classification": "unknown",
    "signals": ["vendor:unverified", "registry:public", "fingerprint:unmatched"]
  },
  "capabilities": ["filesystem", "shell", "network"],
  "flags": ["dangerous_combination", "unvetted_source"],
  "first_seen": "2026-05-12T09:41:07Z"
}

Capability inference is the second half of the picture. From the command, declared scopes, and fingerprint, Discovery infers what an artifact can actually do — filesystem, shell, network, credential access — independent of how it is described. A server billed as a read-only data connector that turns out to launch a shell gets flagged for the gap between claim and capability.

Dangerous combinations and real-time change detection

Individual findings are rarely the story. Dangerous-combination detection looks for the pairings that turn benign components into real exposure: an unknown MCP server holding shell and network capability, a blanket Bash(*) or Write(*) grant on an agent that also reaches sensitive systems, a plaintext credential sitting in the same config that an unvetted server reads. These are the patterns an attacker — or an honest mistake — would exploit, and they only surface when you correlate across the eight pillars.

Inventory also has to stay true between scans, because this layer changes daily. Discovery does real-time change detection: when a developer adds a server, widens a permission, installs an extension, or drops a new key into a config file, that delta is captured as it happens rather than waiting for the next sweep. New state is re-classified and re-evaluated against policy immediately.

Governance: from inventory to enforcement

Visibility is the foundation, not the product. On top of the inventory you define policy, and policies evaluate continuously against the live state of every endpoint. Rules are expressed against the same artifact model Discovery produces — deny blanket permission grants, require MCP servers to be on an approved list, forbid plaintext secrets in agent config. A rule looks like this:

{
  "policy": "agent-baseline",
  "rules": [
    { "id": "no-blanket-shell", "deny": { "permission": ["Bash(*)", "Write(*)"] } },
    { "id": "mcp-allowlist", "require": { "mcp_server.trust": ["official", "community"] } },
    { "id": "no-plaintext-secrets", "deny": { "artifact": "secret", "state": "plaintext" } }
  ],
  "on_violation": { "route": ["siem", "slack", "jira"], "severity": "high" }
}

When state crosses a rule, the violation routes to wherever your team already works — SIEM, Slack, email, Jira — with the artifact, the endpoint, and the offending signal attached. No new console to babysit.

Trust by design and a real audit trail

Because the daemon reads sensitive configuration, the trust model is built in rather than bolted on. Anomity is SOC 2 Type II. Secrets stay on the endpoint and are redacted before anything leaves the machine. Tenants are strictly isolated, each device gets its own credential, and credentials are stored bcrypt-hashed at rest. We collect metadata only — not source code, not prompts.

Every change Discovery observes is written to a 90-day audit trail: every MCP server, permission, extension, plugin, skill, and hook that was added, removed, or modified, with a timestamp and the endpoint it came from.

What changed last Thursday becomes one query, not a forensics engagement.Anomity Discovery

That is the whole point of building inventory first. You cannot enforce a policy against artifacts you have never enumerated, and you cannot answer an incident question about a layer you never recorded. Discovery makes the agentic layer visible so the rest of your program — governance, alerting, audit — has something real to stand on. You can't govern what you can't see.