Introduction

Xavier is a cross-platform device management service: one console that enrolls, configures, secures, and monitors your Macs, iPhones, iPads, Apple TVs, Windows PCs, and Android devices. It manages each platform through the platform's own native management channel, so there is nothing bolted on and nothing extra to maintain on the devices.

What Xavier manages

• Apple: Mac, iPhone, iPad, and Apple TV, with zero-touch Automated Device Enrollment, supervision, configuration profiles, and volume app licensing.
• Windows: enrollment with nothing to install, a visual policy builder for password rules, BitLocker, Defender, firewall, and Windows Update, and an optional agent for software inventory and installs.
• Android: full device control with no Google account required, plus optional Managed Google Play and Samsung Knox zero-touch enrollment.
• Software: App Store and volume-purchased apps, custom packages, Munki, developer package managers, automated third-party patching, and vulnerability scanning.
• Control: the applications, websites, AI tools, and USB drives your fleet is allowed to use, each enforced on the device itself and reported honestly where it is not.

The pieces

Your tenant

Every customer gets their own tenant: a dedicated console address, an isolated database, and credentials that only work for that tenant. Details are in Tenant isolation.

Ready to begin? Start with Getting started.

Getting started

Xavier is a hosted service, so there is nothing to install. When your tenant is provisioned you receive your console address and an administrator account. From there, setup is a short path: secure your account, connect Apple, and enroll your first devices.

1. Sign in and secure your account

• Sign in at your console address and change your password right away.
• Invite your team under Users. Administrators get full control, auditors get read-only access to everything, including reports and the audit log.

2. Connect your Apple push certificate

Apple devices cannot enroll until your organization's push certificate is in place. It takes a few minutes in Settings, then Certificates, and is walked through in Apple certificates.

3. Connect optional integrations

• Apple Business Manager: connect Automated Device Enrollment for zero-touch, supervised Apple devices, and a VPP token for volume-purchased apps.
• Samsung Knox: zero-touch enrollment for Samsung Android devices.
• Managed Google Play: Google's app catalog for Android, if you want it alongside the standalone agent.
• Storage: connect your own S3-compatible or Google Cloud Storage account. This is required before you can upload packages, apps, or signage media.
• Munki: have Xavier manage a Mac software repository in your storage, or connect one you already run.

4. Enroll your first device

• Apple enrollment: an enrollment profile for any device, or Automated Device Enrollment for zero-touch.
• Windows enrollment: your tenant's enrollment credential, entered in Windows Settings.
• Android enrollment: a QR code at device setup.

5. Set your baseline

• Create device groups, including smart groups that maintain themselves.
• Build and assign Apple profiles and Windows profiles.
• Review the compliance rules and adjust them to your policy.

Apple certificates

Apple requires each organization to hold its own push certificate, which lets Xavier reach your Apple devices. Setting it up is a one-time flow that takes a few minutes in the console; Xavier tracks the expiration and warns you well before it runs out.

Setting up the push certificate

• In the console, open Settings, then Certificates and generate a push certificate request. Xavier prepares and signs the request for you, and hands you a file to give to Apple.
• Sign in at identity.apple.com/pushcert with an Apple Account your organization controls, and upload the request.
• Download the certificate Apple returns and upload it back on the same settings page.

That is the whole setup. The certificate's status and expiration date stay visible under Settings.

Device identity certificates

Per-device identity certificates need no setup at all. Xavier's built-in certificate authority issues one to each device during enrollment, using single-use challenges that cannot be replayed. You can inspect, revoke, and reissue certificates per device, expirations are monitored for you, and a fleet-wide verification report is available. Details are in the Security model.

Settings reference

Everything configurable about your tenant lives in the console under Settings and the per-area pages. This is a map of what is where.

Apple enrollment

Apple devices enroll either through an over-the-air enrollment profile (any device) or through Automated Device Enrollment for devices in Apple Business Manager or Apple School Manager (zero-touch, with supervision). In both cases the device receives its own SCEP-issued identity certificate during enrollment.

Profile-based (OTA) enrollment

• In the console, open the enrollment page and download or share the enrollment profile (.mobileconfig).
• Open the profile on the device and approve it in Settings (or System Settings on a Mac).
• The device requests its identity certificate over SCEP with a one-time challenge, checks in, and appears in the device list.

Automated Device Enrollment (ADE)

ADE connects Xavier to Apple Business Manager or Apple School Manager so devices enroll themselves at first boot:

• In the ADE settings, generate a key pair and download the public key.
• In Apple Business Manager, add Xavier as an MDM server using that public key, and download the server token (.p7m).
• Upload the token in Xavier and sync. Your device roster appears in the console.
• Create one or more ADE profiles: choose which Setup Assistant panes to skip, supervision, and other setup options.
• Assign profiles to devices. New devices get the default profile automatically; devices can also be released back to Apple Business Manager.

Once assigned, a device that powers on (or is erased) walks straight through Setup Assistant into a supervised, enrolled state, with its profiles, restrictions, and apps arriving before the user reaches the desktop or home screen.

What happens at enrollment

• The device is issued an identity certificate through the built-in certificate authority.
• Xavier records its inventory: hardware, OS, security posture, installed profiles, certificates, and apps.
• Built-in profiles assigned to the device (or its groups) are pushed automatically.
• On a Mac, you can additionally deploy the macOS agent for package management and scripts.

Windows enrollment

Devices enroll through the built-in Windows management channel, so there is nothing to install and nothing to stage first: a PC is enrolled and inventoried from the Windows Settings app. Enrollment issues the device its own certificate, and policy is delivered through Windows itself. The optional agent is deployed afterwards, over the channel enrollment just established.

What you need

• Windows 10 or 11 (tested through Windows 11 24H2).
• Your tenant's enrollment credential, shown in the console under Windows, then Enrollment info.

Enrolling a device

• In the console, open Windows, then Enrollment info. Xavier shows the enrollment address and a per-tenant credential (an email-shaped user plus a code), which you can rotate at any time.
• On the device, open Settings, Accounts, Access work or school and choose Enroll only in device management.
• Enter the enrollment email and code. Windows finds the server and completes enrollment on its own.
• The device appears in the Windows device list, inventoried and ready for policy.

After enrollment

• Inventory: hardware, OS build, BitLocker, Secure Boot, Defender health, firewall state, and update status, refreshable on demand.
• Policy: assign profiles built in the Windows profile builder, individually or through groups; devices converge on the desired state automatically.
• Commands: lock, wipe (several variants), reboot, rename, Defender scans, and more; see Remote commands.
• Diagnostics: collect a diagnostic log archive from a remote device and download it from the console, no screen-sharing session required.
• Updates: review and approve Windows Updates.

Android enrollment

Xavier manages Android through two parallel planes, and you can use either or both: a standalone Device Owner agent that needs no Google services at all, and the Android Management API with Managed Google Play. Samsung devices additionally support Knox Mobile Enrollment for zero-touch provisioning.

Device Owner agent (QR provisioning)

The Xavier DPC (device policy controller) is a native agent that becomes Device Owner during device setup. It uses no Google account, no Managed Google Play, and no Firebase; devices work on AOSP builds and networks without Google reachability.

• In the console, open Android, then Enrollment and create an enrollment token. Xavier renders a provisioning QR code that embeds the agent download URL, its signing certificate checksum, and the token.
• Factory-reset the device (or start with a new one). On the welcome screen, tap the screen six times to start QR provisioning.
• Scan the code. Android downloads the agent, verifies its signature against the pinned checksum, and sets it as Device Owner.
• The agent enrolls with its per-device token and starts syncing inventory and policy.

Android Management API and Managed Google Play

If you want Google's management plane and the Managed Google Play store:

• Generate the enterprise signup URL from the console and complete Google's signup flow.
• Bind the resulting enterprise to Xavier; enrollment tokens and policies are then managed from the same Android pages.
• Approve apps in the embedded Managed Google Play view and deploy them to devices or groups, including private apps you publish yourself.

Samsung Knox Mobile Enrollment

Knox Mobile Enrollment is the Android analog of Apple Automated Device Enrollment: Samsung devices purchased through participating resellers enroll automatically at first boot.

• Connect your Samsung Knox account credentials in the console (OAuth 2.0, or a legacy JSON key).
• Create a KME profile pointing devices at your Xavier server and DPC.
• Sync the device roster and assign profiles; assigned devices provision themselves out of the box.

Devices and inventory

Every enrolled device has a detail page that brings together its hardware, software, security posture, history, and actions. Devices report on a schedule, on check-in, and on demand; devices running the Xavier agent (Macs and Windows PCs) additionally stream inventory in real time.

