Product Office Hours #9 - AI Governance: JNUC recap - Oct 15th *Q&A in thread*

Currently, converting profiles → blueprints via the cli doesn’t allow for viewing the blueprints components. Will this be adjusted in the future?

As we convert to blueprints is the suggested workflow to duplicate the blueprint and deploy it, once deployed then remove legacy configuration profile? 
Secondly, we had some discussions at JNUC this year around which instruction set (blueprint / DDM vs Config profile) would win.  Is it still our understanding that blueprints are to take precedence?  if you have a less restrictive blueprint than current config profile, then who wins?  

Third - when deploy blueprints for software updates, is it recommended to delete whatever current deployment you have out there and create new for enforcing new deadlines/versions or can you simply overwrite the existing?

Unfortunately I won’t be able to make this event, will look forward to the recap afterwards

Also hoping for a recap, darn class at the same time and no students interested in learning Blueprints!

Q&A: Product Office Hours recap: AI governance and JNUC follow-ups 

This week's Product Office Hours covered AI governance and a JNUC recap, with Josh Stein (VP of Product Strategy) and Colton Chojnacki (Senior Product Manager). Here are questions asked during the session, from both the live Q&A and the chat. 

What AI harnesses we should be supporting next? 

AI governance policy currently supports Claude Desktop, Claude Code and Codex. Visual Studio Code and OpenCode support is behind a feature flag today and is about ready to be released to everyone, so if you'd like early access before then, get in touch and we can arrange it. Cursor support is coming soon. 

Community suggestions so far are DeepSeek, Grok, Goose, Mastra, Pi, OpenHands and Cline. If there's a harness you rely on that isn't on the list, reply on Jamf Nation and let us know. One constraint: a harness needs to support managed settings before we can write policy for it. 

Where should we start with a first AI governance policy? 

A good place to start is what the community is already doing: controlling which models people can use (for cost control or to set a default model), requiring users to log in to your organization's instance rather than a personal one, blocking bypass permissions modes, allowing only approved MCP servers, and using the sandbox to control file access and which binaries can run. The last two are more restrictive. The easiest quick wins, which won't get in the way of productivity, are forcing an organizational login, adding banners that remind people of your acceptable use policy or share company announcements, and turning on OpenTelemetry export for data collection. If you've already hand-rolled policy, the download and upload features let you bring it into AI governance so it can be managed centrally. 

Policy created and managed in AI governance becomes a component in your blueprint catalog. Drag it into a blueprint and you can manage and scope it with everything else you already do in blueprints. 

While Jamf is Apple first and Apple best, what can those of us with mixed fleets do about AI governance? 

There are a couple of options today. Any AI policy you define in AI governance can be downloaded and uploaded to your MDM for Windows, so you can deploy it there if you choose. The Jamf Extender has also been updated so you can do this straight from the console, packaging the policy (for example for PowerShell) so it's ready to use in the tool of your choice on a mixed fleet. 

Mobile is on the way too. One of the JNUC announcements was the target to bring AI governance to Jamf for Mobile (more on that below). 

For Model Insights, how are costs calculated, and can we update them to reflect the terms we have with each model vendor? 

The first release uses list pricing. We know everyone has different contracts and terms, we've had that feedback, and we're looking at how to support it, but it won't be in the first release. The dollar figures are there to help you contextualize a token. Is 64 million tokens $2 or $2,000 at list price? That gives you a rough sense of where most of your costs are going and how models compare. 

Model Insights counts tokens so you can see which models are used for which tasks, then write policy around which models are allowed for which users and groups, such as setting a default model. The target release is the end of the year. Cost is a driver for this release, but not the only focus, and over time there will be other reasons to match the right model to the job. We're also asking for input on what you'd do with this data. 

Is there an advantage to using this if we already track usage with GitHub Copilot? 

Yes. Model Insights tracks across multiple harnesses and inference providers at the same time, so if your organization has subscriptions from Anthropic, OpenAI and Microsoft, you get one view across all of them. 

Where we'd like to take it from here: some organizations set daily budgets for different groups, and people often want to request more usage or a higher budget. With visibility over token spend, you can use Jamf to build workflows that let end users adjust their own spend. 

Can these features be added to the Jamf Protect ingestion flow for other operating systems, along with a way to deploy a restrictions payload to different platforms (Intune, Canonical Landscape, Linux and so on)? 

Visibility through the telemetry agent on other platforms is not on the current roadmap. Policy export already works for other platforms today. A native restrictions payload for tools like Intune or Landscape isn't on the roadmap, but tell us if you'd use it. 

Can you confirm pricing for AI governance? Is it free, and do I need Jamf Protect to use it? 

