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: agentless enrollment and management, with a visual policy builder for password rules, BitLocker, Defender, firewall, and Windows Update rings.
• 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

Windows enrollment is agentless: devices enroll through the same built-in Windows management channel that Microsoft's own tools use, so there is no software to install and nothing extra running on the PC. Enrollment issues the device its own certificate, and management happens through Windows itself.

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; Macs with the agent installed 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. 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.
• 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, and Munki source events. Each event type can be shown as a bell notification, a toast, or muted, per user.

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 pilot ring, the conference room Apple TVs, executive laptops.

Smart groups

Smart groups define membership by rule, starting from a platform (Mac, iPhone, iPad, Apple TV, Android phone or tablet, Windows) plus conditions. Membership is materialized and re-evaluated whenever a device is saved, so a Mac that upgrades its OS or falls out of compliance moves between groups on its own.

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.

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.

macOS agent commands

Macs with the agent accept software commands over the agent's live connection: install, update, and remove packages across Homebrew, npm, pip, and RubyGems, manage Homebrew taps, install managed Mac apps, run scripts, and force an inventory sync. See Package management and Scripts.

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

• 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 or .dmg 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. For ongoing third-party app patching at scale, use Munki.

Windows

Upload MSI installers to the Windows app library; Xavier reads the MSI metadata and deploys through the native enterprise app management channel, with removal supported the same way.

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. Credentials are encrypted and never shown again after saving, connections are tested before use, and if you switch storage later, Xavier migrates your existing files for you.

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 manages the developer package ecosystems on every Mac in the fleet: Homebrew, npm, Python pip, and Ruby Gems. The macOS agent reports what is installed in real time, and the console can search, install, update, and remove packages remotely.

Per-device catalogs

Each Mac's 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

• 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.

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.

Language runtime governance

The agent inventories installed runtimes for Java, Go, Python, Ruby, and Node, and Xavier evaluates each against:

• Known CVEs, matched against advisory data.
• 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, and remediation (updating the runtime) can be pushed from the console.

npm project scanning

The agent discovers npm projects on disk and Xavier annotates their dependency trees:

• 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.

Vulnerability and currency findings can back compliance rules, so a Mac carrying a vulnerable dependency tree shows up as non-compliant, with the fix one click away.

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, including whether one is configured to act without asking first.
• 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.

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. Three are on from the start because they need no policy of your own: MCP server packages with known advisories, credentials sitting in AI tool configuration, and coding agents configured to run commands without asking. The rest wait until you have written a policy for them to measure against.

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 any Mac in the fleet, from a proper editor, with history.

Writing scripts

• Interpreters: bash, sh, zsh, python3, ruby, perl, and 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.

Root execution

By default scripts run as the agent user, without elevation. 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.

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: Windows is waiting on agent support, 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, an assistant's unattended mode switched off, a tool uninstalled, a tool pinned back to an approved version. Triggered by a person, or by a rule. 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 rule can be set to make a change without waiting for anyone, and this is off for every rule until you turn it on. It is only offered where the change cannot destroy work in progress: removing a connector entry or switching off an unattended mode is safe to do unnoticed, uninstalling a tool somebody is in the middle of using is not, so that one stays a deliberate human action.

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. Whether a person or a rule started it, the record is the same and sits in one place, differing only in who or what began it.

Knowing whether any of it is working

Xavier reports how many unapproved tools on each Mac are under no control at all: not blocked, 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 is the honest answer to whether enforcement is doing anything on your fleet.

You are alerted about the things worth interrupting someone for: a tool that started being blocked, a change a rule made without a person, 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.

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.

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, drive notifications, and connect directly to remediation.

Built-in rules

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

From finding to fix

• Non-compliance raises a notification (configurable per event type).
• Package and runtime findings carry a remediation action: push the update straight from the result.
• The compliance report tracks pass rates over the fleet, so drift is visible as a trend, not just an incident.

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.

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: fifteen query tools across inventory, compliance, software, configuration, 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 with roughly 230 endpoints. 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