What Xavier tracks

Organizing the fleet

Devices carry tags, notes, and organizational fields, and belong to device groups that drive policy. You can also collect your own facts about a device with device attributes. The device list filters by platform, group, compliance state, and free-text search.

Reports

• App distribution: which apps are installed across the fleet, with drill-down to the devices running a given app or version.
• OS distribution: OS versions across the fleet, with drill-down to devices on a given version.
• Application usage: how much each app is actually used, and which installed apps nobody has opened. Off until you turn it on; see Application usage.
• AI inventory: the AI tooling present across the fleet; see AI inventory.
• Device compliance: pass/fail against your compliance rules; see Compliance engine.
• Activity: who (or what, including AI tokens) did what, when, with what result.
• Security overview: fleet-wide posture at a glance.

Notifications

Xavier raises notifications for new enrollments, unenrollments, devices falling non-compliant, devices offline past a threshold, certificate expiration, profile install results, jailbreak detection, OS-version drift, Munki source events, AI policy and credential findings, script automation failures, attribute collection failures, and volume-purchase licenses running low. Each event type can be shown as a bell notification, a toast, or muted, and the choice is per user rather than per tenant. Alerts can also be delivered outside the console; see the settings reference.

Device groups

Groups are how policy scales past individual devices. Xavier supports two kinds: static groups you curate by hand, and smart groups whose membership is computed from conditions and kept up to date automatically as devices change.

Static groups

Create a group, pick its devices, done. Static groups suit deliberate collections: a small test group you roll changes out to first, the conference room Apple TVs, executive laptops.

Smart groups

Smart groups define membership by rule, and a rule can combine four kinds of condition, all of which must match:

• Platform: Mac, iPhone, iPad, Apple TV, Android phone or tablet, Windows.
• Compliance: devices failing (or passing) rules you pick from the compliance catalog. "Macs without FileVault" is the FileVault rule, read as failing.
• AI posture: what the device carries in AI tooling; see AI inventory.
• Device attributes: values collected by your own scripts; see Device attributes.

Membership is recomputed whenever a device changes in a way that could affect it, so a Mac that upgrades its OS or falls out of compliance moves between groups on its own. Compliance-based membership is recomputed on every read in the console and swept hourly for everything downstream.

Folders

Groups can be filed into folders once a flat list stops being readable. Folders are organizational only: nothing that consumes a group (profiles, signage, compliance) knows or cares which folder it is in.

What groups drive

• Apple configuration profile deployment and DDM scoping.
• Windows profile assignment with desired-state reconciliation.
• Android Management API policy groups.
• Per-group Munki manifests and app auto-deployment scope.
• Signage sends to every screen in a group.
• The macOS Root Helper rollout scope.

Device attributes

Inventory covers what every device has in common. A device attribute covers the rest: a small script you write that returns JSON, collected on a schedule, whose values land on the device record. What makes it more than extra inventory is what happens next: attribute values are conditions a smart group can be built from, and a group is something an automation can act on. Together those close a loop: the fleet measures a state you care about, the devices in that state gather themselves into a group, and a script runs on them.

Defining one

An attribute is written in the console under Scripts, on the Device Attributes tab. It carries the script and its contract:

• Platform and interpreter: macOS or Windows, in any interpreter that platform accepts.
• The keys it promises to emit, each declared with a type (string, number, boolean, or date) and an optional label and unit.
• A cadence: hourly, daily, at check-in, at login, or manual.
• A scope: everything, whole platforms, or chosen groups, with exclusions that win over every inclusion.
• A timeout, so a collection script that hangs cannot hold anything open.

Why the keys are declared

Declaring the keys up front rather than inferring them from whatever the script last returned buys three things. The condition builder can offer you a typed field list instead of a free-text box. A value that arrives as text where a number was promised is converted once, on the way in, rather than being coerced differently by every operator that reads it later. And a script that quietly stops emitting a key becomes a visible error, instead of a condition that silently stops matching anything.

From a value to an action

This is what attributes are for, and it is worth following end to end:

• Your script reports a fact about the device: the version of an internal tool, whether a required agent is actually running, how much free space a build volume has, whether a licence file is where it should be.
• A smart group is defined by a condition on that value. Membership is not a list anyone maintains: devices join and leave as the value changes underneath them.
• A script automation watches that group and runs when a device enters it, so the fix arrives because the device is in the state that calls for it, not because somebody noticed.

The same group can drive everything else groups drive: profile assignment, app scope, Munki manifests, signage. And because the group is defined by device state rather than by a name on a list, a device that drifts back out of that state leaves on its own.

Values are also readable on the device page alongside the rest of that device's inventory, and an automation can collect an attribute after it runs as a check on whether the run did what it was supposed to.

Remote commands

Commands are sent from a device's detail page or the API, stream to the device over its platform's native channel, and report results back into the device's history. Dispatch is idempotent (a duplicate of an already-queued command type is rejected), capability-gated (commands a device cannot honor, like restarting an unsupervised iPhone, are refused up front), and superseded commands are cleaned up automatically.

Apple

Xavier implements about 45 Apple MDM command types. The ones you will reach for most:

Windows

• Security: lock, wipe (standard, protected, and variants that persist provisioning or user data), Defender quick, full, and offline scans, signature updates.
• Lifecycle: reboot now or on a schedule (one-time or daily), rename (with serial number and random tokens), create a local user, unenroll, refresh inventory.

Android (Device Owner)

• Security: lock, erase (with options for external storage, eSIM, and factory reset protection data), reset passcode, set lock screen message.
• Apps and system: install and uninstall apps, clear app data, enable system apps, install system updates, reboot, set time.
• Diagnostics: refresh inventory, capture a bug report, pull device logs.

Agent commands

Devices running an agent accept a further set of commands over the agent's live connection, which arrive in seconds rather than waiting for a check-in.

• macOS: install, update, and remove packages across Homebrew, npm, pip, and Ruby Gems, manage Homebrew taps, install managed Mac apps, run scripts, and force an inventory sync.
• Windows: install and uninstall applications, set up Chocolatey and apply its package set, re-collect the installed application list, run scripts, and force an inventory sync.

See Package management, Scripts, the macOS agent, and the Windows agent.

Tracking results

Every command records who sent it, when it reached the device, and what came back, in the device history and the fleet-wide activity log. Pending commands can be cancelled before delivery.

Apple configuration profiles

The visual profile builder assembles Apple configuration profiles payload by payload, with sensible defaults and inline validation, then signs and deploys them to devices or groups. You can also upload a raw .mobileconfig built elsewhere.

Payload catalog

The builder covers roughly forty payload types, including:

Deployment

• Deploy a profile to individual devices or to groups; install and removal are tracked per device.
• Profiles are signed before delivery, so devices show them as verified.
• Install results (success or failure) surface as notifications and in the device history.
• A per-profile debug view shows exactly what a device received.

Built-in profiles

Xavier seeds a few profiles it knows how to keep correct for your server:

• Agent configuration: points the macOS agent at your server with a per-tenant URL.
• FileVault escrow: turns on FileVault with the escrow certificate so recovery keys land in Xavier. See FileVault key escrow.
• Agent permissions: Full Disk Access (PPPC) and Location Services approvals for the agent.

Declarative Device Management

Declarative Device Management (DDM) is Apple's modern management protocol: instead of the server polling and pushing, the device holds a set of declarations, applies them itself, and proactively reports status changes. Xavier supports DDM alongside classic MDM, per device, so you can adopt it gradually.

Supported declarations

• Software update enforcement: require a specific OS version by a deadline, or track "latest" with a deferral window, declaratively.
• Software update settings: automatic update behavior.
• Passcode settings: passcode requirements as a declaration with device-reported compliance.
• Accounts: CalDAV, CardDAV, and LDAP accounts.
• Screen sharing host configuration for Macs.
• Certificates and credentials: security assets delivered by reference.
• Legacy profile: wrap any classic configuration profile in a declaration, letting the device manage its lifecycle declaratively.

Status subscriptions

Xavier subscribes to device status items, so DDM-enabled devices report OS version, passcode state, and declaration outcomes as they change, without being asked. Reported status is visible on the device page next to the declarations that produced it.

Scoping

Declarations scope to devices or groups, and DDM itself is enabled per device, so a pilot group can run declaratively while the rest of the fleet stays on classic MDM until you are ready.

Windows profiles

Windows policy is built in the same visual builder style as Apple profiles: pick the settings, assign the profile, done. Behind the scenes Xavier translates your choices into native Windows policy and keeps each device reconciled against its desired state, so a PC that missed a change simply converges the next time it checks in.

