Preloop vs Jamf AI Governance: rollout channel and agent control plane

Preloop is the open-source AI agent control plane: an MCP firewall, an AI model gateway with budgets, human approvals, runtime observability, and an audit trail in one self-hostable service. Jamf AI Governance is a capability of Jamf for Mac, generally available since June 30, 2026, that lets IT and security teams discover AI tools on managed Macs and deploy vendor AI settings to them through Jamf's device management.

The honest one-liner: Jamf decides how AI tools are configured on the Mac; Preloop governs what agents do, what they cost, and who approved it, across vendors and machines. These are different layers. Jamf is an excellent rollout and enforcement channel for vendor settings. Preloop is the cross-vendor control layer those settings can point at. Many teams will want both.

At a glance

What Jamf does well

Jamf has a real head start on the device side, and the controls are genuine:

• It is already on the Mac. Most Mac fleets in companies are managed by something, and Jamf calls itself "the standard in managing and securing Apple at work" (Jamf). AI Governance arrives through the management plane IT already runs, with no new agent to install.
• Settings that stick. Policies are deployed as Blueprints on Apple's Declarative Device Management (Jamf blog), and Jamf says enforcement "is at the OS level, so developers can't override them" (Jamf).
• Vendor-correct configuration. A "vendor control tracking engine continuously monitors supported AI platforms for new or updated controls" (press release). Keeping up with Claude Code and Codex settings by hand is real work.
• No extra license. For Jamf for Mac customers, it is ready to enable.
• Partner ecosystem. Jamf can register discovered agents with Okta for AI Agents for managed identities (press release).

If your question is "how do I make sure every Mac runs Claude Code with our approved model, tenant, and MCP allowlist," Jamf is the right tool.

Where Preloop fits

Vendor settings say what an AI tool may be configured to do. They do not decide, call by call, whether a specific action should happen now, and they do not add up what a team spent. That is the layer Preloop covers:

• Cross-vendor, one policy. The same YAML and CEL rules apply to Claude Code, Codex CLI, Cursor, OpenCode, Hermes, OpenClaw, and any MCP client, on macOS, Linux, or Windows. Jamf's coverage follows each vendor's settings, per platform.
• A human in the loop. When a rule says a person decides, the agent waits and the reviewer gets the tool, the arguments, and the agent's reasoning on a phone, watch, or Slack. Native action gates extend this to shell commands and file edits for supported agents.
• Cost you can act on now. The gateway attributes token spend per agent, session, and model and enforces budgets. Jamf's spend view is announced for Q4 2026 as an estimate from published prices.
• Session evidence. One timeline per session: model calls, tool calls, policy decisions, approvals, spend. Audit rows are sealed into a per-account hash chain with signed checkpoints. This is evidence that can support compliance work, not a certification.
• Servers and flows too. Agents that run in CI, on a server, or as Preloop flows never touch a managed Mac. Preloop governs them the same way.

What Preloop does not do: it does not manage devices, push configuration profiles, or stop an application that never talks to Preloop. That is what an MDM is for.

When to choose Jamf AI Governance

• Your fleet is mostly Macs, already managed by Jamf for Mac, and your first goal is consistent vendor settings for Claude Code, Claude Desktop, and Codex.
• You need settings users cannot change locally.
• You want discovery of AI tools from the device management console you already use.

When to choose Preloop

• You run several agent vendors, or agents on Linux, Windows, and servers as well as Macs.
• You need per-call approvals, budgets, and a session-level audit trail.
• You want an open-source, self-hostable control plane you can read and run in your own network.

How they combine

Use Jamf as the rollout channel and Preloop as the control layer the rolled-out settings point at:

1. Point vendor settings at Preloop. Where a vendor setting exposes a model endpoint or MCP allowlist, Jamf can deploy a value that routes through your Preloop gateway and MCP firewall, so every managed Mac uses the governed path and users cannot switch it off.
2. Deploy the Preloop CLI and discovery job. Preloop documents an MDM pattern for discovery: a scheduled job on every workstation with an API key scoped only to discovery reporting. Reports carry hashed fingerprints and paths, never user names, prompts, or credentials, and unenrolled tools appear in the console as "Not yet governed".
3. Keep each tool doing its job. Jamf proves the configuration is in place. Preloop records what the agents then did, who approved it, and what it cost.

Preloop does not ship a Jamf-specific integration or Blueprint today. The steps above use Jamf's general deployment features and Preloop's documented CLI and API.

FAQ

Is Preloop a Jamf alternative? No. Preloop does not manage devices. It complements Jamf: Jamf enforces vendor settings on the Mac, Preloop governs agent actions, spend, and approvals across vendors and machines.

We already use Jamf (or Intune). Do we need Preloop? If you only need consistent vendor settings on managed devices, perhaps not yet. If you need approvals on risky actions, budgets, or one audit trail across Claude Code, Codex, Cursor, and server-side agents, Preloop adds that layer, and your MDM is how you roll it out.

Does Jamf track AI spend? Jamf has announced estimated usage and spend insights based on token usage and published prices, targeted for general availability in Q4 2026. Preloop meters spend at the gateway today, for traffic routed through it.

Does Preloop work on Windows and Linux? Yes. The CLI ships for macOS, Linux, and Windows, and the control plane runs on any infrastructure.

Try Preloop

• Start your free trial
• Book a demo
• Preloop on GitHub

Last reviewed: 2026-10-08.