Anomity

AI account posture: corporate vs personal (shadow) accounts, data-sharing, BYOK, usage and reach rollups.

get_ai_accounts

What the organization has already approved on Governance -> Allowlist, per tab (ai_tools, ai_sites, model_providers, mcp_servers, extensions, plugins, skills), with who approved each item and when. Returns at most `limit` items per kind (default 50) with the full `total`.

get_allowlist

Items detected on your devices that are not on the allowlist yet - the "Suggested for Approval" list on Governance -> Allowlist, for each tab: ai_tools, ai_sites, model_providers, mcp_servers, extensions, plugins, skills. Each item has a `key` to pass to approve_allowlist_items. Returns at most `limit` items per kind (default 50) with the full `total`. `approvals` says whether approving through this connector is available. `deviceTags` lists the device tags in use, with how many devices carry each - the tags an approval can be limited to.

get_allowlist_suggestions

Approve suggested items on Governance -> Allowlist - the same as clicking Approve in the console: it adds the items to the allowlist and closes their open findings. Pass `keys` exactly as get_allowlist_suggestions returns them, for one `kind` per call. Only items currently in the suggestion list can be approved here; anything else comes back under `notSuggested` and is left unchanged. By default an approval covers every device. Pass `targetTags` to approve only for devices carrying at least one of those tags (from `deviceTags` in get_allowlist_suggestions); every other device keeps raising the finding. Approving an item already approved for other tags adds these tags to it; approving never narrows an existing approval. Without `targetTags`, an item already approved for some tags is left as it is and returned under `scopedElsewhere`; pass `targetTags: []` only when the user wants it approved for every device. Confirm the exact items, and the devices they are approved for, with the user before calling this.

approve_allowlist_items

Query the 90-day audit trail — every added/removed/modified MCP server, permission, skill, hook, plus admin actions. Filter by device, action, actor, and time window. Answers "what changed, and when". `total` is how many rows match; `entries` holds at most `limit`, newest first - when total is larger, say both numbers. For one device pass `device` (its name or hostname) or `deviceId`, not both; several matching devices return `candidates` instead: ask which one, then pass its `id` as `device`. Name a device by its `device.label`, never its id; a row with a `deviceId` and no `device` is about a deleted device.

query_audit_trail

Inferred capabilities across MCP servers and permissions, overprivileged devices, and dangerous capability combinations.

get_capability_surface

Compliance readiness across the mapped frameworks (SOC 2, ISO 42001, NIST AI RMF, EU AI Act, OWASP LLM Top 10 and more): per-framework score and passing/failing requirement counts.

get_compliance_status

Which devices have one thing, looked up by name: an AI tool, app or browser (e.g. "Gemini Desktop", "cursor", "Mozilla Firefox"), an MCP server, an IDE or browser extension, a plugin, a skill, or an AI site. Use this for "which devices have X" - list_devices cannot filter. Omit `kind` unless the user named it: a name can be several kinds at once, and without `kind` every kind is searched. Each match has its `kind`, device count and devices (AI tools also give each device's version and when it last reported). When matches span several kinds, summarise them by kind (name and device count) and list devices only for what the user is clearly asking about, or offer to. `found: false` means it is on no device in any kind searched. `deletedDevices` counts devices that were deleted and cannot be listed: say so, never offer to show them. `devicesNotListed` counts enrolled devices left off a long list: say how many more there are. An AI site is counted in `machines`, each listing the browsers it was visited in; `browserSensors` is one per browser, not a number of machines. Every device listed is enrolled, whatever its last-seen date. There is no online/offline status here, so do not call a device active or online.

get_tool_devices

Fleet summary: total/online/stale/offline devices and open + critical finding counts.

get_dashboard_overview

List managed devices, optionally filtered by status (online/stale/offline). By default these are workstations (the endpoint daemon). Browser sensors are separate devices, one per browser profile: pass kind "browser" for them (each names its browser in `browserSensor.browser`), or "all" for both.

list_devices