Policy catalog

Assignment and reconciliation

• Assign a profile to devices or groups; per-device exclusions are tracked so you can carve out exceptions without restructuring groups.
• Xavier computes the desired state for each device and issues only the operations needed to reach it.
• Removing a profile (or a device from a group) generates the corresponding delete operations.

App distribution

Xavier distributes software to every platform it manages, through each platform's native mechanism plus its own package libraries for custom software.

Apple (Mac, iPhone, iPad, Apple TV)

• App Store: search the App Store from the console and install to devices as managed apps, with managed app configuration injected where supported.
• Volume Purchasing (VPP): upload your Apple Business Manager location token, sync the purchased catalog, and assign or revoke licenses per device.
• Custom apps: upload an IPA; Xavier hosts it with the manifest Apple devices need for installation.

macOS packages

Upload .pkg, .dmg, or .zip files to the Mac app library; Xavier parses their metadata and deploys them through the agent, which downloads the package and installs it silently through the privileged helper, then refreshes inventory. A .zip covers the growing number of apps that ship as a plain .app bundle you drag to Applications, with no installer at all; compress the bundle and upload that. For ongoing third-party app patching at scale, use Munki.

Windows

Upload MSI, EXE, or MSIX and APPX installers to the Windows app library and deploy them to devices or groups; removal is supported the same way. Xavier reads the installer metadata, picks the silent switches for whichever toolkit built the installer, and verifies the download before running it and the installed-programs list afterwards, so an installer that exits cleanly without installing anything is reported as a failure rather than a success. EXE deployment is carried by the Windows agent.

Android

• APK library: upload APKs and deploy them to Device Owner devices, optionally blocking uninstallation.
• Managed Google Play: approve public apps or publish private ones in the embedded Play view, then deploy per device or per group through policy.

Where files live

Package and media distribution runs from your own storage: connect any S3-compatible service or Google Cloud Storage under Settings before uploading. App Store, VPP, and Managed Google Play deployments need no storage connection; only your own uploads do. Your bucket is never made public: devices authenticate to Xavier, which is the only party that talks to your storage account. See Storage and file delivery for how a file actually reaches a device, and for how your storage credentials are handled.

Munki integration

Munki is the de facto open-source standard for managing Mac software at scale. Xavier embeds a full Munki workflow: it manages a repository in your own storage, or connects to one you already run, and the entire catalog, package, and manifest lifecycle is managed from the console.

Repository options

• Managed in your storage: Xavier runs the repository in your connected S3-compatible or Google Cloud Storage account and serves it to your Macs with per-repo credentials. You bring the storage; Xavier does the rest.
• Bring your own: connect an existing repository over S3-compatible storage, SFTP, or Git.

A connection test validates credentials before saving, and a reconcile action keeps Xavier's database and the repository contents in sync.

Packages and catalogs

• Upload packages from the console (chunked, so large installers work), and edit pkginfo metadata inline.
• New versions land in a testing catalog and promote to production when you are ready, per package version.
• Catalogs can be rebuilt on demand.

Manifests

Manifests decide which Macs get which software: a site-wide default, per-group manifests, and per-device manifests, composed in that order. Assignments are managed in the console, not by editing plists.

Client deployment

Xavier deploys the Munki client itself to your Macs and points it at the repository with the right credentials, so bringing a new Mac into the Munki fold is a single action.

Munki Sources

Munki Sources automates the most tedious part of Mac software management: noticing that a third-party app shipped an update, fetching it, and importing it into your repository. Point a source at where an app publishes its releases and Xavier does the rest.

Source types

• GitHub releases: track a repository's release feed.
• Sparkle appcast: track the update feed most Mac apps already publish.
• Direct URL: a stable download link whose contents change with each release.
• Web page: scrape a download page for version and link.

The pipeline

• Detect: Xavier checks the source for a version newer than what the repository holds.
• Download and verify: the artifact is downloaded and verified against a pinned checksum before anything else happens.
• Import: the new version is imported into the Munki repository in the testing catalog.
• Promote: promote to production manually, or mark the source auto-promote for apps you trust. Either way, you can be notified when an update appears.

Health and history

Each source keeps a full import history, and source health is monitored: a feed that stops working or a checksum that stops matching raises an alert instead of failing silently. Six distinct Munki source events can be routed to the notification center per your preferences.

Package management

Beyond apps, Xavier tracks the developer package ecosystems across the fleet. On macOS that means Homebrew, npm, Python pip, and Ruby Gems, reported in real time by the agent, with search, install, update, and remove driven from the console. On Windows the agent reports npm, pip, Ruby Gems, Go binaries, and .NET global tools, alongside Chocolatey and winget.

Per-device catalogs

Every device page lists its installed packages per manager, with versions and available updates. Fleet-wide views surface which devices have a given package and where updates are pending.

Remote actions on macOS

• Search each ecosystem's registry from the console and install to any device.
• Update or remove packages remotely, per device.
• Install Homebrew itself on Macs that lack it.
• Run bulk remediation from compliance results; see Compliance engine.

Chocolatey on Windows

Chocolatey is the managed channel on Windows. The agent bootstraps it on devices that do not have it, registers your Xavier feed as a source, and keeps the package set you assigned applied, re-checking on its own schedule. Installed packages come back in inventory whether or not the agent has the privileges to change them.

The other Windows ecosystems (npm, pip, Ruby Gems, Go, .NET tools) are inventoried and feed compliance and vulnerability scanning, but the console does not yet install or update them per device the way it does on macOS. Where an action does not exist, the console does not offer it.

Homebrew taps and drift

Define the Homebrew taps your fleet should carry; Xavier detects drift between the fleet configuration and what each Mac actually has, and taps or untaps remotely to converge.

Runtimes and vulnerabilities

Developer machines carry risk that traditional MDM never sees: outdated language runtimes and vulnerable project dependencies. Xavier watches both, on Macs and on Windows PCs running the agent.

Language runtime governance

The agent inventories installed runtimes (Java, Node, Python, Go, Ruby on macOS, and Java, Node, Python, Go, .NET on Windows), including the copies installed by version managers rather than only the ones on PATH. Xavier evaluates Node, Python, Ruby, Go and .NET against:

• End-of-life dates: runtimes past their support window are flagged.
• Currency: whether the installed build is the latest in its release cycle.

Findings appear on the device page and in compliance. A runtime below its supported baseline is reported as unmanageable rather than updated automatically, because something on the machine is usually pinned to it.

Project dependency scanning

The agent finds project manifests on disk (package.json, Maven and Gradle builds on macOS, and those plus requirements.txt, pyproject.toml, go.mod and .NET project files on Windows), and Xavier annotates the declared dependencies:

• Dependencies with known vulnerabilities, matched against the GitHub Advisory Database.
• Outdated dependencies, with the current and latest versions.
• Per-project remediation, pushed to the device from the console. Windows devices are scanned and reported the same way; pushing the fix from the console is macOS today.

Scanning reads manifests as text and never runs a build tool: no dependency resolution, no restore, no install. Those download and execute code on a managed device, which an inventory pass has no business doing. A version that is not written out concretely, such as a Maven property or an unpinned range, is skipped rather than guessed, because a guessed version produces a confident CVE verdict that may be wrong in the direction that matters.

Vulnerability and currency findings can back compliance rules, so a device carrying a vulnerable dependency tree shows up as non-compliant.

AI inventory

Local AI models, coding agents, and MCP servers now live on the same laptops that hold your source code and customer data, and traditional device management cannot see any of it. Xavier discovers what AI is running on your Macs, where it came from, and what it is wired up to, then tells you which of it is a problem.

Xavier then measures what it finds against the policy you set, and scores each Mac on it. Discovery itself changes nothing on a device: it lists, it does not disable or remove. Acting on what it finds is a separate, deliberate step, described in AI enforcement below.

What Xavier discovers

• Local models: model files on disk, with their sizes and content digests, so you know what unreviewed weights your fleet is carrying and where they came from.
• Inference runtimes: the software that loads and serves those models, including whether it is running and which local port it answers on.
• Coding agents and AI apps: assistants that can read files and run commands, and the AI apps people use every day.
• MCP servers: the external tools an AI assistant has been connected to, which tools each one offers, and which software package it runs.
• Browser and editor extensions: AI extensions in Chrome and in code editors, including which ones can read the contents of the pages someone visits.

Vulnerable AI tooling