AI governance is included as an entitlement in the Jamf platform offerings: Jamf for Mac, the Enterprise Plan, the Business Plan and, for MSPs, Jamf for MSP. All of the higher education variants of those packages include it too. AI governance runs on the same endpoint data collection pipeline as Jamf Protect, but you don't need a separate Jamf Protect license. The plans above cover it. 

Our organization uses several inference providers (Anthropic, Bedrock and Vertex). We want to focus on how AI is used rather than what it costs, especially local use like Chrome DevTools or Playwright. Can Jamf help? 

Yes. Cost is the headline for the first Model Insights release, but the data underneath it is really about usage. Model Insights works as a gateway on the device, so once each harness is configured to point at it, every inference call flows through regardless of provider. Anthropic, Bedrock and Vertex all show up in one view. Alongside counting tokens, it will classify the task behind each request, so instead of "this user spent 12 million tokens" you'll see "this user spent 12 million tokens generating tests." Classification happens on the device (more on privacy below). Local tooling like Chrome DevTools or Playwright is covered by the same path when used through a supported harness. If you have specific usage questions you want answered, share them and we'll use them to shape what the classification surfaces. 

Could this track individual users and machines with very high token usage, and spot the same inefficient prompt being used repeatedly, so we can educate users? 

It lays the foundation for use cases like that, and we can explore them. To start, you'll see your top token consumers and the classification of the tasks they're trying to accomplish. We won't analyze prompt by prompt at launch, so it won't tell you the same prompt has been run 50 times. But you'll be able to see the same type of task from the same user consuming tokens. 

The goal is that you can see which devices, users and tasks are burning the most tokens, then make policy decisions about which models and providers give you the most efficient use and best outcomes. Community stories show why this matters: top-tier models being used for simple jobs like summarizing an email, where a smaller model would do the job far more cheaply. There's also an appetite to help the community develop skills or additional guidance based on the sessions shared at JNUC. 

Can we control, or at least get insight into, MLX and other inference models running locally on device? We have a lot of researchers running local models. 

This is an active area of research and development for us, and there's nothing to announce yet. We said at JNUC that we're looking at supporting on-device inference, and alongside that we'd provide visibility into the usage of local harnesses and models. Expect visibility and control to keep growing as we go deeper into on-device and local AI. 

This is one of the reasons we're doing this on the device. We want to give you visibility and control for prompts that never leave the device, including the ability to route models or ensure certain prompts never leave it if your policy requires that. Usage and cost are the drivers of this first release, but it's foundational for the other on-device capabilities we want to bring to you. 

What mechanism is used to detect token usage, and is the content of the prompt visible? 

Prompts never leave the device for a Jamf system. Token counting and metadata extraction happen on the device, and Jamf does not collect or inspect prompt content in any cloud service. Any future capability in that area would be something you would have to explicitly enable. 

What else is coming for AI governance after JNUC? 

A series of incremental releases will add attribution, meaning more detail on which devices and users are running harnesses and on the commands being run. Browser insights, announced at JNUC, will use a browser extension to extend AI governance into the browser, with visibility of AI use on websites, who is signing in with personal rather than work accounts, and the ability to block risky uploads and set policy on what can be shared. Get in touch if you're interested in these use cases. 

AI governance on mobile is targeted by the end of the year through Jamf for Mobile on the Business and Enterprise Plans. It will give you inventory and visibility of which AI providers are being reached from mobile devices and which apps are reaching them, plus control over whether they can. For example, you could allow only your homegrown app to contact a cloud inference provider, rather than blocking or allowing it for every app. Visibility comes into AI governance first, with controls following. Community feedback is that mobile matters, since users often bypass corporate policy on mobile devices. 

Will there be ways to manage the level of inspection so AI governance doesn’t affect end user devices? 

The telemetry engine and inspection pipeline that powers AI governance also drives Jamf Protect, which already has dials for how much inspection happens on noisy processes. We've made performance improvements since the initial release and will keep tuning. Our goal is that you shouldn't have to manage this yourself. 

What are you most excited about in these announcements? 

Once Model Insights is rolled out and there's visibility into how tokens are being spent and on what, the next step is building what Jamf admins can do with that data. That includes letting end users temporarily request a higher-tier model, and creating the orchestration organizations are looking for. The other one is on-device and local AI: helping you make the most of Apple silicon while keeping your data under your control. 

Do you have examples of how higher education institutions are using AI governance? I'd like to share practical use cases with our IT leadership. 

Yes, there are higher education institutions using AI governance. We'll go back and explore any anecdotes or stories that can be shared. 

Would a session with customers who are using AI governance be useful? 

Plenty of thumbs up in the room. Community feedback is that a hands-on demo of what's possible, without risking your environment, would help people get started, especially where the AI team sits in a different country or works separately. Several customers offered to share what they're building internally. If you'd like to tell your story, please reach out. We'll look at what we can do.