Security & governance
Posture attestation
A managed install writes what it actually is to a file your EDR reads. No server, no callback, no Conifer in the loop.
No IT team hands a fleet a local model runtime on faith. They want to know what each Mac is running, whether the build is signed, whether it is past its expiry, and what the org policy has turned off. Endpoint tooling already scans for stray quantized weights and flags them as shadow software. Attestation answers that scan: a governed install drops a structured posture document the tooling collects and reads, so the runtime reports itself instead of reading like contraband.
The posture document
The document is one JSON file, schema version 1, assembled from state the app already holds: the baked expiry, the org-policy status, and the live telemetry preference. One builder produces both the file the tooling collects and the readout the admin previews, so the two cannot drift apart.
| Field | What it carries |
|---|---|
bundle_id | The install identity the tooling keys its collection on. |
app_version | The running version, straight from the binary. |
expires | The build’s baked expiry, RFC 3339. Past this date the binary refuses to run, so a fleet cannot drift onto an abandoned build. |
release_signed | True only when the real release key signed this build. A dev build reports false, honestly. |
managed | Whether an MDM profile governs this Mac, plus the policy fingerprint and the restriction tokens it declares. |
telemetry | The live opt-in state: none on a default install, opt-in-enabled once a user turns collection on. Read from the actual preference, never hardcoded. |
signature | Reserved for a detached build-key signature over the document. Null in v1. |
The fingerprint is a stable content hash of the policy, not a cryptographic seal. IT matches it against the profile they pushed to confirm the machine is running the policy they think it is.
How it gets collected
Writing the file is opt-in at launch, not a background behavior. The MDM launch policy arms an environment variable, CONIFER_ATTEST, set to the path the app writes to. At startup the app writes the document there once and carries on. The path comes only from the environment. Nothing inside the studio can choose it, and an unarmed launch (every consumer launch) writes nothing at all.
# Arm the beacon at the well-known collection path, then launch.
CONIFER_ATTEST="/Library/Application Support/build.conifer.desktop/posture.json" \
open -a "Sage"Collection is whatever file-gathering your tooling already does. A Jamf Extension Attribute, an osquery table, or any policy that reads a path off disk picks up the document on its own schedule. The recommended target sits under group-readable Application Support, so an agent reads it without elevating into the app.
- The app
- Writes one file when armed. Never opens a socket to do it.
- Your tooling
- Reads that file on its own cadence and rolls it up however you already roll up endpoint data.
- Conifer
- Is not contacted. There is no beacon endpoint and no callback. The collection path runs entirely between the Mac and your fleet tooling.
Same serverless shape as the rest of fleet governance. For how the binary and the MDM-pushed policy fit together, see MDM policy & the expiring binary. To read this same document in-app, see the admin console.
What it proves, and what it does not
Attestation is governance, not DRM. The report stays worth trusting only because it is precise about that boundary. The line:
| Claim | Holds? |
|---|---|
| A Conifer-signed build is reporting its own posture honestly. | Yes, as far as a signed binary is trustworthy. |
| The policy fingerprint matches the profile your MDM pushed. | Yes. A mismatch means the machine is not on the policy you think. |
| The telemetry line reflects the live opt-in, not a constant. | Yes. An install that opted in testifies so, never a false 'none'. |
| The document is cryptographically signed and tamper-proof. | No. A detached signature is reserved, null today. |
| Conifer enforces the policy on the device. | No. Your MDM owns device-level enforcement. |
The honesty rule
The telemetry line cannot drift into a false privacy claim. Only the exact marker the opt-in setter writes reads back as enabled; an absent, empty, or tampered mirror falls through to none. The one lie that would matter, reporting none while collection is on, takes deleting a file the setter rewrites on every toggle. The document carries the same local-first guarantee the settings panel shows on screen, up to the fleet, written once rather than read off a panel.