An MCP server is ordinary third-party software, usually an npm or Python package launched in the background. Xavier resolves which package each one is and checks it against the same GitHub Advisory Database it already uses for your project dependencies, so a known vulnerability in an AI tool is reported exactly like any other.

Exposed credentials

AI tool configuration files routinely hold live API tokens. Xavier reports which file and which setting contains one, and treats a configuration file inside a source-code repository as the most serious case, because a token there can be committed and shared without anyone noticing.

The credential itself never leaves the Mac. The device recognises that a value looks like a token and reports only that fact, its location, and what kind it is. The value is never transmitted, never stored by Xavier, and never appears in a report, an alert, or an export.

The files, settings and credential formats checked are listed in AI governance checks.

Deciding what is allowed

Discovery answers what is running. An AI policy says what should be. You approve the inference runtimes, coding agents and AI clients your organization permits, the MCP server packages you have reviewed, and the registries model weights may come from. Anything can also be blocked outright, and blocking always wins over approval.

Until you write a policy, no allowlist rule is evaluated at all. An organization that switches collection on does not suddenly find its whole fleet failing: not having stated a policy is not the same as breaking one. Approving a tool takes effect across every Mac immediately, rather than waiting for each one to check in.

Compliance rules and risk scores

AI checks sit alongside the compliance rules you already have, scoped to Macs. Two are on from the start because they need no policy of your own: MCP server packages with known advisories, and credentials sitting in AI tool configuration. The rest wait until you have written a policy for them to measure against. Each one is described in AI governance checks.

Each Mac also gets an AI risk score out of 100, and every score breaks down into the findings that produced it, with the points each contributed. A credential inside a code repository weighs heaviest, because it may already have been shared. Stale package versions weigh least. No single kind of finding can dominate the score on its own, so forty out-of-date packages never outrank one leaked token.

A Mac that has not been assessed is always counted separately from a Mac with nothing to report. An unmonitored fleet never appears as a healthy one.

Acting on what you find

Findings become device groups. A group can be defined by AI posture the same way it is defined by platform, so "Macs with an unapproved MCP server" or "Macs where AI risk is critical" is a live list that machines join and leave on their own as their posture changes. Alerts fire the first time a Mac breaches AI policy, not on every check afterwards.

Everything on this page detects, assesses and reports. Enforcement is a separate set of controls you switch on deliberately, and it is covered in AI enforcement below, where each mechanism is named alongside what it actually requires.

AI bill of materials

Everything discovered can be exported as a dated inventory in JSON or CSV, and saved as a snapshot so you can answer "what changed since our last review". Snapshots record the fleet's risk posture as well as its inventory, so the question can be "what got worse" and not only "what appeared". Each export records which collection settings were switched on at the time, so a zero is never ambiguous between "nothing found" and "we were not looking".

Collection is off until you turn it on

AI inventory is disabled for every organization by default. Nothing is collected from any device until an administrator enables it in Settings, and there is a second, separate switch for the part that reads configuration files:

• Listing installed AI software works the same way as the existing package inventory.
• Reading the contents of configuration files in someone's home folder is a bigger ask, so it is its own decision and is also off by default. Without it, MCP server discovery and credential findings stay empty.
• You can exclude folders entirely. Exclusions are applied on the Mac, before anything is sent, rather than filtered after the fact.

Xavier never collects prompts, conversations, model responses, or anything typed into an AI tool.

Keeping up with new tools

AI tools appear faster than any list of them can be maintained, so Macs report what they find rather than deciding what counts. Recognition happens in the Xavier service, which means support for a new tool arrives without updating or touching a single device. Anything not yet recognised is still shown to you, rather than quietly reported as nothing.

Available on macOS. Windows and Android devices do not report AI inventory.

Scripts

The script library covers the gaps between built-in features: anything you can express in a shell or scripting language can run on the Macs and Windows PCs in your fleet, from a proper editor, with history.

Writing scripts

• Each script declares its platform, which decides the interpreters it can use. macOS: bash, sh, zsh, python3, ruby, perl, node. Windows: powershell, pwsh, cmd, python, node.
• A syntax-highlighting editor in the console, with tags to keep the library organized.
• Scripts are versioned records: edit in place, run anywhere.

Running and results

• Run a script against a device from the library; delivery happens over the agent's live connection.
• Every run is recorded with its output and exit status, browsable per run in the run history.
• Runs are bounded by a timeout, so a script that hangs does not hold a device or a queue open.
• To run a script on a schedule, on check-in, at enrollment, or whenever a device enters a group, see Script automations.

Elevation

On a Mac, scripts run as the agent user without elevation by default. A script marked run as root executes through the privileged Root Helper instead, which only accepts requests from a code-signature-verified agent. Root execution is therefore both opt-in per script and gated by the fleet's Root Helper policy; see the macOS agent.

On Windows the agent already runs as a system service, so a script it runs is elevated and there is no per-script flag to set. Deploy the agent in its constrained mode where that is not what you want.

Script automations

An automation is a saved script, a scope, and a trigger: run this, on these devices, when this happens. It is how a fix stops being something an administrator remembers to apply and becomes something the fleet applies to itself.

Triggers

The condition trigger is the one that turns a fleet into something self-correcting, and it is worth understanding what it can watch. A smart group can be defined on compliance state, AI posture, platform, and on device attributes, which are facts your own scripts report. That last one is what lets an automation respond to anything you can measure rather than only to what Xavier collects out of the box: the attribute reports the state, the group collects the devices in it, and the automation runs on them as they arrive.

It deliberately reuses smart groups rather than introducing a second condition language. "Devices where X" already has one answer in Xavier, and a second one would disagree with the first at the edges.

Alongside the trigger, a frequency decides how often a given device may be acted on: once, once per day, once per week, once until it succeeds, or every time. Some combinations are refused outright: agents check in every five minutes, so a check-in trigger that ran every time would run the script nearly three hundred times a day on every device.

Scope

Target everything, whole platforms, or chosen groups, static or smart, with an exclusion list that wins over every inclusion. Exclusions are not a nicety: the first thing anyone does after a bad fleet-wide script is carve out the build machines and the executives' laptops, and without exclusions that means maintaining a "not this one" group per automation.

Guardrails

Running arbitrary code across a fleet on a timer is the feature most capable of ruining a week, so the safety behavior is part of the feature rather than advice in the interface:

• Every automation starts paused. One authored in a single sitting cannot begin firing across the fleet the moment it is saved.
• A canary stage. Run against a handful of devices you name, and only widen to full scope once that looks right.
• A circuit breaker. Consecutive device failures pause the automation and record why, rather than working through the rest of the fleet.
• Nothing is retroactive. Enabling an automation applies from the next trigger onward. A condition automation does not fire for the devices already sitting in the group, so switching one on never dispatches a burst of unattended changes for a state that has been true for weeks.
• Concurrency and batch limits. Cap how many devices are acted on at once and how many per run, so a fleet-wide automation lands as a wave rather than all at once.
• Confirmation on large scopes. Above a threshold, a person confirms before the automation runs.
• Offline devices are either queued for a bounded window or skipped; your choice, per automation.

Knowing it worked

Every run lands in the run history and the activity log with its output and exit status, attributed to the automation that fired it, and you can be notified on failure only, on every run, or never.

An automation can also name an attribute to collect once the run finishes, so success is judged by the state of the machine afterwards rather than by an exit code. Verification never blocks the run. Where the automation was triggered by a condition, this closes on its own anyway: the script changes the state, the next collection reports the new value, and the device leaves the group that called for the fix. A device still sitting in that group is the report that it did not work.

Application usage

Installed-app inventory answers what is on a device. Application usage answers whether anyone actually opens it, the question behind every license renewal and every "do we still need this?" conversation. It is reported by the agent on Macs and by the Android agent, and it is off until you turn it on.

Turning it on

• A master switch, plus a separate switch per platform. The platforms do not measure the same thing, so you may reasonably want one and not the other.
• Retention: how many days of usage to keep. Records are deleted automatically when they age out.
• Never-record list: applications that are never measured at all. The exclusion is applied on the device, before anything is transmitted, rather than being filtered out after storage.

Usage is aggregated into daily totals on the device itself. What reaches Xavier is "six hours of this app on this day", never a timeline of when someone opened and closed it. That record is never built, rather than being built and discarded.

The report

The Application Usage report ranks apps by how much they are actually used over a period you choose, and lists dormant apps: installed, but untouched for the whole window. That second list is the one that pays for the feature, since an app nobody has opened in ninety days is usually a license you are still paying for.

What the numbers do not cover

