Introduction

Xavier is a cross-platform device management service. One console enrolls, configures, secures, and monitors Macs, iPhones, iPads, Apple TVs, Windows PCs, and Android devices, using each platform's native management channel.

What Xavier manages

• Apple: Mac, iPhone, iPad, and Apple TV, including Automated Device Enrollment, supervision, profiles, and volume app licensing.
• Windows: enrollment with nothing to install, a policy builder, and an optional agent for software inventory and installs.
• Android: full device control with no Google account required, and optional Samsung Knox enrollment. Managed Google Play is coming soon.
• Software: App Store and volume-purchased apps, custom packages, Munki, developer package managers, patching, and vulnerability scanning.
• Control: which applications, websites, AI tools, and USB drives are allowed, enforced on the device.

The pieces

Your tenant

Each customer gets a dedicated console address, an isolated database, and tenant-only credentials. See Tenant isolation.

Next: Getting started.

Getting started

When your organization is set up, you receive an email invitation to your console address.

1. Sign in and secure your account

• Open the invitation and choose a password. As the account holder, you keep this password even after single sign-on is turned on, so a problem with your identity provider can never lock you out.
• To have your team sign in with your company accounts, connect your identity provider and turn on console sign-in; see Console sign-in and SSO.
• Invite your team under Users; each person gets an email invitation. Roles are described in the Security model.

2. Connect your Apple push certificate

Apple devices cannot enroll without it. Set it up in Settings, then Certificates; see Apple certificates.

3. Connect optional integrations

• Apple Business Manager: Automated Device Enrollment for zero-touch, supervised devices, and a VPP token for volume-purchased apps.
• Samsung Knox: zero-touch enrollment for Samsung devices.
• Managed Google Play: coming soon.
• Storage: your own S3-compatible or Google Cloud Storage account, for uploads; see Storage and file delivery.
• Munki: a Xavier-managed Mac software repository in your storage, or one you already run.

4. Enroll your first device

• Apple enrollment: an enrollment profile, 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 self-maintaining smart groups.
• Build and assign Apple profiles and Windows profiles.
• Review and adjust the compliance rules.

Apple certificates

Apple requires each organization to hold its own push certificate so Xavier can reach your Apple devices. Setup is a one-time flow of a few minutes.

Setting up the push certificate

• In the console, open Settings, then Certificates and generate a push certificate request. Xavier signs it and gives you a file for 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 on the same settings page.

The certificate's status and expiration date are shown under Settings, and Xavier warns you well before it expires.

Device identity certificates

Per-device identity certificates need no setup; Xavier issues them automatically at enrollment. See the Security model.

Settings reference

Where each tenant setting lives in the console.

Apple enrollment

Apple devices enroll with 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, supervised).

Profile-based (OTA) enrollment

