Documentation

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, how you query the result from an AI assistant over MCP, 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.

The Anomity MCP server

Your inventory, findings and audit trail already live in the console. The MCP server puts them behind a question instead. Connect Anomity to an AI assistant that speaks the Model Context Protocol, Claude and ChatGPT both do, and an analyst can ask what changed last week or which unapproved MCP servers are spreading, and get an answer drawn from your own tenant rather than from a dashboard filter.

It is read-only by design. Nothing it exposes can change a policy, resolve a finding, revoke a grant or touch a device. Each person connects as themselves, inherits the role they already have, and sees only their own organization, so the connector can never surface anything they could not already open in the console.

It reaches the same views your team uses every day:

• The fleet at a glance: how many devices are reporting, how many findings are open, and how many of those are critical
• Managed devices, filtered by whether they are online, stale or offline
• Policy violations, by severity and by where they sit in your workflow
• MCP servers across the fleet, grouped official, community or unknown, with the unknown ones ranked by how far they have spread
• Inferred capabilities, overprivileged devices, and the dangerous combinations that only show up when you look across artifacts
• Plaintext secrets found in AI configuration files, by type and severity, never by value
• Skills and instruction files flagged by on-device content scanning
• AI account posture, corporate against personal, with data-sharing and BYOK settings
• Compliance readiness across SOC 2, ISO 42001, NIST AI RMF, the EU AI Act and the OWASP LLM Top 10
• The 90-day audit trail: what was added, changed or removed, when, and by whom

Connecting an assistant

Add https://app.anomity.ai/mcp as a connector in Claude, ChatGPT or any other MCP client, then sign in when prompted. Authorization runs over OAuth 2.0 against your Anomity tenant, so there is no API key to copy and no long-lived credential stored in the client. Discovery is automatic: a client that implements the MCP authorization spec finds the sign-in endpoint on its own.

In practice the questions look like which unknown MCP servers are installed on the most devices, what changed on our fleet in the last seven days and who changed it, show me every open critical finding and the devices it sits on, or where are we failing EU AI Act requirements. The assistant picks the right view; nobody needs to learn a query language.

If answers come back empty, the tenant usually has no enrolled devices yet, or the account signed in cannot read inventory, and both are visible in the console. If authorization fails, disconnecting and reconnecting forces a fresh sign-in. The audit trail is a rolling 90-day window, so a question reaching further back is answered from an export rather than a query.

The connector inherits the platform's collection limits, so it cannot return what Anomity never collected in the first place. Secrets come back as a type, a severity and a location, never as a value, and skill scanning returns a rule identifier rather than the text it matched. The server reads your Anomity tenant and nothing else: it has no access to your conversation with the assistant, to its memory or history, or to any file you upload there. How the underlying data is handled is set out in the Privacy Policy.

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.