The report states its own coverage: how many devices are reporting out of how many exist, and which platforms cannot report at all. iPhones, iPads, Apple TVs and Windows PCs contribute nothing, so an app that looks unused may simply be used somewhere that cannot say so. Android is reported separately again, because a device where nobody granted usage access can report that an app was launched but not how long it was used, and presenting those two as one number would be a chart that lies.

Blocked applications

Name the applications your organization does not permit, choose which devices the rule covers, and Xavier stops them running. A rule can apply to every device or to specific device groups, so a restriction that belongs to one team does not have to be imposed on everyone.

Which platforms enforce this

Two platforms enforce, and they do not enforce the same way. Xavier says which is which rather than flattening the difference, because the difference is what somebody at the device actually experiences.

• macOS: the Mac refuses to start the application, so it never runs.
• Android: the device suspends the package, so it greys out and cannot be opened, and the person holding the phone is told why. You can choose to hide it completely instead, which also stops it if it is running. Hiding is off by default, because taking something away with no explanation earns a support ticket rather than compliance.

Windows and iOS do not enforce application blocking today, and the console says so on each of those tabs rather than offering a rule that would do nothing. The two are not the same kind of gap: on Windows the enforcement piece has not been built into the agent yet, while iOS offers no mechanism for it at all.

Blocked means it never opens

Xavier refuses the launch itself, using Apple's Endpoint Security framework. The application does not start: no window appears, no document is half-opened, and there is nothing to clean up afterwards. This is not the same as watching for an app and closing it a moment later, which is what most people picture and which would risk losing whatever somebody had just typed.

Copies that are already open when you add a rule are left alone unless you ask otherwise. Closing them is a separate choice on each rule, off by default, because closing an application somebody is working in loses their unsaved work. The console shows how many Macs are running the app before you decide.

How an application is recognised

On a Mac, rules match on the application's code signature rather than its name or location, so renaming a copy, moving it to the Downloads folder, or keeping a duplicate elsewhere does not get around a rule. On Android a rule names the package.

You choose applications from what your fleet actually has installed rather than typing an identifier, so a rule cannot quietly match nothing because of a typo. Nobody knows a signing identifier or an Android package name by heart, and a mistyped one produces the worst failure a security control can have: a rule that looks configured and does nothing. Mac applications with no code signature at all cannot be blocked this way, and the console says so plainly instead of offering a rule that would never take effect.

What has to be in place

Blocking is done by a security extension that ships inside the Xavier agent. It has to be approved before it can do anything, and Xavier deploys the profile that approves it, so there is no payload for you to assemble by hand.

On a supervised or automatically enrolled Mac this is silent. On a Mac that was enrolled by the person using it, the profile installs but they still have to allow the extension once in System Settings. That is Apple's rule, not ours, and we would rather say so than have it surprise you. The console shows which Macs are actually enforcing, so a rule is never assumed to be in force where it is not.

What can never be blocked

Some things are refused whatever a rule says: the parts of macOS a Mac cannot be used without, and Xavier itself. A rule blocking the management agent would remove any way of undoing the mistake remotely, so it is not permitted. Xavier also fails open by design, meaning that if anything goes wrong with a policy the applications run. A Mac that cannot start programs is a far worse outcome than an app briefly opening that should not have.

What people see, and what you see

When a launch is refused, the person at the Mac is told the application is blocked by organization policy, rather than being left with an app that simply will not open. You get a record of what was blocked and when, and repeated attempts are grouped into one entry with a count rather than filling the log.

What this does not cover

Blocking an application cannot see a browser tab. A service with a web version is still reachable through it, and stopping that is the job of the network filter, which denies the destination instead. Blocking an AI tool in AI policy writes both kinds of rule at once for exactly this reason. Rules written that way appear here like any other, and are marked with where they came from, so lifting the decision behind one removes precisely the rules it created and nothing you wrote by hand.

Website and destination blocking

Name the destinations your organization does not allow devices to reach, and a filter running on the Mac itself refuses the connection. This is the control that reaches a browser tab, which is the one thing blocking an application cannot do.

The same page serves two purposes that are really one statement about a destination: web filtering an administrator writes by hand, and the egress rules that AI policy produces when you block an AI tool. Every rule records where it came from, so an automatically written one traces back to the decision behind it instead of looking like something somebody typed.

What a rule says

• Destinations: one or more hostnames. Each covers the host itself and everything under it, because that is what an administrator means by blocking a service rather than one of its pages.
• Deny or allow: deny refuses the connection. Allow is an exception, and it wins over any deny.
• Applications, optionally: a rule can be limited to particular applications instead of applying to everything on the device.
• Which Macs: every Mac, or specific device groups, scoped exactly the way blocked applications are.

Allow winning over deny is what makes the useful policy expressible. "Nothing may reach this AI provider except the two tools we approved" is one deny plus two allow exceptions, rather than an entry for every application in your fleet that is not one of the two.

Where this works

macOS, through a network filter that ships inside the Xavier agent as a system extension. Like the blocking extension it has to be approved before it can do anything, and Xavier deploys the profile that approves it. On a supervised or automatically enrolled Mac that is silent; on a Mac somebody enrolled themselves, they have to allow it once in System Settings. The console reports how many Macs in a rule's scope are actually filtering, so a rule is never assumed to be in force where it is not. Rules can be written for a fleet that includes other platforms, and they simply do nothing there today.

Limiting a rule to particular applications is a macOS capability rather than a universal one: a Mac can attribute a connection to the application that made it, and most platforms cannot. That is why the application scope is optional, and a rule without one is complete rather than unfinished.

Destinations no rule may block

Some destinations are refused whatever a rule says: Apple's device management, push, activation and software update services, the addresses used to check whether a certificate is still valid, and Xavier itself. A rule denying the whole internet is refused for the same reason.

This is not a matter of taste. A fleet that cannot reach its own management service cannot be told to stop blocking its own management service, and the only remaining fix is to visit every machine in person. The filter on the device carries its own copy of that list and enforces it independently, so a rule that arrived through a bug is still refused at the point it would take effect.

No rules means nothing is filtered

An empty rule set allows everything. Unconfigured never means deny, and every path through this feature fails towards allowing, including a policy that cannot be read or delivered. Getting that backwards here does not produce a wrong number on a report, it takes a fleet off the network remotely, so writing a rule is the only thing that ever blocks anything.

Because a mistake reaches further than one stopped application, only administrators can write these rules, and every change is recorded in the activity log with the person who made it.

Removable storage

What happens when somebody plugs a USB drive into a managed Mac or Windows PC. One rule covers both platforms, with the same modes, the same device group scoping, and the same list of approved drives, so you express an intention once rather than learning two products.

Start by watching, not blocking

A rule is in one of two modes:

• Audit: nothing is blocked. Every drive that is plugged in is recorded, with the machine it appeared on and how often.
• Block: drives do not mount at all. The strictest option, and the one that generates the most tickets.

Audit is the underrated one and the right place to start. It is the only mode that cannot break somebody's day, and it is what produces the drive inventory an approved list needs. Writing the approved list first is the classic mistake: a rule that breaks the finance team's backup drive on its first morning gets the whole feature switched off by lunchtime.

When more than one rule covers a device, the strictest one wins, and approved drives are shared across them, so a drive you have approved stays usable.

Approving the drives people actually need

The allowlist is not a third mode: it is a set of exemptions that applies to whichever mode is in force. You approve a drive from the inventory of ones your fleet has really used, so an approval refers to a drive that exists rather than to a vendor and model somebody typed from memory. An entry with no serial number matches every drive of that make, which is a deliberately blunter option rather than an accident.

A drive is recognised by the serial number it reports about itself, and that is a claim, not a proof. It is not tamper-evident and it can be copied, so treat an approved list as a guard against carelessness rather than against somebody deliberately working around it. Every screen that shows a serial says so.

The platforms differ, and the difference matters

Enforcement is done by the Xavier agent on both platforms, so a machine without the agent is unaffected. What the agent can do is not the same on each:

• macOS: the Mac asks whether the volume may mount, and Xavier can refuse. A blocked drive never appears at all.
• Windows: nothing gets to answer that question. The drive is enumerated and mounted first, and the agent switches the device off immediately afterwards, so there is a brief moment in which a blocked drive is present and readable. Treat Windows blocking as a strong deterrent rather than an airtight one.

If that moment is unacceptable, Windows has an alternative that does not involve the agent: a Windows configuration profile can deny removable storage at the class level, before anything is enumerated, with no interval at all. It gives up the reporting and the drive inventory in exchange, which is the whole trade.

What people see

