Overview & Getting Started

AI posture gives you a live inventory of the AI agents running on your organization's endpoints — what they are, which machines they're on, what they can reach, and how risky they are. A lightweight sensor deployed through your MDM scans each endpoint on a schedule and reports what it finds, so your governance team works from what is actually installed rather than from what people say they've installed.

This guide covers what AI posture does, the concepts you'll need, and how to get your first devices reporting.

What AI posture does

Once the sensor is running on an endpoint, MineOS:

Scans the device on a daily schedule for AI agents and the tools they can reach
Uploads the findings to your workspace
Identifies each distinct agent and the devices it appears on
Analyzes each agent's own configuration for vulnerabilities and produces a posture score
Cross-references each agent against your vendor, assessment, processing-activity, and data classification records to produce governance signals and a risk score
Classifies what each agent is used for, so you can see AI activity by function
Surfaces all of it on the AI posture page for review

Key concepts

The AISPM sensor

The AISPM sensor is the program that runs on each endpoint and performs the scan. It supports macOS, Windows, and Ubuntu, and you deploy it as a script through your existing MDM — there's no installer to repackage and no per-machine setup. See Deploy the AISPM Sensor to Your Endpoints.

The sensor reports only what it discovers about AI agents and their configuration. It records where a finding was located, not the contents of the files it inspected.

Devices and enrollment

A device is one enrolled endpoint. On first run, the sensor exchanges the enrollment token carried in your MDM package for a client certificate, and uses that certificate for every subsequent connection. Enrollment happens once per machine; after that the device is durably identified regardless of hostname changes.

In the AI posture page, the machine an agent was found on appears in the Device name column.

AI agents and detected tools

An AI agent is a distinct agent the sensor found on one or more devices. Because the same agent frequently appears across a fleet, MineOS tracks each agent once and records every device it was seen on.

Detected tools is the umbrella term for the capabilities an agent can reach — its tools, its skills, and any MCP servers it connects to. This is usually the most revealing part of the inventory: it's the difference between knowing an agent exists and knowing it can read your team's email.

Vulnerabilities and the posture score

Vulnerabilities are weaknesses found in an agent's own configuration — overly broad permissions, unsafe defaults, and similar issues. Each carries a risk level and a confidence value, and each subtracts from the agent's posture score.

The posture score answers: how well configured is this agent?

Governance signals and the risk score

Governance signals are a separate finding type. Rather than inspecting the agent's configuration, they compare the agent against the records you already keep in MineOS — your vendors, assessments, processing activities, and data classification results. A signal flags an agent tied to a vendor that was never approved, one with no corresponding AI assessment, one with no matching processing activity, or one whose detected tools reach data classified as sensitive. Each signal adds to the agent's risk score, which maps to a risk level of Very high, High, Medium, Low, or Very low.

The risk score answers: how exposed is your organization because this agent is running?

Vulnerabilities and governance signals use different severity scales and are always kept separate — an agent can be flawlessly configured and still be a governance problem, or vice versa. Both appear under the Issues tab.

Business purpose

Each agent is classified by what it's used for — software development, data management, IT operations, and so on — with a confidence value. This is what lets you answer questions like "how much of our AI activity is in engineering versus HR" without tagging anything by hand.

Scan cadence

Each device scans once per day, at a fixed time assigned to that device inside your workspace's scan window. Slots are spread across the window so a fleet doesn't scan all at once. The default window is overnight in each device's local time; contact your MineOS representative if you need a different one.

Getting started

Step 1: Confirm your workspace is onboarded

AI posture is enabled per workspace. If package generation returns a 409, the workspace isn't onboarded yet — contact your MineOS representative.

Step 2: Deploy the sensor to your endpoints

This is an IT task and needs access to your MDM. Deploy the AISPM Sensor to Your Endpoints covers it end to end — generating a package, pushing it through your MDM, and allowing the sensor through your network.

Start with a small pilot group before scoping to the whole fleet.

Step 3: Confirm devices are reporting

Devices enroll within minutes of the script running. Agents appear in AI posture after each device's first scheduled scan completes, so allow up to a day for the first results across a pilot group.

Step 4: Review your first findings

Open Governance → AI posture. The Agents tab lists every agent discovered across your fleet; the Issues tab lists the findings raised against them. Filter by Risk to triage, or by Business purpose to see where AI activity is concentrated.

Two things are worth doing on your first pass: look for agents whose vendor you don't recognize, and look at the Connected tools filter to see which agents reach systems holding personal data. Both are common starting points for an AI assessment.

A current inventory of the AI systems in use across your organization supports the risk-management and record-keeping obligations of the EU AI Act, and complements the records of processing activities required under GDPR Article 30.