Claude Automox connectorWhat Claude can do in your Automox account.

Runs a structured, field-based query over your fleet, the kind that finds every Windows machine not seen in 30 days. Claude gets back the matching devices and can then narrow or explain the list.

Queries audit events from Automox's Audit Service v2, returned in the OCSF format that many security tools already understand. A date is required, and an event type name can narrow the result further.

Pulls the audit trail of one person on a given day, identified by email or by identifier, with paging when the day was busy. The raw event payloads, sanitized, come back only when you explicitly ask for them.

Answers, for one or several server groups, whether each sits inside an active exclusion window at this exact moment. The reply is a plain yes or no per group, with nothing to interpret.

Tells whether one maintenance window is live right now. Automox counts it as active when its status says so, at least one group is attached, and the current time falls inside an exclusion period.

Gives a curated picture of one device: recent policy status, assignments, queued commands and key facts. Status codes come back as readable labels, plus a compliance summary naming the policies that need remediation.

Aggregates health figures for the whole organization. Compliance follows Automox's own rule: a device counts as non-compliant only when a policy needs remediation, while pending work is tracked in a separate bucket.

Suggests valid values for device search fields while a query is being built, so Claude stops guessing at the spelling of a tag, an OS name or a status. It discovers values, it does not search devices.

Surfaces the machines Automox has flagged for immediate action. Every flagged device comes with its failing policies, each carrying a severity, the reason it failed and the date the policy was created.

Returns the server's own inventory of its tools, grouped by domain, with live availability. Automox keeps it loaded whatever module selection is configured.

Fetches the basic record of your Automox account: its identifier, name, type and timestamps. It says nothing about users, devices or policies, only about the account object itself.

Reads one account-level user record by identifier: status, account role, verification state and the type of two-factor authentication in place. It is the record behind access questions at account scope.

Opens one vulnerability remediation action set and shows its details, including a lifecycle status observed as active, ready or building. Automox notes the final value of that lifecycle is not confirmed.

Lists the vulnerabilities, identified by CVE, that are attached to one remediation action set. It is the bridge between a scanner import and the concrete issues Automox will help you fix.

Shows the solutions proposed for an action set: recommended patches or configuration fixes, with a severity per vulnerability and a status per device. Automox points out those values are coded strings without a published list.

Retrieves the results Automox stored on its side for a device search that already ran, using that search's execution identifier. Nothing is executed again, which keeps follow-up questions cheap.

Combines non-compliant devices, fleet health metrics and policy statistics in one call, which answers the question of where your compliance stands. Inner lists are capped, ten entries by default.

Checks one bulk data extract job: its status, from queued through complete to expired, a readiness flag, and whether a download link exists along with the time it expires.

Shows the mapping between devices and the policies and groups they belong to. Most questions about why a machine received something start from this mapping.

Returns the near-raw record of a device from its unique identifier. Integer policy codes get a readable label next to them, uptime is given in minutes, and a compliance rollup names whatever needs remediation.

Merges device detail, an inventory summary, installed packages and policy assignments into one profile. Claude answers about a machine without chaining four separate lookups.

Retrieves detailed inventory for one device across hardware, network, security, services, system and users, through the Console's device-details endpoint. A single category can be requested on its own.

Lists which inventory categories exist for a given device. They differ from one machine to the next, which is why Automox exposes them separately before you request the inventory itself.

Returns the field names and types the advanced search accepts, as a flat list. Claude reads it to build device queries that the search will not reject for an unknown field.

Shows the upcoming maintenance periods for one device, with start and end times computed from each window's rule and duration, and the type of each window. An optional end date limits how far ahead it looks.

Lists the upcoming maintenance periods of a server group, with start and end times worked out from the stored rule, start and duration. You can cap the look-ahead with a future date.

Combines the pre-patch report, pending approvals and patch policy schedules into one view of how ready the fleet is for Patch Tuesday. Automox frames it as the answer to that readiness question in a single call.

Opens one maintenance window by its identifier and shows its recurrence rule, duration, the groups it applies to and its current status, everything needed to understand what it blocks.

Reads one saved device search by identifier, with its name, description, query and metadata. It shows the definition only and does not run the search against your fleet.

Runs a saved search and returns the devices it currently matches, page by page. The answer reflects the fleet as it is now, not the last time someone looked.

Lists the scope options available for device searches. This metadata does not depend on any organization, and Claude uses it to pick the right scope before searching on tags or other fields.

Lists the searchable device fields grouped by scope, with the type of each one. Automox presents it as richer than the flat field list and meant for building typed queries.

Gets the full information Automox holds on one server group. The tool reference does not list the fields returned. The tool only reads that group's record.

Lists the CSV formats Automox accepts when you import a vulnerability remediation action set from a scanner export. It is a reference call, nothing is imported.

Reads one user by numeric identifier, including organization and server-group membership and the RBAC roles held. Automox states secrets never appear in what comes back.

Fetches the metadata of one API key belonging to a user, from the user and key identifiers. The key's secret is never part of the answer.

Brings back the configuration of one webhook subscription, the settings Automox uses to push events to an outside system.

Shows one community worklet in depth: its evaluation code, its remediation code, its requirements, and the same trust and availability signals the catalog search returns.

Opens a single zone, which is what Automox calls an organization, by its identifier. The zone's access key stays out of the reply.