By default the person at the device is told when a drive is refused, and that default is deliberate. A drive that silently fails to appear reads as broken hardware, so people escalate dead USB sticks rather than asking about policy, and you pay for the block twice.

What this does not do

• It does not stop a phone. A connected iPhone or Android handset is a media-transfer device rather than a mounted volume, so it never raises the event any of this depends on.
• It does not stop data leaving over the network. That is what the network filter is for.
• It never touches an internal disk, the startup volume, a system volume, a Time Machine volume, or a network share. That list lives on the device as well as in the service, so it holds even for a policy that arrived through a bug.
• There is no read-only mode. It was built, tested on real hardware, and withdrawn: macOS refuses to remount an already-mounted APFS volume as read-only, which is how Mac-formatted drives are normally formatted, and a control that reports a restriction it did not apply is worse than no control at all. Rules created before it was withdrawn are delivered as audit.

No rules means nothing happens

Until you write a rule, nothing is recorded and nothing is blocked. Missing, unreadable or undelivered policy enforces nothing and an unrecognised drive is allowed and logged, because a fleet that will not mount its own disks cannot be fixed remotely.

AI enforcement

AI inventory answers what is running and whether you allow it. This is what Xavier does about it. Enforcement is off until you switch it on: discovering a tool never removes or restricts it.

Five mechanisms, and they are not the same thing

Xavier does all five of these, and they differ in what they stop, how visible they are to the person using the Mac, and what each one needs in place first. We name them separately because calling all of it "blocking" would be the easiest thing to say and the least accurate.

• Stop the application : the application does not launch. The Mac refuses to start it, so it never runs rather than being closed after it appears. Requires the Xavier security extension to be installed and approved on that Mac. A Mac without it is a Mac where nothing is blocked, and Xavier reports which Macs those are rather than assuming the rule took effect everywhere.
• Deny the destination : the tool cannot reach the service behind it, browser tab included. This is the only mechanism that covers a web version, a native app calling a provider directly, or somebody who simply opens the site in Safari. Requires the Xavier network filter to be approved on that Mac. It is reported separately from the security extension, because a Mac can have one and not the other.
• Remediate : one specific, named change is made: an AI connector removed from a configuration file, a tool uninstalled, a tool pinned back to an approved version. Requires the Xavier agent on that Mac. There is no general "run anything" capability here; the list of possible changes is fixed.
• Configure : an approved app keeps working, but within limits you set: which AI providers it may use, whether secret scanning stays on, which connectors it may reach. Nothing is stopped; the tool behaves differently. Delivered as a configuration profile over device management, so it requires the Mac to be enrolled. It does not need the Xavier agent.
• Pin : the fleet may run one verified build of a tool and no other. Each new release is checked against its expected content and waits in testing for a person to approve it, rather than rolling out on its own. Requires software distribution to be set up for your organization.

Neither of the first two covers the other, which is why blocking a tool uses both wherever both apply. Stopping the application cannot see a browser tab; denying the destination cannot stop a tool that has not made a network call yet. Xavier writes rules for both and reports which ones actually took effect.

There is no AI-specific blocking engine underneath any of this. Blocking a tool writes ordinary blocked application and network filter rules, visible and editable on those pages like any other, and marked with the decision that produced them. A parallel AI-only path would mean two sources of truth for why something stopped working, and two things to debug at five o'clock.

Browser extensions are the exception worth stating on its own. An AI browser extension never starts as its own application, so blocking cannot see it. Xavier controls those through the browser's own management settings instead, by extension identity. This is currently supported for Chrome.

Blocking a provider, rather than a tool

A tool's own website and a provider's API are deliberately different statements. Blocking a chat tool blocks its web version, because that is the same tool in another form. Denying a provider's API is a much larger claim: the same endpoint is reached by that vendor's app, by an engineer's own script, and by any number of tools you have approved, so it is a decision you make deliberately rather than one you inherit.

Anthropic, OpenAI, Google, Perplexity, Mistral, Cohere, Groq, and GitHub Copilot are recognised with their API endpoints already filled in. Because an allow exception beats a deny, "nothing may reach this provider except the tools we approved" is one deny plus an exception for each approved tool, instead of a rule for every application you did not mean to stop.

Nothing here ever touches local inference. There are no loopback addresses and no local model ports in any of it, and there never will be. A model running on the machine sends nothing anywhere, which is the outcome this whole feature is trying to encourage, so a rule that interfered with it would be working against the point.

Blocking records a decision; enforcing it is a second choice

Marking a tool as blocked in the catalog records the policy and raises a violation. Whether that also writes and pushes enforcement rules the moment you save is a separate setting, and it is off until you turn it on. An edit on a policy page that silently stops software across an entire fleet is not something anyone should discover by accident.

The approved AI catalog

Every decision lives in one place: a catalog of the AI tools, connector packages and model sources your organization has considered. Each entry records who owns it, why it was allowed or refused, when the approval runs out, and every decision ever made about it. That history is the record an auditor asks for, and it is the reason this belongs to your security team rather than being scattered through settings screens.

Approving happens where the discovery is. Someone who has just been shown what is actually on the fleet is in the right position to say which of it is fine, so every unapproved item in the AI report offers Approve and Deny in place. Refusing is a decision in its own right, recorded like any other, not merely the absence of an approval.

Anyone in the console can ask for a tool, and those requests queue for a decision. The person who wants a tool is the person who knows why they want it, and an allowlist only a handful of administrators can add to is an allowlist that stays empty.

An approval can be given an expiry date. When it passes, the tool stops counting as approved on its own and you are told, without anyone having to remember to review it.

Making a change on a Mac

A remediation makes exactly one named change and nothing else. Editing someone's configuration file is treated as the delicate operation it is: if the file cannot be read cleanly, Xavier refuses rather than rewriting it, everything it did not come to change is preserved exactly, the file is written in one piece, and a copy of the original is kept beside it so the person can get their setup back themselves.

A Mac that is closed or offline is not skipped. The change waits and is applied when the machine comes back, and expires unapplied if it has been waiting long enough that the policy behind it may have moved on. Every change is recorded in one place, along with who started it.

Knowing whether any of it is working

Xavier reports how many of the tools you have blocked in your AI policy are still not actually stopped on each Mac: not prevented from launching, not pinned, not constrained by a profile. That number is the difference between a policy that exists and a policy that is in force, and it shows at a glance whether enforcement is doing its job on your fleet.

You are alerted about the things worth interrupting someone for: a tool that started being blocked, a change that failed, an approval that ran out. Approving something clears its findings quietly, because nobody needs twenty messages telling them that what they just approved is now approved. Everything is written to the activity log either way, which is what answers the question three weeks later about why an app stopped opening on someone's Mac.

What the risk score measures

Reaching an outside AI provider is what exposes your data, so that is what weighs most: an unapproved tool sending content to a third party outranks anything sitting on a disk. Running models locally is not penalised. A Mac doing its own inference sends nothing anywhere, and a score that treated stored model files as the danger would have marked your safest machines as your worst ones. Model files are still checked for where they came from, as a supply-chain question, and their disk usage is reported as a cost rather than a security finding.

Available on macOS. Windows and Android devices do not report AI inventory and are not covered by these controls.

Security model

Xavier's security is built in layers: every device proves its identity cryptographically, every kind of credential is limited to exactly what it needs, secrets are encrypted at rest, and everything that happens is recorded. Here is what that means in practice.

Every device proves who it is

• Xavier's built-in certificate authority issues each device its own identity certificate during enrollment. Enrollment challenges are single-use, so one can never be intercepted and replayed.
• Device requests are verified against those certificates, on Apple and Windows alike, including revocation checks.
• You can revoke or reissue any device's certificate from its detail page. Revoking cuts that device off immediately.
• Expirations are scanned daily and raised as alerts long before anything breaks, and a fleet-wide verification report shows the state of every certificate.

Credentials can only do their own job

Three distinct kinds of credential exist, and each works only on its own surface:

A credential presented in the wrong place is simply rejected, and the rejection reveals nothing about what kind of credential it was. Every credential is also bound to your tenant; see Tenant isolation.

Access control for your team

• Roles keep duties separate: administrators have full control, auditors can see everything (including reports and the audit log) but change nothing.
• Sessions are secure browser sessions with a limited lifetime; passwords are stored only as strong one-way hashes.
• Sign-in attempts, API calls, AI queries, and even device check-ins are all rate-limited to blunt abuse.

Secrets stay secret

