Book a 30-minute demo →
Docs

Documentation

A high-level overview of how Anomity deploys across the endpoint, the browser, and your cloud tenant, what each sensor discovers, how you govern it, where it integrates, and how it handles your data.

Before you start

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 Endpoint Sensor and Browser Sensor run, how cloud discovery connects, what each one finds, how you write policy, where alerts go, and how your data is handled.

Anomity collects from three places. The Endpoint Sensor reads AI tool configuration on managed machines. The Browser Sensor covers the AI services your people reach in a browser tab. Read-only cloud connectors find the AI applications that hold OAuth grants on your tenant without ever touching a device. All three feed one console, one findings queue, and one audit trail.

Full documentation, including install scripts, API references, policy schemas, and integration setup guides, is available to customers. If you would like access, book a demo or contact us and we will get you set up.

Deploying the Endpoint Sensor

Anomity runs as a single lightweight, unprivileged system service (the Endpoint Sensor) 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 Endpoint Sensor 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 Endpoint Sensor to Anomity Cloud to your security team.

Because the Endpoint Sensor 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.

Deploying the Browser Sensor

Most AI use never installs anything: people open a tab. The Browser Sensor is a managed Chrome and Edge extension, force-installed by browser policy from the Google Admin console, Microsoft Intune, or on-prem group policy, so it arrives the same way any other managed extension does.

It instruments only the AI web services it is configured for. It holds no blanket host permission, so the rest of what your people browse is never touched. For pilots and single machines, a time-limited connect code enrolls one browser without exposing your organization enrollment token.

Full detail on what the Browser Sensor records, what it blocks, and what it deliberately never collects lives on the Browser Sensor page.

Connecting cloud AI discovery

One employee clicking Allow on a third-party AI tool grants it access to your data without anything landing on a laptop, so no endpoint control will ever see it. Anomity finds those grants by asking your identity and code platforms directly.

Read-only connectors to Google Workspace and GitHub sync on a six-hour schedule or on demand. Each discovered application is matched against a catalog of known AI vendors, its OAuth scopes are rated for sensitivity and for the tier of personal data they expose, and the console names which of your people granted each scope. Grants can be revoked from the console, for everyone or for named users. Connectors for Vertex AI, Bedrock, and Azure AI Foundry are on the roadmap.

The first sync records your existing estate silently rather than raising a finding for every grant you already had, so the inventory is usable from day one.

What gets discovered

Between them the three collectors inventory twelve AI surfaces, then run everything 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.

Coverage is a moving target, so it is versioned rather than fixed. The registry currently recognises 144 AI tools across seven categories, 311 AI web services, and 162 credential formats, and grows as the ecosystem does.

  • AI Agents (Claude, ChatGPT, Cursor, Copilot, Gemini, Grok Bot, Cline, Windsurf)
  • MCP Servers, classified official, community, or unknown
  • IDE Extensions
  • Skills and instruction files, with their content scanned for risky behaviour
  • Plugins
  • Secrets, redacted on the device before anything leaves it
  • Hooks
  • CLIs, wrappers, and shims
  • AI sites and the accounts signed into them, corporate or personal
  • Local LLM runtimes and the model weights sitting on each machine
  • Browser extensions, with the AI ones called out
  • Cloud AI applications holding OAuth grants on your tenant

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 Endpoint Sensor sends metadata only, not your source code and not your prompts, and everything travels over HTTPS.

The same principle governs the other two collectors. Skill and instruction-file scanning runs on the device and returns a rule identifier and a severity, never the text it matched. The Browser Sensor sends no prompt text, no model responses, no page content, no cookies, and no browsing history outside the AI-site list; where a credential is detected, a masked fragment travels with the finding, enough for an analyst to know which key to rotate and never the value itself. Cloud discovery reads grant metadata through the provider API and never reads message or file content.

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, customers have access to the full documentation. Contact us if you need it.

Ask AI about Anomity
ChatGPT Claude Perplexity Google AI Grok