Lists the role-based access roles defined in the account. It gives the vocabulary of permissions that user records refer to.

Returns every bulk export job of the organization with its type, its status, a readiness flag and whether a download link is available yet.

Lists the software installed on one device, with version, install state, severity, repository and whether Automox manages the package.

Summarizes device inventory and policy status across the organization, unmanaged machines included by default. Filters on policy status or managed state isolate, for example, non-compliant managed endpoints.

Returns the machines one or more policies currently target, by policy identifier. Automox describes it as a read-only way to size the blast radius before a policy runs or is edited.

Lists events in your organization, with filters on policy, device, user, event name or date range. For policy and patch events, the status field holds the raw exit code.

Lists the account-wide API keys with their name, enabled state and expiry date. Automox never exposes the secrets themselves through this call.

Returns the organization's API keys, metadata only: name, whether each is enabled, and when it expires. Secrets stay hidden.

Lists the organizations your key can see, with device count, device limit, parent organization and trial end date. Automox suggests it for navigating several organizations and watching capacity.

Lists the vulnerability remediation action sets in your organization, the imports from scanners that Automox turns into remediation work.

Shows every saved device search of the organization with their names, queries and metadata, so you can see what already exists.

Lists the saved searches whose current results include a given device, with an optional filter on search type. It works backwards from a machine to the searches that catch it.

Lists all server groups with device counts, assigned policies and identifiers, plus each group's refresh interval, the agent check-in cadence in minutes.

Shows which API keys one user holds, metadata only: name, enabled state and expiry. The secret behind each key is not shown.

Lists the users of the organization with name, email and RBAC roles in a lean format. Automox keeps internal secrets out of the result.

Shows recent delivery attempts for one webhook, newest first, with status, latency and error, optionally between two dates. Automox frames it as a troubleshooting tool.

Lists every event type a webhook can subscribe to, each with a short description, so you can choose what an integration should receive.

Lists all webhook subscriptions of the organization, page by page, giving a view of every outside system Automox currently notifies. Automox paginates the list with a cursor, so a long one arrives in several pages.

Names everyone assigned to one zone, identified by the zone's unique identifier, so you see at a glance who works inside that organization.

Lists the zones of your account, meaning its organizations, page by page. It is the top-level map for anyone managing several organizations.

Lists every zone a given user belongs to, the reverse view of the per-zone user list.

Retrieves the report of non-compliant devices, those needing attention because of policy failures or missing patches. Each failing policy now carries the upstream failure reason, shortened when long.

Summarizes patch approvals awaiting a decision. Each approval covers one software package, with its version, OS and CVE identifiers, for a specific policy.

Lists your Automox policies with summaries of type and status, page by page. Schedule days are decoded into readable form next to the raw bitmask.

Computes compliance per policy over the devices actually evaluated. Pending devices are reported on their own rather than counted against the rate.

Retrieves the configuration of one policy along with its recent history, so Claude can explain what it does and how it has been behaving.

Lists execution counts across the fleet over a time window, one row per policy with its run count, in a single round trip instead of one call per policy.

Reviews the recent executions of one policy. For each run it gives device counts per outcome, and Automox notes a run with only pending or not-applicable devices is a benign no-op.

Summarizes recent policy activity across the organization, counting runs by outcome so failures stand out. A bucket marks runs where every device was pending or not applicable.

Gets the history of a policy by its identifier, including runs and status. Each run lists how many devices landed in each outcome, which Automox distinguishes from a run status.

Returns aggregate policy execution counts, with an optional number of past days to look back over. It gives a single figure rather than a breakdown.

Gets per-device results for one policy run, filterable by device name and paginated. Exit codes are raw: zero means success, and negative values on Windows are system status codes.

Fetches per-device output for a specific execution token taken from the execution timeline: standard output, error output and exit codes.

Gets policy runs grouped by policy so that several policies can be compared side by side over the same period.

Gets the execution runs of one policy by identifier, with an optional range of days and sort order. A summary-only mode trims each run to its essentials.

Lists policy runs with filters on time range, policy name or type, and result status. Automox applies those filters after fetching, on its own side.

Shows devices with patches pending before the next scheduled patch window. Each device carries its highest severity, and Automox separates packages with no known CVE from those whose severity is unknown.

Dry-runs a policy's targeting to show which devices it would resolve to, before the policy is created or updated. Automox stresses nothing is created or changed by this call.

Executes a saved search by identifier and returns the matching devices, with paging and an optional choice of fields. Automox describes it as lighter than the full results tool.

Searches devices by hostname, IP address, tag, status or severity of missing patches, with several severities accepted at once.

Searches software packages across the organization, with filters on managed status or on packages awaiting installation. Results give name, version, severity and whether Automox manages them.

Searches maintenance and exclusion windows, filtered by group identifiers, by active or inactive status, and by one-time versus recurring. The recurrence filter ignores case. Results arrive page by page.

Searches Automox's community worklet catalog and returns names, descriptions, categories, OS compatibility and trust signals such as whether a worklet is verified.

Shows whether the Splashtop remote-control client is installed and registered on a device, with install time and any install error. Automox notes both states are independent.

Tells whether end-user consent is required before a remote session can start on a device. It reads the setting only, nothing more.

Shows the number of active remote sessions, the maximum allowed, and whether capacity permits a new one. That last flag reflects capacity only.