• FileVault recovery keys, storage credentials, and integration credentials are encrypted at rest with AES-256-GCM.
• Saved credentials are never displayed again after you enter them; they can be replaced, but not read back.
• Revealing a recovery key requires an authenticated admin request and is recorded in the audit log. See FileVault key escrow.

Devices are hardened too

• On Macs, privileged work goes through a separate helper that only accepts requests from the genuine, signature-verified Xavier agent.
• On Android, the agent's identity is pinned into the enrollment QR code, so a tampered agent cannot enroll, and its local data is hardware-encrypted.
• On Windows, an installer is verified against its checksum before it runs and against the installed-programs list afterwards, so neither a substituted download nor an installer that silently did nothing is reported as a success. The channel the tray app uses to talk to the service accepts three fixed requests that carry no arguments, so nothing a local user sends can become a path, a package name, or a command line.

Everything is on the record

Every command, script run, key reveal, and AI query lands in the activity log with who did it, when, and what came back. Auditors can review all of it without being able to change anything.

FileVault key escrow

Xavier turns on FileVault across your Macs and escrows each personal recovery key, encrypted, so a locked-out user is a console lookup instead of a lost machine.

How escrow works

• Xavier deploys the built-in FileVault profile, which includes a per-device escrow certificate.
• When FileVault enables (immediately, or deferred to the next login), macOS encrypts the personal recovery key to that certificate and returns it.
• Xavier decrypts the envelope, then re-encrypts the key with AES-256-GCM for storage. Keys are decrypted again only on an authenticated reveal request.

Day-to-day operations

• Reveal: an admin can view a device's recovery key from its detail page; the access is recorded in the audit log.
• Rotate: rotate the recovery key after any reveal, so a key that has been seen is retired.
• Monitor: FileVault status is part of security posture and compliance, so unencrypted Macs surface immediately.

Storage and file delivery

Everything you upload (installers, packages, signage media, collected diagnostics) lives in a storage account you own and control, not in Xavier's. This page covers how that connection is made and, more importantly, how a file gets from your bucket onto a device without your bucket ever being open to anyone.

Connecting your storage

• Connect any S3-compatible service or Google Cloud Storage under Settings. This is required before you can upload packages, apps, or media; App Store, VPP, and Managed Google Play deployments need no storage connection, because nothing of yours is being hosted.
• Credentials are encrypted at rest with AES-256-GCM and are never shown again after saving. You can replace them; you cannot read them back, and neither can anyone else with console access.
• The connection is tested before it is saved, so a bad credential fails at the point you enter it rather than the first time a device tries to install something.

Your bucket is never public

This is worth being explicit about, because the usual way to distribute software is the thing Xavier deliberately does not do. Nothing Xavier uploads is ever made publicly readable, and no part of the product asks you to relax your bucket permissions to get started. Your files stay private objects, and a device reaches one only by proving to Xavier who it is first.

There are two ways that plays out, and neither exposes the bucket:

• Xavier streams the file itself. The device authenticates to Xavier on every request, and Xavier proxies the bytes out of your storage. Signage media works this way: the display asks Xavier, Xavier checks the credential, and the content is streamed through. The screen never holds a storage credential and never talks to your bucket at all.
• Xavier mints a short-lived link. When an app deployment is dispatched, Xavier generates a signed URL valid for a limited window and for that one object only. It is created at the moment the command is sent rather than stored against the app, so there is no long-lived link sitting in a database waiting to leak.

An expired link grants nothing, and a device with no valid credential is refused rather than falling back to an open read. The practical consequence is that putting a build into Xavier does not put it on the public internet, and somebody who learns the name of your bucket learns nothing they can fetch.

What a device is trusted with

No device ever holds your storage credentials. A device authenticates to Xavier with a credential valid only for its own reporting, and Xavier is the only party that talks to your storage account. That keeps the blast radius of a compromised or stolen device to what that one device could already do, rather than to everything in your bucket. How those credentials are scoped is covered in the security model.

Compliance engine

The compliance engine evaluates every device against a set of rules, each with a severity (critical, high, medium, low), a category, and platform scoping. Results roll up into fleet statistics and drive notifications.

Built-in rules

Each category has its own page explaining where every rule gets its data and exactly what counts as a pass.

Rules can be adjusted, scoped to device types, or disabled; evaluation runs fleet-wide or against a single device on demand.

How a result is decided

• Every rule checks one fact that a device reports about itself.
• A device is compliant when it passes every enabled rule for its platform. A single failed rule makes it non-compliant, whatever that rule's severity.
• Severity sets how a violation is ranked and how loudly it is announced. You can change any rule's severity, and switch any rule on or off.
• Each rule applies only to the platforms it names. A Mac rule never affects an iPhone.
• Results are worked out from the most recent data each device has reported, every time you open a compliance view. An hourly check also sends a notification when a device falls out of compliance.
• Rules marked "off by default" ship switched off, usually because they depend on a policy of your own. Turn them on from the Compliance page.

From finding to fix

• Non-compliance raises a notification (configurable per event type).
• Outdated packages, projects and runtimes can be fixed from the console, which pushes the update to the device.
• The compliance report tracks pass rates over the fleet, so drift is visible as a trend, not just an incident.

Mac security checks

The Xavier agent runs in the signed-in user's session and reports to Xavier every five minutes. It re-reads these security settings on the same five-minute cycle, using the same built-in commands an administrator would run in Terminal.

Mac package checks

Package checks run every ten minutes, as the signed-in user, against the package managers that user actually has. A Mac that does not have a given package manager passes its rule. Project dependencies are covered separately, in project and runtime checks.

Apple device checks

These values come straight from Apple's device management protocol, so they need no agent. Xavier asks each device shortly after enrollment and then about once an hour, or every six hours for devices using Declarative Device Management. A value changes only when the device answers, so a device that is switched off keeps its last known state.

Windows checks

Windows reports its security state through the Microsoft device management settings built into every edition, so these checks need no agent. Xavier collects them at enrollment and each time inventory is refreshed from the device page.

On PCs running the Xavier agent, three more rules check developer packages. The agent refreshes each list every six hours, and a PC without a given package manager passes its rule.

Android checks

The Xavier agent on each Android device reads these values from Android's own device policy and lock screen services. It reports right after enrollment, then every hour, and whenever you refresh inventory from the device page.

Project and runtime checks

The agent looks for software projects in each user's home folder, down to ten folders deep and up to 500 projects. It skips system and media folders, hidden folders, and folders that hold downloaded dependencies or build output, such as node_modules. It reads each project's manifest as plain text and never runs a build tool.

• Mac: package.json, pom.xml, build.gradle and build.gradle.kts. A full scan runs every six hours.
• Windows: those, plus requirements.txt, pyproject.toml, go.mod, and .NET project files. A full scan runs every six hours, and changes to project files are picked up as they happen.

The dependencies each project declares directly are checked, development dependencies included. Xavier works out the results whenever a device sends new project data.

For runtimes, the agent finds every installed copy of each language, including copies installed by version managers such as nvm, pyenv, rbenv, asdf and Homebrew, not only the one on the path. It reports them every hour on Macs and every six hours on Windows. Xavier then looks up each version's release line on endoflife.date.

AI governance checks

These rules use what AI inventory finds, so they start working once AI inventory is enabled in Settings. The agent takes a fresh inventory every six hours, as soon as collection is switched on, and whenever you ask for a rescan. Rules that read inside configuration files also need the separate setting that allows reading their contents.

macOS agent

The Xavier agent is a native menu bar app that complements MDM on the Mac. MDM handles profiles, restrictions, and commands; the agent adds what the protocol cannot see: live package inventory, developer tooling, project scanning, and script execution, over an always-on connection to the console.

What the agent does

• Reports inventory, security state, installed applications, and packages in real time.
• Executes package operations for Homebrew, npm, pip, and RubyGems; see Package management.
• Discovers npm projects and language runtimes for vulnerability scanning.
• Runs scripts and installs managed Mac apps.
• Reports location when the location profile is deployed.
• Enforces blocked applications, destination rules, and removable storage policy on the Mac itself.

The system extensions

Two of the agent's jobs need permissions macOS grants to system extensions rather than to ordinary apps, and they are separate extensions on purpose:

• Endpoint protection: refuses a blocked application's launch, and refuses a blocked drive's mount.
• Network filter: refuses connections to destinations a rule denies.

Splitting them means a failure in one cannot take out the other. Both have to be approved before they can do anything, and Xavier deploys the profiles that approve them, so there is no payload for you to assemble. On a supervised or automatically enrolled Mac this is silent; on a Mac somebody enrolled themselves, they allow each one once in System Settings. The console reports which Macs have each extension running, separately, rather than averaging two independent controls into one status.

