Skip to main content

Why MDM Integrations?

MDM (Mobile Device Management) integrations deploy and configure AI coding tools across your organization’s devices. Connect your MDM provider to Unbound and you can:
  • Automate tool deployments: Push AI coding tools to users automatically
  • Identify device owners: Map devices to users by serial number, so activity is attributed without importing a device list
  • Streamline onboarding: New team members get AI tools configured without manual setup
  • Track deployments: See which users have which AI tools installed
Settings URL: https://gateway.getunbound.ai/settings?tab=integrations

Integrations Settings

Click here to manage your MDM integrations

How to Connect

  1. Go to Settings > Integrations
  2. Click Connect on the MDM provider you want to integrate
  3. Enter your API key
  4. Click Add
Once connected, you’ll see a Connected status badge on the integration card.
Keep your API key secure. It provides access to your MDM organization data.

How a device gets attributed to a person

A machine identifies itself by hardware serial, and everything it reports is attributed to whoever JumpCloud — the MDM Unbound connects to for device ownership — names as that serial’s owner. You do not need to import a device list before you roll out.
While a JumpCloud integration is active, it is the only source Unbound asks. A serial JumpCloud cannot resolve does not fall back to the device list on Settings → Devices, even when that list has the answer. The device is attributed to a placeholder instead, and its activity stays there until the owner is identified.This matters most when you connect an MDM to an organization that already has an imported device list: attribution that used to work from that list now depends entirely on JumpCloud knowing the serial. Before connecting, confirm its inventory covers the serials you are rolling out to.

Placeholder users

A device whose owner cannot be resolved is held against a placeholder account named after its serial — the serial number, at the email domain of an existing user in your organization, so C02XK1ABCDEF@yourcompany.com. During a rollout you will see these rows in Users, and they are expected, not a fault:
  • A placeholder row looks like any other in the Users list — it carries an Unidentified status pill (filter the Users list by Status → Unidentified to see them all), shows the serial number in place of a name, and has an info icon beside it pointing you at Settings → Devices.
  • A placeholder is one device, not a person. It is excluded from the Total users figure that Analytics → Usage → AI Usage measures adoption against, so it never dilutes your adoption numbers. It does still appear in the Policies → Users list, under Individuals, and its count.
  • When the owner is identified, the placeholder folds into their real account, bringing its devices, connected tools and discovery history with it, and the serial-number row drops out of your organization. This happens when you map the device to a person on Settings → Devices, or when the device next checks in as that person.
  • A directory sync skips placeholders entirely — Okta will neither enrich one nor suspend one.
A placeholder that persists means the serial never resolved. Add the device to your MDM inventory, or add the device on Settings → Devices and disconnect the MDM if it is not the source of truth for these machines.
Install reports are rate limited to 12 per device per hour, with an organization-wide ceiling of 20,000 per hour. A device reporting once per policy run never comes close; one stuck in a retry loop gets a 429 with a Retry-After header saying how many seconds are left in the window.

Supported AI Tools

MDM integrations help deploy and configure these AI coding tools with Unbound:
  • Cursor - AI-powered code editor
  • Claude Code - Anthropic’s agentic coding tool
  • Codex - OpenAI’s coding assistant
  • GitHub Copilot - GitHub’s AI pair programmer (VS Code extension and CLI)
  • Augment Code - AI coding assistant for large codebases (VS Code extension and Auggie CLI)
  • Pi (Beta) - Terminal coding agent, set up only on devices where pi is detected (Python installer, Intune and Workspace ONE; the signed macOS package for Jamf does not set up Pi) — see Pi
  • AI Tools Discovery - Discover and manage AI tools across your organization

Network requirements

On a private deployment, substitute your own hosts for backend.getunbound.ai and api.getunbound.ai. Behind a TLS-inspecting proxy. Everything Unbound installs uses the operating system’s own certificate store, so a proxy whose root CA is already trusted on the device — the normal managed-fleet arrangement — works with no extra configuration. The macOS runtime package is the exception: it is verified against a pinned hash and signature, so a proxy that rewrites it makes the install fail loudly rather than run modified code. Exclude that host from TLS inspection. Off the network. A scan that cannot reach the backend holds its report on the device and sends it at the start of the next scan. Reports older than 24 hours are dropped rather than uploaded stale, so a laptop that was offline for a week reports fresh state when it reconnects instead of a backlog. The upload link. A scan’s tool inventory goes to a short-lived storage link rather than to the backend. If that upload fails for any reason at all, the report goes to the backend instead, so blocking the link costs time and never data. How much time depends on how it is blocked, and a scan sends one report per tool per user: On a device with several tools and several user profiles, a stalling proxy is the case worth avoiding — it turns a quiet fallback into a long scan.