Drata

Drata is an evidence destination, not an MDM: once an MDM inventory source (Jamf Pro or Iru) is connected, the platform pushes one record per managed device into a Drata Custom Connection on a schedule, so “AI usage on endpoints is monitored” becomes a continuously-tested control instead of quarterly screenshots. Shared concepts (the coverage model and what the evidence attests) are on the MDM installations page.

1. Create a scope-limited API key

In Drata, go to Settings → API Keys and create a key for this integration. Grant it only these Custom Connections scopes. It needs nothing else:

• List Custom Connections and Create Custom Connection: Speakeasy finds or creates the dedicated connection for you on connect.
• Create Custom Connection Data and Create and Update Custom Connection Data: the record uploads themselves.
• Delete Custom Connection Data: pruning departed devices and clearing an empty fleet.

The key is shown once; store it in your password manager.

2. Connect in the dashboard

1. Open Device Agent → MDM Integrations, then Connect on the Drata row.
2. Select your Drata region (us, eu, or apac), enter your Workspace ID (usually 1, find it under Settings → Workspaces), and paste your API key. Leave Custom Connection ID blank. Credentials are stored encrypted and are never shown again after saving.
3. Save. Speakeasy creates a dedicated Custom Connection named “Speakeasy Device Agent Coverage” with the correct record schema and discovers its resource: no manual API setup, and no way to get the schema wrong. Re-saving reuses the same connection rather than creating a duplicate.
4. Test connection, then enable it. New connections start paused: the flow is save, test, then enable.

Once enabled, evidence pushes hourly (skipping cycles where nothing changed). Each push is a complete snapshot: departed devices drop out of the record set automatically, and retries can never duplicate records.

Bringing your own connection? If you’d rather create the connection yourself (or already have one), paste its connection id into the field in step 2 and Speakeasy uses it instead of provisioning one. Create it with exactly this record schema (the record resource is created automatically with the connection; the integration discovers it):

curl -s -X POST https://public-api.drata.com/public/v2/custom-connections \
  -H "Authorization: Bearer <YOUR_API_KEY>" -H "Content-Type: application/json" \
  -d '{
    "name": "Speakeasy Device Agent Coverage",
    "providerTypes": ["CUSTOM"],
    "workspaceIds": [<WORKSPACE_ID>],
    "displayNameKey": "hostname",
    "schema": {
      "type": "object",
      "required": ["id", "serialNumber", "hostname", "assignedUserEmail", "agentActive", "agentAttestation"],
      "properties": {
        "id": { "type": "string" },
        "serialNumber": { "type": "string" },
        "hostname": { "type": "string" },
        "assignedUserEmail": { "type": "string" },
        "agentActive": { "type": "boolean" },
        "agentAttestation": { "type": "string" },
        "agentLastSeenAt": { "type": "string" }
      }
    }
  }'

The required list must stay exactly as shown. In particular, it must not include agentLastSeenAt. If required is omitted, Drata marks every property required, and records for devices whose agent has never reported (which omit agentLastSeenAt rather than fabricating a timestamp) fail schema validation on upload. The automatic provisioning gets this right for you.

3. Wire it to a control

In Drata, map the connection to a test on the relevant control (for example, your SOC 2 monitoring control). Phrase the test over agentActive: one device with no live agent fails the test and routes to an owner.

Each record states its own attestation strength in agentAttestation, and both values can appear in one push:

• "device": that machine’s own agent reported in, matched on hardware serial. agentActive means this device is running the agent.
• "user": matched on the MDM-assigned user’s email. agentActive means only that the assigned user runs the agent on some machine, which is strictly weaker.

A machine whose agent cannot read a hardware serial stays "user" even once your organization is on device-level matching, so the strength genuinely varies row by row. agentLastSeenAt is omitted entirely when no agent has ever reported, rather than sent as null or a zero timestamp.

If your auditor requires per-device attestation, phrase the test to require both agentActive = true and agentAttestation = "device". Testing agentActive alone accepts the weaker claim.