Deployment

• Deploy the built-in agent configuration profile (it already points at your tenant) and the built-in permissions profiles, so the agent never has to ask the user for access.
• Install the agent, from the device page or your app deployment channel.
• The agent connects with a credential that is valid only for that device's own reporting, and shows up as a live connection on the device page.

The agent keeps itself current with automatic in-place updates as new versions are released.

The Root Helper

By design the agent runs without administrator rights, which means it cannot install software or touch anything privileged on its own. The Root Helper is a separate root service that does that work on the agent's behalf. It is off by default, and until you turn it on the agent's privileged features are unavailable, so most fleets will want it enabled.

What it unlocks

• Silent installs of managed Mac apps: .pkg and .dmg alike; see app distribution. Macs without the helper are not selectable as deployment targets.
• Munki client setup and auto-deployment, which the console will not let you enable until the helper is on.
• Scripts marked run as root. Running one against a Mac that has no helper is refused rather than silently downgraded.
• Unattended installation of developer tooling such as Homebrew; see package management.

Enabling it

• Go to Settings → Apple → macOS Root Helper and turn it on.
• Choose the scope: every Mac, or only selected device groups if you would rather pilot it first.
• Xavier pushes the signed, notarized helper package over MDM, silently and as root. Targeted Macs pick it up on their next check-in; nobody is prompted and no one has to visit each machine.

The settings page counts the Macs in scope, how many have the helper installed, and how many are still pending, and each count opens the list of devices behind it. From then on the helper keeps itself current: when a newer version ships, Xavier re-pushes it to any Mac running an older one. Turning the toggle back off stops new installs and leaves the privileged features unavailable again.

Why it is safe to run

The helper exposes exactly four operations (install a package, install a disk image, run a script under a named interpreter, and report its own version) and nothing else. Every request arriving at it is checked against a code-signing requirement, so only the genuine Xavier agent, signed by our team and anchored to Apple, can drive it; anything else is refused. The agent pins the helper's signature in the same way, so neither side will talk to a substitute.

Windows agent

The Windows agent holds an always-on connection between a PC and the console. Windows MDM handles profiles, policy, and commands; the agent adds what the protocol cannot see or cannot do: live software inventory, developer tooling and runtimes, project scanning, script execution, and silent installs of the installers MDM will not take. It is a Windows service, with a small tray app for the person using the machine.

What the agent does

• Reports device facts (name, OS version, model, processor, memory, storage, local accounts) on a five-minute check-in, with a heartbeat in between so the console knows the device is live.
• Reports installed applications from Add/Remove Programs, winget, and Chocolatey, merged into one list and re-sent whenever it actually changes.
• Reports packages from npm, pip, RubyGems, Go, and .NET global tools; see package management.
• Discovers language runtimes and project dependencies for vulnerability scanning.
• Runs scripts and installs managed Windows apps, including the ones MDM cannot deploy on its own.
• Manages Chocolatey: bootstraps it if missing, registers your Xavier feed as a source, and keeps the assigned package set applied.

Installing apps MDM cannot

Windows enterprise app management takes MSI packages and nothing else, which leaves out most of what a real fleet actually installs. The agent covers the gap: it installs MSI and EXE alike, silently, using the right switches for whichever toolkit built the installer, or an override you supply.

• Verified before it runs: the download must match the SHA-256 you supplied or it is not executed, and an app can be marked as requiring a valid signature.
• Verified after it runs: an exit code is not evidence. Silent installers do fail while reporting success, so a successful exit is checked against Add/Remove Programs before Xavier believes it. Nothing installed means the deploy is reported as failed, not completed.
• Reported in full: exit code, output, duration, and whether a reboot is pending all land on the device's log, so you can see what the installer actually did.

Privileges

The agent normally runs as a system service, so privileged work (installs, Chocolatey, elevated scripts) happens directly. There is no separate helper component to deploy or enable, and nothing for anyone to approve on the device. If you deploy the agent in a constrained mode instead, it still connects and reports everything; only the install and Chocolatey operations are refused, each with a stated reason the console shows. Inventory never depends on elevation.

The tray app

A tray icon shows the person at the keyboard what is happening on their machine: connection status, last sync, a warning when Xavier has flagged vulnerabilities on the device, and tabs for the device, its runtimes, and its packages. The menu offers Sync Now and Check for Updates and nothing that could change policy; the tray only displays what the service already knows, and closing it affects nothing but the window.

Deployment

• Deploy the built-in Xavier Agent Configuration Windows profile. It already points at your tenant, and each device is stamped with its own credential at deploy time.
• Xavier pushes the agent installer to enrolled devices over MDM. Nobody is prompted and nobody has to visit each machine.
• The agent connects with a credential valid only for that device's own reporting, and appears as a live connection on the device page.

Updates arrive the same way. Every device reports the agent version it is running, and any device behind the released version is re-pushed the current installer on its next check-in, so the fleet converges without you tracking who is on what.

Digital signage

Megaphone turns managed devices into signage displays: iPads, Apple TVs, Macs, and Android tablets show the content you send, from the same console that manages everything else. A signage device is simply an enrolled device running the Megaphone app.

Setting up a screen

• Deploy Megaphone to the device through app distribution; Xavier hosts the builds and keeps them updated.
• On managed devices, Megaphone pairs itself automatically using injected managed configuration; a six-character pairing code covers manual setup.
• The device appears in the signage dashboard, linked to its MDM record (duplicates are prevented by matching on the device identity).

Content

• A media library holds uploaded images and videos, with generated thumbnails.
• Send content to a single screen or a group of screens, and clear it just as easily.
• An idle screen defines what displays show when nothing is scheduled.
• Per-device content history and a signage activity feed track what showed where, when.

MCP server

Xavier exposes a Model Context Protocol (MCP) server so AI assistants (Claude Desktop, VoxyAI, Cursor, or any MCP client) can query your fleet in natural language: "Any Windows laptops with BitLocker off?", "Which Macs have outdated Homebrew packages?", "Which devices haven't checked in for two weeks?", "How healthy is my fleet?".

What the AI can use

• Tools: two dozen query tools across inventory, compliance, software, configuration, AI posture, and audit.
• Resources: xavier:// resources for fleet summaries and reference data.
• Prompts: ready-made workflows for investigating a device and running a compliance audit.

Connecting a client

• Create an MCP token in Settings, then MCP tokens. Each token is named, revocable, and tenant-bound.
• Point your MCP client at https://app.<domain>/mcp (Streamable HTTP) with the token as a bearer credential.
• Ask questions. Every query is rate-limited per token and lands in the activity log attributed to the token and client.

Safety properties

• MCP tokens are a distinct credential class, valid only at the MCP endpoint; they cannot call the admin API. See the Security model.
• Responses pass through a redaction layer that strips recovery keys, bootstrap and unlock tokens, push credentials, Wi-Fi passwords, and SCEP challenges; tests sweep every projection for forbidden fields.
• Revoking a token cuts access immediately.

Tenant isolation

Xavier is a hosted service, and your organization's slice of it is a tenant. Isolation between tenants is structural, not just a permission check.

What you get

• Your own console address: your team signs in at your organization's own subdomain.
• Your own database: your devices, inventory, keys, and history live in a database that belongs to your tenant alone, not in shared tables.
• Tenant-bound credentials: every session, device credential, and AI token is tied to your tenant. Presented anywhere else, it is rejected.
• Your own enrollment identity: Windows enrollment credentials and device enrollment are per-tenant, and rotatable by you.
• Your storage: packages and media are distributed from your own storage account, any S3-compatible service or Google Cloud Storage, connected in Settings. Your files stay in an account you own and control.

A curated software library, included

Common Mac apps are packaged, tested, and published centrally by the Xavier team, and appear in your Munki catalog ready to import, so you get a maintained app library without doing the packaging yourself.

API reference

Everything the console does goes through a documented REST API, described by an OpenAPI 3.1 specification covering around 400 paths and 500 operations. Your deployment serves its own interactive reference.

Interactive docs

• https://app.<domain>/api/docs: browsable API reference (admin sign-in required).
• /api/openapi.json and /api/openapi.yaml: the raw specification for codegen and tooling.

Authentication

Browsers use the httpOnly session cookie set at login. Scripts and CLIs use a bearer token:

> curl -s https://app.example.com/api/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email": "you@example.com", "password": "..."}'
# response includes a JWT

> curl -s https://app.example.com/api/devices \
  -H 'Authorization: Bearer YOUR_TOKEN'

Surface at a glance