MDM policy & the expiring binary

Governing cloud AI is a metadata problem. A server exists, so a log exists, and policy is rules written against that log. Local inference has no server. The model runs on the laptop, the prompts never leave it, and an admin watching traffic finds nothing to watch. So Conifer governs the binary instead of the data. Restrictions push through the channel that already manages the device, and the build ages out so the fleet cannot drift onto stale code.

Policy rides the channel you already run#

On macOS, an MDM-pushed configuration profile lands at /Library/Managed Preferences/build.conifer.desktop.plist. The file is root-owned, so a standard user cannot edit it, and IT ships it through Jamf, Kandji, or whatever already manages the machine. Conifer reads it. No enrollment step, no device-management product to buy, no console of ours for the endpoint to phone home to. The org’s existing tooling is the delivery layer.

The profile carries a deny-list. Every key defaults to “not restricted,” so an empty or partial profile restricts what it names and nothing else. A policy can only remove capability. No key adds a grant, so a managed install is always a subset of an unmanaged one, never a superset. With no policy present, you get the consumer default.

The full set is the deny-list IT authors in a configuration profile. An unrecognized integration name is recorded so you can spot the typo, but it clamps nothing.

Where the policy actually bites#

Enforcement happens kernel-side, before anything reaches the model. When the studio asks for a set of agent grants, the policy reader clamps the request first: a capability the org disallows drops out of the grant set, whatever the settings screen asked for. The stripped capability is then absent from the decoding grammar and unreachable through the tool broker, the same fail-closed seam every grant already takes. The user cannot toggle around it, because the toggle is gone, not disabled. A malformed profile fails closed for the keys it does carry.

Nothing is collected, so the proof is pulled, not pushed. Each endpoint writes a signed posture document that your EDR already gathers, which turns “is this machine actually honoring the policy?” into a query against data you hold anyway. That seam has its own page: posture attestation.

The expiring binary#

Every build carries a signed expiry date, checked on launch. Inside its window the app runs in full. Past it, the build raises an “update needed” wall and stops until the user installs a fresh signed build. The date is absolute and signed with the release key, so a user cannot forge a later one. It is anchored against a high-water-mark clock, so rolling the system time backward reads as tampering, not a reset.

For a fleet, this is an update-governance primitive. You cannot reach into installed copies to recall them: a downloaded build runs forever and spreads beyond any URL. Each binary carries its own deadline instead. Code not refreshed past that deadline stops, so a managed fleet cannot quietly accrete months-old builds with stale policy handling or unpatched behavior. The expiry stamp also rides in the posture document, so an admin sees which machines are nearing their wall.

Control without surveillance#

Together the two cost the org nothing in privacy. Restrictions arrive through the MDM channel and only subtract capability. A binary that ages out on a schedule keeps the fleet current. Neither needs a collection server, neither sends prompts or usage anywhere, and the local-first guarantee holds on every managed machine.

What the org gets

A provable, subtract-only restriction set per machine, plus the ability to force a fleet off old code.

What the org never gets

Prompts, completions, file contents, or a usage feed. On a default install the posture document reports telemetry as none, read live from the opt-in state, not hardcoded, so it cannot testify falsely if a user later turns on anonymized usage collection.

What the user keeps

Full local inference on hardware they own, with no account and no connection to us during a single token of generation.

Authoring and rollout#

IT authors the deny-list in the admin console, which exports a .mobileconfig profile, then ships it through the same MDM workflow as every other managed setting. Starter presets cover regulated work (privileged legal, HIPAA-aligned healthcare, finance, and a read-only lockdown), each stating plainly what it denies. For getting Conifer onto the machines in the first place, see deploy across a team.

A pre-rollout test seam reads a policy from an environment variable, so enforcement is validated before any profile is pushed. Conifer consults it only when no managed profile exists, so it can never shadow a real MDM policy in production.

# Dry-run a policy locally before pushing it through MDM.
# Honored only when no managed profile is present.
CONIFER_ORG_POLICY=/path/to/policy.plist open -a Sage