• On the device to enroll, open the console at Settings, then Apple, then Apple Enrollment, and download the enrollment profile (.mobileconfig).
• Open the profile and approve it in Settings (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.

Some enrollments wait for administrator approval first. See Enrollment approval.

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 with 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: Setup Assistant panes to skip, supervision, other setup options, and optionally Sign-in during setup.
• Assign profiles to devices. New devices get the default profile automatically. Devices can also be released back to Apple Business Manager.

An assigned device that powers on or is erased goes through Setup Assistant into a supervised, enrolled state, with profiles, restrictions, and apps installed before the user reaches the desktop or home screen. Devices that fail ADE verification wait for approval.

What happens at enrollment

• The built-in certificate authority issues the device an identity certificate.
• 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 also deploy the macOS agent for package management and scripts.

Enrollment approval

An Apple device (Mac, iPhone, iPad, or Apple TV) that enrolls through an untrusted path is held until an administrator approves it. It installs the enrollment profile but gets no configuration profiles, certificates, Wi-Fi or VPN settings, apps, or declarations, and is not on the device list.

Enrollments that skip approval

Everything else waits: the plain enrollment link, a shared profile file, a profile downloaded by a non-administrator, and an Automated Device Enrollment whose signature cannot be verified.

While a device waits

• It appears on the Pending Approval page, not the device list, and does not count toward billing.
• Xavier collects basic inventory only: name, model, operating system, serial number, and security information.
• Every administrator gets a "Device waiting for approval" alert on every channel you have set up (console, email, Slack, Microsoft Teams, Google Chat, or webhook), linking to the Pending Approval page.
• An unverified Automated Device Enrollment stays in Setup Assistant until approved.

Approving and rejecting

While devices are waiting, Pending Approval appears in the sidebar below Devices with a count. Select devices, then choose Approve or Reject. Only administrators can decide; auditors can view.

• Approve: the device joins the device list and, at its next check-in, receives every profile, app, declaration, and group assignment that applies to it.
• Reject: Xavier removes the enrollment profile, unenrolling the device, usually within seconds. That enrollment can never be approved; to retry, the device must enroll with a new profile.

Every decision is recorded in the activity log with the administrator's name.

Settings

On the Apple Enrollment page (Settings, then Apple, then Apple Enrollment):

• Reject automatically after: devices waiting longer than this many days are rejected and unenrolled. Default 7; 0 means wait indefinitely.
• Pre-approved serial numbers: paste expected serials (for example from a purchase order) with an optional note. A switch turns automatic approval on or off.
• Active enrollment links: valid administrator downloads and Apple Configurator links, who created them, and usage counts. Revoking a link sends later enrollments through approval.

Safeguards

• Each enrollment profile belongs to the first device that installs it; any other device presenting it is refused.
• The public enrollment link is rate limited per network address and per organization. Unusually heavy use blocks further requests for an hour and alerts administrators that the link may have been shared.

Identity provider

Connect the service your organization signs in with: Google Workspace, Microsoft Entra ID, Okta, or any OpenID Connect provider. One connection can do two things: ask people to sign in while setting up a device, which assigns it to them, and sign your admins in to the console. People sign in on your provider's own page; Xavier never sees their password.

Set it up under Settings, then General, then Identity Provider, by following the guide for your provider: Google Workspace, Microsoft Entra ID, Okta. For another provider, create a confidential web client with the authorization code flow, register the redirect URI shown on the page, and paste its issuer, client ID and secret.

Directory access and importing people

With read-only directory access, Xavier lists your groups to pick from, reads Google groups when people sign in, and can import people so devices are assigned to them before they ever sign in. Each guide shows how to grant it. Imports run from the People page, or every 6 hours with Import automatically.

Console sign-in and SSO

Your admins can sign in to Xavier with your identity provider instead of a Xavier password, so joining and leaving your company controls their access and your provider's multi-factor rules apply. It is set up on the Identity Provider page (Settings, then General, then Identity Provider).

Setup guides

• Google Workspace
• Microsoft Entra ID
• Okta

Other providers work too, over OpenID Connect, or SAML 2.0 for console sign-in only. A SAML app must send a persistent NameID or the email address, and an attribute named groups for roles.

Who can sign in

Each person needs a console user: invite them on the Users page, or turn on Create console users at first sign-in. A console user is linked to the provider account they first sign in with, never matched by email alone.

Roles from groups

Map your provider's groups to the admin, user and auditor roles. The highest role wins, it is set again at every sign-in, and a change ends the person's open sessions. The account holder always stays an admin.

Require single sign-on

Turns passwords off for everyone except the account holder and the admins you choose under Admins who can still use a password, so a problem with your provider never locks you out. Turn it on while signed in with single sign-on. SSO sessions last 12 hours by default; password sessions 7 days.

Ending access

Deactivating, deleting or changing the role of a console user ends their sessions at once. With directory import, someone your directory suspends loses console access too. Every sign-in is recorded in the activity log.

Set up Google Workspace

One connection for device setup and console sign-in, with console roles from your Google groups. You need a Workspace super admin.

In Google Cloud

1. At console.cloud.google.com, pick or create a project in your Workspace organization.
2. Open Google Auth Platform. If asked, name the app, add a support email and choose Internal.
3. Under Clients, choose Create client, then Web application. Add the Redirect URI from Xavier's Identity Provider page, choose Create, and copy the client ID and secret.
4. Search for Admin SDK API and choose Enable.

In Xavier

Open Settings, then General, then Identity Provider.

1. Choose Google Workspace, paste the client ID and secret, choose Save connection, then Test connection.
2. Under Allowed email domains, choose Add for your domain.
3. Under Directory access, choose Connect to Google, sign in as a Workspace admin, and choose Allow.
4. Under What it's used for, turn on Sign-in during device setup and Console sign-in. Set Console roles to From your provider's groups, map your groups to roles, and save.
5. Sign out, sign back in with the Google button, then turn on Require single sign-on under Sign-in policy.

Set up Microsoft Entra ID

One connection for device setup and console sign-in, with console roles from your Entra groups. You need an admin who can register apps and grant admin consent.

In the Entra admin center

1. Open Entra ID, then App registrations, and choose New registration. Under Supported account types, choose single tenant. Under Redirect URI, choose Web (not Single-page application), enter the Redirect URI from Xavier's Identity Provider page, and choose Register.
2. From Overview, copy the Application (client) ID and Directory (tenant) ID.
3. Under Certificates & secrets, create a client secret and copy its Value, not its Secret ID. Entra shows the Value only once.
4. Under Token configuration, choose Add groups claim and tick Security groups.
5. Under API permissions, add the Microsoft Graph application permissions User.Read.All and GroupMember.Read.All, then choose Grant admin consent. Grant consent even if you skip directory access, so nobody is asked to approve the app at sign-in.

In Xavier

Open Settings, then General, then Identity Provider.

1. Choose Microsoft Entra ID. Set the issuer to https://login.microsoftonline.com/ followed by your tenant ID and /v2.0, paste the client ID and secret, choose Save connection, then Test connection.
2. Under Allowed email domains, choose Add for your domain.
3. Under Directory access, turn on Let Xavier read your directory, save, and choose Test directory access.
4. Under What it's used for, turn on Sign-in during device setup and Console sign-in. Set Console roles to From your provider's groups, map your groups to roles, and save.
5. Sign out, sign back in with the Entra button, then turn on Require single sign-on under Sign-in policy.

Set up Okta

One connection for device setup and console sign-in, with console roles from your Okta groups. You need a Super Administrator.

In the Okta Admin Console

1. Open Applications, then Applications, and choose Create App Integration. Choose the Classic experience tab, then OIDC - OpenID Connect and Web Application.
2. Replace the sign-in redirect URI with the Redirect URI from Xavier's Identity Provider page and clear the sign-out redirect URI. If asked, choose Use Okta-generated client ID. Assign the groups who will use Xavier, and save.
3. On the app's General tab, under Client Credentials, copy the client ID and the client secret.
4. For directory access, create a second app integration: choose Create App Integration, the Classic experience tab, then API Services. Name it, choose Use Okta-generated client ID, and save.
5. On its General tab, under Client Credentials, choose Edit, then Public key / Private key. Choose Add key, Generate new key, then PEM, and copy the private key: Okta shows it only once. Choose Done, then Save. Note the KID shown under Public keys.
6. Under General Settings, choose Edit, clear Require Demonstrating Proof of Possession (DPoP) header in token requests, and save.
7. On the Okta API Scopes tab, grant okta.users.read and okta.groups.read. On the Admin Roles tab, choose Edit assignments, pick Read-only Administrator, and save.

In Xavier

Open Settings, then General, then Identity Provider.

1. Choose Okta. Set the issuer to your Okta domain, which is your Admin Console address without -admin (for example, https://example.okta.com). Paste the client ID and secret, choose Save connection, then Test connection.
2. Under Allowed email domains, choose Add for your domain.
3. Under Directory access, turn on Let Xavier read your directory, paste the API Services app's client ID, private key and KID, save, and choose Test directory access.
4. Under What it's used for, turn on Sign-in during device setup and Console sign-in. Set Console roles to From your provider's groups, map your groups to roles, and save.
5. Sign out, sign back in with the Okta button, then turn on Require single sign-on under Sign-in policy.

Sign-in during setup

An Automated Device Enrollment profile can require the person setting up a Mac, iPhone, or iPad to sign in with your identity provider before the device enrolls. The device is assigned to them, and a Mac's first account is created with their name.

Turning it on

Sign-in is turned on per profile. Connecting a provider alone asks nobody to sign in.

1. Connect your identity provider. See Identity provider.
2. Open Settings, then Apple, then Apple Business Manager, and edit each enrollment profile whose devices should ask for sign-in.
3. Turn on Require sign-in during setup and save. Await device configured is turned on with it and stays on, because the Mac's account is named while Setup Assistant is held.

Saving sends the profile to Apple. Its devices ask for sign-in the next time they run Setup Assistant; a device already in use must be erased first. The Identity Provider page shows which profiles have sign-in on.

What the person sees

1. After connecting to a network, Setup Assistant shows your provider's sign-in page, including any multi-factor prompt.
2. After sign-in, the device enrolls and receives its profiles and apps.
3. On a Mac, Create Account shows their full name and account name filled in (optionally locked). They choose their own password.

If sign-in is refused, the page says why: the device is not registered to your organization, the account is not in an allowed domain or group, no identity provider is connected, or sign-in timed out and must be restarted. Refusals are recorded in the activity log.

Which devices can sign in

Only devices that pass Automated Device Enrollment verification reach your sign-in page (see Enrollment approval). The enrollment profile earned by signing in only enrolls the device that asked for it.

Mac account setup

Once a profile requires sign-in, the Apple Business Manager page shows a Mac account setup section. It applies to every Mac that signs in during setup.

• Account name: how the name is built. For Jane Doe (jane.doe@example.com): Email name and first.last give jane.doe; First initial + last name gives jdoe. Names are lowercase, macOS-safe, and at most 31 characters. A name from your provider's account name claim takes precedence.
• Lock name and account name: the person cannot change the filled-in details. On by default.
• Create a managed admin account: a separate administrator account with a random per-Mac password, hidden from the login window by default. You choose its account name and full name.
• The person's account: administrator or standard user. Standard user requires the managed admin account, so every Mac keeps an administrator.

Xavier holds the Mac in Setup Assistant until it accepts the account details. After 15 minutes it is released anyway, the person chooses their own account name, and the device history records this.

The managed admin password

A Mac with a managed admin account shows a Managed admin account card on its device page.

• Reveal password: administrators only; every reveal is recorded in the activity log.
• Change password: sends a new random password. The old one works until the Mac accepts the change. The card shows when it last changed.

Windows enrollment

PCs enroll from the Windows Settings app through the built-in Windows management channel; nothing to install first. Each device gets its own certificate, and policy is delivered through Windows. The optional agent is deployed afterwards over that channel.

What you need

• Windows 10 or 11 (tested through Windows 11 24H2). Windows on ARM requires Windows 11 for the Xavier agent.
• 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. It shows the enrollment address and 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 enrolls.
• 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, and update status, refreshable on demand.
• Policy: assign profiles from the Windows profile builder to devices or groups; devices converge automatically.
• Commands: lock, wipe (several variants), reboot, rename, Defender scans, and more; see Remote commands.
• Diagnostics: collect a diagnostic log archive remotely and download it from the console.
• Updates: review and approve Windows Updates.

Android enrollment

Android devices are managed by the Xavier Device Owner agent, which needs no Google services. Samsung devices also support Knox Mobile Enrollment for zero-touch provisioning.

Device Owner agent (QR provisioning)

The Xavier DPC (device policy controller) becomes Device Owner during setup. It needs no Google account, Managed Google Play, or Firebase, so it works on AOSP builds and networks without Google access.

• In the console, open Android, then Enrollment and create an enrollment token. Xavier shows a provisioning QR code containing the agent download URL, its signing certificate checksum, and the token.
• Factory-reset the device (or use a new one) and tap the welcome 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

Samsung Knox Mobile Enrollment

Samsung devices bought through participating resellers enroll automatically at first boot, like Apple Automated Device Enrollment.

• Connect your Samsung Knox account 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

Each enrolled device has a detail page with its hardware, software, security posture, history, and actions. Devices report on a schedule, on check-in, and on demand; Macs and Windows PCs running the Xavier agent also 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: installed apps across the fleet, with drill-down to devices by app or version.
• OS distribution: OS versions across the fleet, with drill-down by version.
• Application usage: how much each app is used, and which installed apps nobody opens. Off by default; 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, and the result.
• Security overview: fleet-wide posture at a glance.

Notifications

Xavier notifies on enrollments, devices awaiting enrollment approval, unenrollments, non-compliance, 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 and attribute collection failures, and low volume-purchase licenses. Each console account, including auditors, chooses, per event type, a bell notification, a toast, or mute. For delivery outside the console, see the settings reference.

People and device assignment

Every device can be assigned to a person. Assignments keep a history of who has had each device.

People

Settings, then General, then People lists everyone devices can be assigned to, their device count, and last sign-in. Search by name or email; select a person to see their devices and assignment history.

• Signed in: added automatically on their first sign-in during setup. Name and email come from your identity provider and update at each sign-in.
• Imported: read from your identity provider's directory. Name and email come from your provider and update at each import and sign-in. When they sign in, it is the same person.
• Added by hand: added by an administrator or user for someone who has not signed in. If they later sign in or are imported with the same email, it is the same person.

Filter the list by how people got there and by status. Name and email can only be edited on people added by hand who are not yet linked to your identity provider. A person with no assigned devices can be deleted. Auditors have read-only access.

Importing from your identity provider

Once directory access is set up, the People page shows when the last import ran and what it changed. An administrator chooses Import to see a preview of who would be added, updated, suspended, or reactivated, then Import again to apply it.

• Only people who could sign in are imported: active accounts that pass the allowed domains and required groups on the Identity Provider page. Guest accounts in Entra ID are not imported.
• Nobody is deleted. A person your provider disables or no longer lists is suspended, and reactivated if they return. A person an administrator suspended stays suspended.
• Groups are read by name from the directory. In a directory with more than 500 groups, groups are not updated, but required groups are still checked.
• If nobody in the directory passes the sign-in rules, the import changes nothing and says so.

With Import automatically on, the import also runs every 6 hours. Each import is recorded in the activity log.

Assigning a device

On a Mac, iPhone, or iPad device page, the Assigned to card offers Assign or Change (pick or add a person) and Unassign. A badge shows how the assignment was made:

• Signed in during setup: the person signed in with your identity provider while setting up the device.
• Assigned by admin: someone chose the person in the console.

Searching the device list by a person's name or email finds their devices.

When an assignment ends

• The device is reassigned or unassigned.
• The device is erased or removed from Xavier.
• A device assigned by sign-in during setup enrolls again. Admin assignments stay in place.

Ended assignments stay in the person's history, even for removed devices. Every assignment change is recorded in the activity log.

Device groups

Groups apply policy to many devices at once. Static groups are curated by hand; smart groups compute membership from conditions and update automatically.

Static groups

Create a group and pick its devices. Use them for fixed sets such as a test group, conference room Apple TVs, or executive laptops.

Smart groups

A smart group rule can combine four kinds of condition; all must match:

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

Membership updates as devices change, such as after an OS upgrade or falling out of compliance.

Folders

File groups into folders to organize a long list. Folders are organizational only and don't affect anything that uses the group.

What groups drive

• Apple configuration profile deployment and DDM scoping.
• Windows profile assignment with desired-state reconciliation.
• 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

A device attribute is a small script you write that returns JSON. It is collected on a schedule and its values are stored on the device record. Smart groups can use attribute values as conditions, and automations can act on those groups.

Defining one

Create attributes under Scripts, on the Device Attributes tab. Each has:

• Platform and interpreter: macOS or Windows, in any interpreter that platform accepts.
• The keys it promises to emit, each 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 override inclusions.
• A timeout, so a hung script cannot hold anything open.

Why the keys are declared

• The condition builder offers a typed field list instead of a free-text box.
• A value sent as text where a number was declared is converted once, on arrival.
• A script that stops emitting a key shows an error, instead of a condition that silently stops matching.

From a value to an action

• Your script reports a fact, such as an internal tool's version, whether a required agent is running, free space on a build volume, or whether a licence file is present.
• A smart group uses a condition on that value. Devices join and leave as the value changes.
• A script automation watches the group and runs when a device enters it.

The group can also drive anything else a device group drives. Attribute values appear on the device page, and an automation can collect an attribute after it runs to verify the result.

Remote commands

Send commands from a device's detail page or the API. They travel over the platform's native channel, and results land in the device's history. A duplicate of an already-queued command type is rejected, commands a device cannot honor (like restarting an unsupervised iPhone) are refused up front, and superseded commands are cleaned up automatically.

Apple

Xavier supports about 45 Apple MDM command types. The most common:

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 these commands over its live connection, delivered in seconds without 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, install, update, and remove winget packages, set up Chocolatey and apply its package set, re-collect the installed application list, run scripts, and force an inventory sync.

See Mac package management, winget, Chocolatey, Scripts, the macOS agent, and the Windows agent.

Tracking results

The device history and activity log record who sent each command, when it reached the device, and the result. Pending commands can be cancelled before delivery.

Apple configuration profiles

The visual profile builder assembles profiles payload by payload, with defaults and inline validation, then signs and deploys them. You can also upload a raw .mobileconfig file.

Payload catalog

About forty payload types, including:

Deployment

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

Built-in profiles

Xavier seeds and maintains these profiles for your server:

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

Declarative Device Management

With Declarative Device Management (DDM), the device holds declarations, applies them itself, and reports status changes on its own. Xavier runs DDM alongside classic MDM and enables it per device.

Supported declarations

• Software update enforcement: require a specific OS version by a deadline, or track "latest" with a deferral window.
• Software update settings: automatic update behavior.
• Passcode settings: passcode requirements 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.
• Custom declarations: any Apple configuration declaration, written as JSON and sent to the platforms you choose. Xavier sends the payload as written; a device that rejects it reports why, and only that declaration fails.

Status subscriptions

DDM devices report OS version, passcode state, and declaration outcomes as they change. The device page shows reported status next to the declarations that produced it.

Scoping

Declarations scope to devices or groups. Because DDM is enabled per device, a pilot group can run DDM while the rest of the fleet stays on classic MDM.

Windows profiles

Build Windows policy in a visual builder and assign it. Xavier translates it to native Windows policy and reconciles each device to its desired state, so a PC that missed a change converges at its next check-in.

Policy catalog

Assignment and reconciliation

• Assign to devices or groups. Per-device exclusions let you carve out exceptions without restructuring groups.
• Xavier issues only the operations each device needs to reach its desired state.
• Removing a profile, or a device from a group, generates the matching delete operations.

App distribution

Xavier installs software through each platform's native mechanism, plus its own package libraries for custom software.

Apple (Mac, iPhone, iPad, Apple TV)

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

macOS packages

Upload .pkg, .dmg, or .zip files to the Mac app library. Xavier reads their metadata; the agent downloads each package, installs it silently through the Root Helper, and refreshes inventory. For apps shipped as a plain .app bundle with no installer, compress the bundle and upload the .zip. For ongoing third-party patching at scale, use Munki.

Windows

Upload MSI, EXE, MSIX, or APPX installers to the Windows app library, then deploy to or remove from devices or groups. Xavier reads the metadata. EXE deployment, including silent install and verification, requires the Windows agent.

For packages from the public catalog, see winget; for your own package feed, see Chocolatey.

Android

• APK library: upload APKs and deploy them to Device Owner devices, optionally blocking uninstallation.
• Managed Google Play: coming soon.

Where files live

Your own uploads are served from your storage (any S3-compatible service or Google Cloud Storage), which you must connect first. See Storage and file delivery.

Munki integration

Xavier runs a full Munki workflow for Mac software. It manages a repository in your own storage or connects to one you already run, and you manage catalogs, packages, and manifests 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 Macs with per-repo credentials.
• Bring your own: connect an existing repository over S3-compatible storage, SFTP, or Git.

A connection test validates credentials before saving. A reconcile action syncs Xavier's database with the repository contents.

Packages and catalogs

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

Manifests

Manifests compose in order: site-wide default, per-group, then per-device. Assign software in the console; no plist editing.

Client deployment

Xavier deploys the Munki client to your Macs and configures it with the repository and credentials in one action.

Munki Sources

A source watches where a third-party app publishes releases, then fetches and imports each new version into your repository.

Source types

• GitHub releases: a repository's release feed.
• Sparkle appcast: the update feed most Mac apps 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: check the source for a version newer than the repository's.
• Download and verify: download and verify against a pinned checksum.
• Import: add the new version to the testing catalog.
• Promote: promote to production manually, or mark the source auto-promote. You can be notified when an update appears.

Health and history

Each source keeps a full import history. A feed that stops working or a checksum that stops matching raises an alert. Six Munki source events can be routed to the notification center.

Mac package management

The macOS agent reports Homebrew, npm, pip, and Ruby Gems packages in real time, with search, install, update, and remove from the console.

Each Mac's page lists installed packages per manager, with versions and available updates. Fleet-wide views show which Macs have a package and where updates are pending.

Remote actions

• Search each ecosystem's registry and install to any device.
• Update or remove packages per device.
• Install Homebrew 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 Macs that drift from it and taps or untaps remotely to converge.

winget

winget, the Windows Package Manager, is managed through the Windows agent. The agent reports every winget package on a PC by its Id, with any available update, and installs, updates and removes packages on your behalf.

From the console

• Search the winget catalog and install a package on a PC.
• Update one package, update all of them, or remove a package on a PC.
• Run the same action across the fleet in one step.
• See which PCs have a package and where updates are pending.

Package assignments

Assign a winget package to every PC or to device groups, and choose whether it is installed, kept updated or removed. Assignments support update windows and canary rollouts, and the agent re-applies them, so a PC that was off catches up when it next connects.

Installing winget

Xavier installs winget automatically on PCs that lack it: on every PC, on the device groups you choose, or on any PC a winget package is assigned to. You can also install it right away on all PCs, on a device group, or on chosen PCs; a PC that is off gets it when it next connects.

winget policy

• Sources: add private sources to every PC, and turn off the Microsoft Store source.
• Settings: turn off local manifests and hash overrides.
• Deny list: packages that may not be installed. Xavier refuses them on every winget command it runs, from the console and from assignments. People who have winget on their PC can still run it themselves.

Limits

• Packages install for the whole machine. A package that only offers a per-user installer cannot be installed by Xavier, and says so.
• The Microsoft Store source is not used.

Other package managers on Windows

The agent also reports npm, pip, Ruby Gems, Go binaries, and .NET global tools. These are inventory-only: they feed compliance and vulnerability scanning, but cannot be installed or updated from the console.

Chocolatey

Chocolatey is managed through the Windows agent, with your Xavier feed registered as a source.

What the agent does

• Installs Chocolatey on PCs where it is missing.
• Registers your Xavier feed as a source.
• Periodically re-applies the package set you assigned, so a PC that drifted or was off converges again.
• Reports installed Chocolatey packages in inventory, even when the agent lacks the privileges to change them.

From the console

Set up Chocolatey on a PC and apply its package set as a remote command, delivered in seconds over the agent's live connection.

Runtimes and vulnerabilities

Xavier tracks outdated language runtimes and vulnerable project dependencies on Macs and on Windows PCs running the agent.

Language runtime governance

The agent inventories installed runtimes, including copies installed by version managers such as nvm, pyenv, rbenv, asdf and Homebrew, not only those on PATH: Java, Node, Python, Go and Ruby on macOS; Java, Node, Python, Go and .NET on Windows. Node, Python, Ruby, Go and .NET are checked for end-of-life dates and currency; see project and runtime checks.

Findings appear on the device page and in compliance. A runtime below its supported baseline is reported as unmanageable, not updated automatically.

Project dependency scanning

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

• Dependencies with known vulnerabilities.
• Outdated dependencies, with the current and latest versions.
• Per-project remediation, pushed from the console. This is macOS only; Windows devices are scanned and reported the same way.

Manifests are read as text. No build tool runs, so nothing is resolved, restored, or installed. Versions that are not written out concretely, such as a Maven property or an unpinned range, are skipped, not guessed.

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

AI inventory

Xavier discovers the AI on your Macs and Windows PCs, measures it against your policy, and scores each device. Discovery changes nothing on a device; to act on findings, see AI enforcement.

What Xavier discovers

• Local models, with sizes and content digests, and the runtimes that serve them.
• Coding agents and AI apps, including assistants that can read files and run commands.
• MCP servers: the tools each assistant is connected to, and the package each runs, checked against the GitHub Advisory Database.
• Browser and editor extensions for AI.
• Exposed credentials: API tokens left in AI tool configuration. Only the location and kind are reported; the value never leaves the device. See AI governance checks.

Collection is off until you turn it on

An administrator enables AI inventory in Settings. Reading configuration files in home folders, which MCP servers and credential findings need, is a separate setting. Excluded folders are skipped on the device. Prompts, conversations and anything typed into an AI tool are never collected.

Deciding what is allowed

Your AI policy lists the tools, MCP server packages and model sources you permit, and anything you block; blocking always wins. Until you write a policy, no allowlist rule fails. Approve or deny items straight from the AI report, set an expiry on an approval, and let anyone in the console request a tool.

Scores, groups and reports

• Each device gets an AI risk score out of 100, with the findings behind it. Sending data to an outside AI provider counts against it; running models locally does not.
• AI checks are compliance rules, and smart groups can use AI posture, such as devices with an unapproved MCP server.
• Export the inventory as JSON or CSV, or save snapshots to compare over time.

Available on Macs and on Windows PCs running the Xavier agent.

Scripts

The script library runs your own shell and scripting code on Macs and Windows PCs.

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.
• Scripts are versioned and edited in a syntax-highlighting editor, with tags for organizing.

Running and results

• Run a script against a device from the library; it is delivered over the agent's live connection.
• Each run's output and exit status is recorded in the run history.
• Runs have a timeout, so a hung script does not block the device or queue.
• 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 by default. A script marked run as root runs through the Root Helper, which must be enabled for that Mac; see the macOS agent.

On Windows, the agent runs as a system service, so scripts always run elevated; there is no per-script flag. If you don't want that, deploy the agent in constrained mode.

Script automations

An automation is a saved script, a scope, and a trigger: run this, on these devices, when this happens.

Triggers

Condition triggers can respond to anything a smart group can match, including facts your own scripts report; see device attributes.

A frequency limits how often a device may be acted on: once, once per day, once per week, once until it succeeds, or every time. Some combinations are refused; for example, a check-in trigger cannot run every time, because agents check in every five minutes.

Scope

Target everything, whole platforms, or chosen static or smart groups. An exclusion list overrides every inclusion.

Guardrails

• Every automation starts paused. Nothing fires the moment it is saved.
• A canary stage. Run against a few devices you name, then widen to full scope.
• A circuit breaker. Consecutive device failures pause the automation and record why.
• Nothing is retroactive. Enabling an automation applies from the next trigger onward. A condition automation does not fire for devices already in the group.
• Concurrency and batch limits. Cap how many devices are acted on at once and per run.
• 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 is recorded in the run history and the activity log with its output and exit status, attributed to the automation. Notify on failure only, on every run, or never.

An automation can name an attribute to collect after the run, so success is judged by the machine's state, not the exit code. Verification never blocks the run. For condition automations, a device that stays in the group after the run is one where the fix did not work.

Application usage

Application usage shows whether installed apps are actually opened, which helps with license renewals. It is reported by the agent on Macs and by the Android agent.

Turning it on

• A master switch, plus a separate switch per platform, since the platforms measure different things.
• Retention: days of usage to keep. Older records are deleted automatically.
• Never-record list: apps that are never measured. The exclusion is applied on the device, before anything is sent.

The device aggregates usage into daily totals (for example, six hours of an app on a given day). No open/close timeline is ever built or sent.

The report

The Application Usage report ranks apps by use over a period you choose and lists dormant apps: installed but untouched for the whole period.

What the numbers do not cover

• The report shows its coverage: how many devices report out of the total, and which platforms cannot report.
• iPhones, iPads, Apple TVs, and Windows PCs report no usage, so an app that looks unused may be used there.
• Android is shown separately. Without usage access granted, a device reports launches but not time used.

Blocked applications

Name the applications your organization does not permit, and Xavier stops them running. A rule can apply to every device or to specific device groups.

Which platforms enforce this

• macOS: the Mac refuses to start the application, so it never runs.
• Windows: the PC refuses to start the application, through an App Control (WDAC) policy the Xavier agent builds from your rules.
• Android: the package is suspended. It greys out, cannot be opened, and the user is told why. You can choose to hide it completely instead, which also stops it if running. Hiding is off by default.

iOS does not enforce application blocking, because it offers no mechanism for it, and the console says so on that tab.

Blocked means it never opens

The launch is refused, so no window appears and no work is lost. Copies already open when you add a rule keep running; closing them is a per-rule option, off by default, and the console shows how many devices are running the app first.

How an application is recognised

• On a Mac, rules match the code signature, not the name or location. Renaming, moving, or duplicating an app does not get around a rule.
• On a Windows PC, a rule names one identity: the publisher's signature, the product name, the file name, the file's hash, or its path. The strongest is the publisher's signature.
• On Android, a rule names the package.
• You pick applications from what your fleet has installed instead of typing an identifier, so a typo cannot produce a rule that matches nothing.
• Mac applications with no code signature cannot be blocked, and the console says so.

What has to be in place

On a Mac, blocking is done by a security extension inside the Xavier agent, and it must be approved before it works; see macOS agent. On a Windows PC, the Xavier agent puts the App Control policy in force. Some changes need a restart, and some editions of Windows cannot take the policy. The console shows which devices are actually enforcing, and why any others are waiting.

What can never be blocked

Rules cannot block the parts of macOS or Windows a device needs to work, or Xavier itself, since blocking the agent would leave no remote way to undo it. Xavier fails open: if anything goes wrong with a policy, applications run.

What people see, and what you see

The person at the Mac or PC is told the application is blocked by organization policy. You get a record of what was blocked and when; repeated attempts are grouped into one entry with a count.

What this does not cover

Blocking an application does not reach a browser tab, so a service's web version stays reachable. Use the network filter to deny the destination. Blocking an AI tool in AI policy writes both kinds of rule at once. Those rules appear here marked with their source, and lifting the decision removes only the rules it created.

Website and destination blocking

Name the destinations devices may not reach, and a filter on the Mac or Windows PC refuses them. Unlike application blocking, this reaches browser tabs.

This page holds both hand-written web filtering rules and the egress rules AI policy creates when you block an AI tool. Each rule records its source.

What a rule says

• Destinations: one or more hostnames. Each covers the host and all its subdomains.
• Deny or allow: deny refuses the connection. Allow is an exception and always wins over deny. For example, one deny plus two allows can block an AI provider for everything except two approved tools.
• Applications, optionally: limit a rule to particular applications. Without this, the rule applies to everything on the device. Only Macs can tell which application made a connection; on a Windows PC a limited deny applies to every application, and a limited allow is not used.
• Which devices: every Mac and PC, or specific device groups, scoped the same way as blocked applications.

Where this works

On Macs, through a network filter system extension in the Xavier agent. It needs a one-time approval; see the macOS agent.

On Windows PCs, through a DNS filter in the Xavier agent: the PC looks names up through Xavier, and blocked names do not resolve. Xavier switches off DNS-over-HTTPS in Edge, Chrome and Firefox so their lookups go through the filter too. An application with its own encrypted DNS, or one that connects straight to an IP address, is not filtered.

The console reports how many devices in a rule's scope are actually filtering, for each platform. Rules can include phones and tablets but do nothing there today.

What people see

On both Macs and Windows PCs, the person gets a notification that the site is blocked, and the Xavier block page opens in a new browser tab next to the one that failed. It names the site and tells them to contact their IT administrator. Xavier never intercepts the secure connection itself, so the original tab shows the browser's own connection error.

Destinations no rule may block

Apple's and Microsoft's device management, sign-in and update services, certificate checks, and Xavier itself are always allowed, so a rule can never cut a device off from management. A rule denying the whole internet is refused.

No rules means nothing is filtered

Only a rule you write blocks anything. If a policy cannot be read or delivered, or the filter stops, connections are allowed.

Only administrators can write these rules, and every change is recorded in the activity log with who made it.

Removable storage

Control what happens when a USB drive is plugged into a managed Mac or Windows PC. One rule covers both platforms, with the same modes, device group scoping, and approved drives list.

Start by watching, not blocking

• Audit: nothing is blocked. Every drive plugged in is recorded, with the machine and how often.
• Block: drives do not mount at all.

Start in Audit. It cannot disrupt anyone, and it builds the drive inventory you approve drives from. When several rules cover a device, the strictest wins, and approved drives are shared across them.

Approving the drives people actually need

Approved drives are exemptions to whichever mode is in force, not a third mode. You approve drives from the inventory your fleet has actually used. An entry with no serial number matches every drive of that make.

A drive is recognised by the serial number it reports, which can be copied, so approval guards against carelessness, not deliberate circumvention.

The platforms differ, and the difference matters

The Xavier agent enforces rules, so machines without it are unaffected.

• macOS: Xavier refuses the mount. A blocked drive never appears.
• Windows: the drive mounts first and the agent disables it immediately afterwards, so a blocked drive is briefly readable. Treat it as a strong deterrent, not airtight.

If that gap is unacceptable, use a Windows configuration profile to deny removable storage at the class level instead. It blocks before anything mounts, but you lose reporting and the drive inventory.

What people see

By default the user is told when a drive is refused, so they don't mistake it for broken hardware.

What this does not do

• It does not stop phones. A connected iPhone or Android handset is a media-transfer device, not a mounted volume.
• It does not stop data leaving over the network. Use the network filter for that.
• It never touches an internal disk, the startup volume, a system volume, a Time Machine volume, or a network share. The device enforces this list too, even against a policy delivered by a bug.
• It has no read-only mode.

No rules means nothing happens

Until you write a rule, nothing is recorded or blocked. Missing, unreadable or undelivered policy enforces nothing, and an unrecognised drive is allowed and logged.

AI enforcement

Enforcement acts on what AI inventory finds. It is off until you switch it on: discovering a tool never removes or restricts it. Available on Macs and on Windows PCs running the Xavier agent.

Five mechanisms

• Stop the application: the Mac or PC refuses to launch it. Mac and Windows.
• Deny the destination: the tool cannot reach its service, including its web version in a browser. Mac and Windows.
• Remediate: one named change, such as removing an AI connector from a configuration file, uninstalling a tool, or pinning it to an approved version. Mac and Windows.
• Configure: an approved app runs within limits you set, such as which AI providers and connectors it may use. Mac only, by configuration profile.
• Pin: the fleet runs one verified build of a tool, and each new release waits for approval. Mac only.

Blocking a tool uses the first two together. They are ordinary blocked application and network filter rules, marked with the decision that created them, with the same prerequisites. On a PC, command-line coding agents are removed instead of blocked, because their builds change too often.

Marking a tool as blocked in the catalog records the decision and raises a violation. Pushing enforcement rules when you save is a separate setting, off by default.

AI browser extensions

Blocked through each browser's managed settings: Chrome on Macs, by configuration profile; Chrome and Edge on Windows PCs, by the Xavier agent, alongside any entries your organization already manages.

Blocking a provider, rather than a tool

Denying a provider's API also affects its own app, scripts, and tools you approved. On a Mac, allow exceptions can keep approved apps working; on a PC the deny applies to every program. Anthropic, OpenAI, Google, Perplexity, Mistral, Cohere, Groq, and GitHub Copilot come with their API endpoints filled in. Local inference is never blocked.

Remediations

A remediation makes exactly one change and keeps a copy of any file it edits. On an offline device it waits until the device is back, or expires. Every change is recorded with who started it.

Knowing it works

Each device shows how many blocked tools are not actually stopped yet. You are alerted when a tool starts being blocked, a change fails, or an approval runs out, and everything is in the activity log.

Security model

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 they cannot be replayed.
• Device requests are verified against those certificates, including revocation checks, on Apple and Windows.
• Revoke or reissue any device's certificate from its detail page. Revoking cuts the device off immediately.
• Expirations are scanned daily and alerted well in advance. A fleet-wide verification report shows every certificate's state.

Credentials can only do their own job

A credential used in the wrong place is rejected without revealing what kind it was. Every credential is bound to your tenant; see Tenant isolation.

Access control for your team

• Roles: administrators have full control; auditors can see everything (including reports and the audit log) but change nothing.
• Admins can sign in with your identity provider over OpenID Connect or SAML 2.0, and you can require it; see Console sign-in and SSO.
• Browser sessions have a limited lifetime, and end at once when someone is deactivated, deleted, changes role or resets their password. Anyone can sign themselves out everywhere. Passwords are stored only as strong one-way hashes.
• Every console sign-in, successful or not, is recorded in the activity log.
• Sign-in attempts, API calls, AI queries, and device check-ins are rate-limited.

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; they can be replaced, not read back.
• Revealing a recovery key is an authenticated, audited action. See FileVault key escrow.

Devices are hardened too

• On Macs, privileged work goes through the Root Helper, which accepts requests only from the signature-verified Xavier agent; see macOS agent.
• On Android, the agent's identity is pinned in the enrollment QR code, so a tampered agent cannot enroll. Its local data is hardware-encrypted.
• On Windows, installers are verified before and after they run; see Windows agent. The tray app's channel to the service accepts only three fixed requests with no arguments, so local input cannot become a path, package name, or command line.

Everything is on the record

Every command, script run, key reveal, and AI query is logged in the activity log with who, when, and the result.

FileVault key escrow

Xavier turns on FileVault across your Macs and escrows each personal recovery key, encrypted, so a locked-out user can be recovered from the console.

How escrow works

• Xavier deploys the built-in FileVault profile, which includes a per-device escrow certificate.
• When FileVault enables (immediately, or at next login), macOS encrypts the personal recovery key to that certificate and returns it.
• Xavier decrypts it and re-encrypts the key with AES-256-GCM for storage. It is 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 key after any reveal. Rotation goes through the normal MDM channel and completes at the device's next check-in.
• Monitor: FileVault status is part of security posture and compliance, so unencrypted Macs show up immediately.

Storage and file delivery

Everything you upload (installers, packages, signage media, collected diagnostics) lives in a storage account you own, not Xavier's.

Connecting your storage

• Connect any S3-compatible service or Google Cloud Storage under Settings. This is required to upload packages, apps, or media. App Store and VPP deployments need no storage connection.
• Credentials are encrypted and cannot be read back after saving (see security model).
• The connection is tested before it is saved, so a bad credential fails immediately.

Your bucket is never public

Xavier never makes an uploaded file publicly readable and never asks you to relax bucket permissions. A device reaches a file only after authenticating to Xavier, in one of two ways:

• Xavier streams the file itself. The device authenticates on every request and Xavier proxies the bytes from your storage. Signage media works this way.
• Xavier mints a short-lived link. When an app deployment is dispatched, Xavier generates a signed URL for that one object, valid for a limited window. It is created when the command is sent, not stored.

An expired link grants nothing, and a device without a valid credential is refused. Knowing your bucket name lets nobody fetch anything.

No device ever holds your storage credentials; only Xavier talks to your storage account. The same applies to a Munki repository Xavier manages in your storage.

Bring your own database

Each organization's data lives in its own database. Xavier hosts it by default, or you can keep it on a MongoDB you run yourself.

What you need

• MongoDB 6.0 or later, reachable over TLS.
• An empty database for Xavier, with a dedicated user that has access to that database only. Xavier support gives you the details.
• Xavier's outbound IP address allowed in the database's network access list. Xavier support gives you the address.

Connecting it

• Xavier support connects your database, either when your organization is created or at any time later.
• Before anything is stored, Xavier checks the connection, version, permissions and network round trip, and that the database is empty.
• Your connection string is kept in a secrets vault. It is never stored in Xavier's database, written to logs, or shown again.
• An existing organization moves with all of its data. The console and devices pause while it copies, usually a few minutes, and if anything fails nothing changes. Moving back to Xavier hosting works the same way.

Settings › Organization shows where your data lives.

Compliance engine

Xavier evaluates every device against a set of rules. Each rule has a severity (critical, high, medium, low), a category, and the platforms it applies to.

Built-in rules

Each category's page lists where every rule gets its data and what counts as a pass.

How a result is decided

• Each rule checks one fact the device reports about itself, and applies only to the platforms it names.
• A device is compliant when it passes every enabled rule for its platform. One failed rule makes it non-compliant, whatever the severity.
• Severity sets how a violation is ranked and announced. You can change any rule's severity, scope it to device types, or switch it on or off.
• Rules marked "off by default" usually depend on a policy of your own. Turn them on from the Compliance page.
• A device without a given package manager passes that package manager's rule.
• Results use each device's latest reported data and are recalculated whenever you open a compliance view. You can also evaluate the whole fleet or one device on demand.

From finding to fix

• An hourly check sends a notification when a device falls out of compliance (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 time.

Mac security checks

The Xavier agent runs in the signed-in user's session and re-reads these settings every five minutes, using standard macOS commands.

Mac package checks

Package checks run every ten minutes as the signed-in user. Project dependencies are covered in project and runtime checks.

Apple device checks

These values come from Apple's device management protocol and need no agent. Xavier queries each device shortly after enrollment, then about hourly (every six hours with Declarative Device Management). A device that is switched off keeps its last known state.

Windows checks

These checks use Windows' built-in device management settings and need no agent. Xavier collects them at enrollment and whenever inventory is refreshed from the device page.

On PCs running the Xavier agent, three more rules check developer packages, refreshed every six hours.

Android checks

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

Project and runtime checks

The agent scans each user's home folder for software projects, up to ten folders deep and 500 projects. It skips system, media, and hidden folders, and dependency or build output folders such as node_modules. Which manifests are read on each platform is listed in Runtimes and vulnerabilities.

• Mac: full scan every six hours.
• Windows: full scan every six hours; project file changes are picked up as they happen.

Direct dependencies are checked, development dependencies included. Results update whenever a device sends new project data.

For runtimes, the agent reports every installed copy of each language (see Runtimes and vulnerabilities) hourly on Macs and every six hours on Windows. Xavier looks up each version's release line on endoflife.date.

AI governance checks

These rules use what AI inventory finds, so they need AI inventory enabled in Settings. Rules that read inside configuration files also need the separate setting for reading their contents. The agent refreshes the inventory every six hours, when collection is switched on, and on rescan.

macOS agent

The Xavier agent is a menu bar app that adds what MDM 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 jobs run in separate system extensions, so a failure in one cannot take out the other:

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

Xavier deploys the profiles that approve both. On a supervised or automatically enrolled Mac approval is silent; on a user-enrolled Mac, the user allows each one once in System Settings. The console reports each extension's status separately.

Deployment

• Deploy the built-in agent configuration profile (already pointed 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 valid only for that device's own reporting, and appears as a live connection on the device page.

The agent updates itself automatically.

The Root Helper

The agent runs without administrator rights. The Root Helper is a separate root service that does privileged work for it. It is off by default; until you turn it on, the features below are unavailable.

What it unlocks

• Silent installs of managed Mac apps: .pkg and .dmg alike; see app distribution. Macs without the helper cannot be deployment targets.
• Munki client setup and auto-deployment.
• Scripts marked run as root. On a Mac without the helper, these are refused, not 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 selected device groups for a pilot.
• Xavier pushes the signed, notarized helper package silently over MDM. Targeted Macs install it on their next check-in, with no prompts.

The settings page shows how many Macs are in scope, installed, and pending; click a count to see the devices. When a newer helper ships, Xavier re-pushes it to Macs running older versions. Turning the toggle off stops new installs and makes the privileged features unavailable again.

Security

The helper exposes only four operations: install a package, install a disk image, run a script under a named interpreter, and report its version. It accepts requests only from the genuine Xavier agent, verified by code-signing requirement, and the agent verifies the helper's signature the same way.

Windows agent

The Windows agent is a Windows service, with a small tray app, that keeps an always-on connection to the console. It adds what Windows MDM cannot: live software inventory, developer tooling and runtimes, project scanning, script execution, and silent installs of non-MSI installers.

What the agent does

• Reports device facts (name, OS version, model, processor, memory, storage, local accounts) every five minutes, with a heartbeat in between.
• Reports installed applications from Add/Remove Programs, winget, and Chocolatey as one list, re-sent when it changes.
• Reports packages from npm, pip, RubyGems, Go, and .NET global tools; see other package managers on Windows.
• Discovers language runtimes and project dependencies for vulnerability scanning.
• Runs scripts and installs managed Windows apps.
• Manages winget and Chocolatey.

Installing apps MDM cannot

Windows MDM only installs MSI packages. The agent installs MSI and EXE silently, using the right switches for the installer's toolkit or an override you supply.

• Verified before it runs: the download must match the SHA-256 you supplied, and an app can be marked as requiring a valid signature.
• Verified after it runs: a successful exit code is checked against Add/Remove Programs. If nothing was installed, the deploy is reported as failed.
• Reported in full: exit code, output, duration, and whether a reboot is pending appear on the device's log.

Privileges

The agent normally runs as a system service, so installs, Chocolatey, and elevated scripts need no separate helper or on-device approval. If you deploy it in constrained mode, it still reports everything, but install and Chocolatey operations are refused with a reason shown in the console.

The tray app

The tray app shows the user connection status, last sync, a warning when the device has flagged vulnerabilities, and tabs for the device, its runtimes, and its packages. Its menu offers only Sync Now and Check for Updates. Closing it does not affect the service.

Deployment

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

Devices running an older agent version are re-pushed the current installer on their next check-in.

Digital signage

Megaphone turns enrolled iPads, Apple TVs, Macs, and Android tablets into signage displays. A signage device is an enrolled device running the Megaphone app, so compliance, commands, app updates, and monitoring still apply.

Setting up a screen

• Deploy Megaphone through app distribution; Xavier hosts the builds and keeps them updated.
• Managed devices pair automatically via managed configuration. For manual setup, use the six-character pairing code.
• The device appears in the signage dashboard, linked to its MDM record. Matching on device identity prevents duplicates.

Content

• The media library holds uploaded images and videos, with generated thumbnails.
• Send or clear content on one screen or a group of screens.
• An idle screen sets what displays show when nothing is scheduled.
• Per-device content history and a signage activity feed track what showed where, and when.

MCP server

Xavier's Model Context Protocol (MCP) server lets AI assistants (Claude Desktop, VoxyAI, Cursor, or any MCP client) query your fleet in natural language, for example "Which Macs have outdated Homebrew packages?"

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. Queries are rate-limited per token and logged in the activity log with the token and client.

Safety properties

• MCP tokens work only at the MCP endpoint and cannot call the admin API. See the Security model.
• Responses are stripped of recovery keys, bootstrap and unlock tokens, push credentials, Wi-Fi passwords, and SCEP challenges.
• Revoking a token cuts access immediately.

Tenant isolation

Your organization is a tenant of the hosted Xavier service. Tenants are isolated structurally, not just by permission checks.

What you get

• Your own console address: your organization's own subdomain.
• Your own database: devices, inventory, keys, and history live in a database for your tenant alone.
• Tenant-bound credentials: every session, device credential, and AI token is tied to your tenant and rejected anywhere else.
• Your own enrollment identity: Windows enrollment credentials and device enrollment are per-tenant and rotatable by you.
• Your storage: packages and media are served from your own storage account; see Storage and file delivery.

A curated software library, included

The Xavier team packages, tests, and publishes common Mac apps. They appear in your Munki catalog ready to import.

API reference

Everything the console does is available through a REST API, described by an OpenAPI 3.1 specification (about 400 paths and 500 operations).

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