Documentation
A high-level overview of how Anomity deploys, what it discovers, how you govern it, where it integrates, and how it handles your data.
Before you start
Anomity is in early access, and this page is a high-level overview rather than a complete reference. It explains how the platform fits together so you can evaluate it: where the daemon runs, what it discovers, how you write policy, where alerts go, and how your data is handled.
Full documentation, including install scripts, API references, policy schemas, and integration setup guides, is available to early-access customers. If you would like access, request early access or contact us and we will get you set up.
Deploying the daemon
Anomity runs as a single lightweight, unprivileged daemon on every managed endpoint. It supports Windows, macOS, and Linux, and is designed to deploy through the tooling you already use, including your MDM, configuration management, or existing endpoint management workflow.
Once installed, the daemon discovers AI artifacts locally and sends classified metadata to the Anomity Cloud over HTTPS, where it is evaluated against your policies and stored for your security team. The data flow is straightforward: endpoint to Anomity daemon to Anomity Cloud to your security team.
Because the daemon is unprivileged and works in the background, developers and employees do not change how they work and, in most cases, do not notice it is there.
What gets discovered
The daemon inventories eight types of AI artifacts across each endpoint, then runs them through the discovery engine. A multi-signal trust classifier labels each artifact as official, community, or unknown; capability inference flags what an artifact can reach, such as filesystem, shell, network, or credentials; and dangerous-combination and real-time change detection surface risky setups as they appear.
- AI Agents (Claude, ChatGPT, Cursor, Copilot, Gemini, Cline, Windsurf)
- MCP Servers
- Extensions
- Skills
- Plugins
- Secrets
- Hooks
- CLIs
Defining governance policies
Governance is rule-driven. You define policies that describe what is and is not allowed across your fleet, and Anomity evaluates every discovered artifact against them continuously rather than only at install time.
Policies map directly to the risks the discovery engine surfaces, so you can encode your standards once and have them enforced everywhere. When an artifact violates a policy, the violation is routed to your integrations so the right people see it immediately.
- Disallow blanket capabilities such as Bash(*) or Write(*)
- Permit only approved MCP servers
- Block plaintext secrets on the endpoint
- Continuously re-evaluate as artifacts are added, removed, or modified
Integrations and routing
Anomity is built to fit into the tools your security team already lives in. Violations and notable changes can route to your SIEM, Slack, email, and Jira, so detection turns into action without anyone watching a separate dashboard.
Anomity complements your existing stack rather than replacing it. It sits alongside your network and gateway controls, EDR and XDR, DLP, and GRC tooling, covering the AI agent layer those tools were not built to see.
Data handling and security
Anomity is designed to be safe to deploy across your fleet. Secrets stay on the endpoint and are redacted before anything leaves the device. The daemon sends metadata only, not your source code and not your prompts, and everything travels over HTTPS.
On the platform side, Anomity is SOC 2 Type II, enforces strict tenant isolation, issues per-device credentials, and stores credentials hashed with bcrypt at rest. Anomity also maintains a 90-day audit trail of every artifact added, removed, or modified, so a question like "what changed last Thursday?" becomes a single query.
For complete details on architecture, retention, and compliance, early-access customers have access to the full documentation. Contact us if you need it before then.