This guide explains what MCP Governance puts on a managed device, what data it collects, how identity is established, and what it does and does not prevent. It is written for a security reviewer.

​

The MCP Governance security model

To deploy this across a fleet, see MCP Governance: Deployment.

​

What is installed on the device

Nothing from Lumos is installed. Two things are written:

1. A device token at /Library/Lumos/device-token, written by the enrollment script.
2. A hook config, pushed by your MDM as managed settings for the agent (e.g. Claude Code, Codex, Copilot).

The hooks themselves are a curl invocation. There is no daemon, no kernel extension, and no background process.

​

What is captured

On every MCP tool call an enrolled agent makes, two requests reach Lumos: an access check before the call runs, and a log entry after it. Each event carries the person’s identity, the MCP server, the tool name, session and call identifiers, a timestamp, and a summary of the tool’s arguments. Tool arguments are captured by default. Arguments can contain sensitive data — a query, a message body, a file path. Two controls:

• Append ?capture=none to the hook config URL and arguments never leave the device. Policies that match on tool input will then never match.
• Argument capture can also be disabled on the Lumos side. Contact Lumos if you want it off without changing your MDM profile.

Contents of prompts, model responses and conversation transcripts are not captured.

​

Where the data goes

Events are stored in Lumos infrastructure within the Lumos AWS environment. No new third-party processor is introduced by this product. Event data is queryable by your admins in the Lumos UI and via the Lumos API for SIEM ingestion. Retention is configurable. Contact Lumos if you have a specific retention requirement.

​

How a tool call is attributed to a person

Attribution determines whether your policies apply to the right person.

• On the MDM path, the device is bound at enrollment to the stable_identifier in your inventory — an Okta user id or Entra object id. The binding comes from your MDM and your IdP, not from the machine. A user cannot change it.
• On the per-user install path, the install page issues an enrollment token scoped to that one person, and the email the agent reports comes from its own local config file in the user’s home directory — which that user can edit. The same user can also remove the hooks, since they installed them.

Use MDM deployment if you intend to enforce anything per person. The per-user path is for proofs of concept and pilots, where the point is to see what your agents are doing rather than to stop them.

​

The token model

Only a Lumos admin can create a fleet enrollment token, and a single token enrolls as many devices as you need — bounded by your inventory. Revocation is per device and immediate. If a laptop is lost or stolen, revoke that device on the Devices tab and its token stops working at once — no effect on any other machine, no need to re-mint anything or re-enroll the fleet. The same action covers offboarding. Revoking an enrollment token does not affect devices it already enrolled. The device token is a file on disk that a user with local administrator rights can read. It is scoped precisely so that this is survivable: holding it lets a machine log its own tool calls, and nothing else.

​

Unexpected devices

A machine that tries to enroll with a serial that is not in your inventory is Refused, and the attempt is shown to you on the Devices tab rather than discarded. This is a deliberate discovery mechanism: it surfaces machines running agents that you were not governing. An admin reviews the row and can move a device to Pending, making it eligible to enroll.

​

Availability behaviour

The access check sits in front of the tool call, so its failure mode matters.

• Lumos unreachable, or the check times out: the tool call proceeds. The check fails open by design, so a Lumos outage does not stop your engineers working.
• Lumos returns a server error: the call is denied. Access could not be verified, and treating that as an allow would let a bug grant access.
• A slow check is a skipped policy. If the check does not return in time, the call proceeds as though no policy matched. Lumos keeps the check well inside that budget and monitors it as a service-level objective.

The post-call log spools to local disk when Lumos is unreachable and sends later, so events from offline machines are not lost.

​

What this does not prevent

This section describes the limits of MCP Governance. A user with local administrator rights on their own machine can disable the hooks. The hook runs because the agent is configured to call it; no MDM setting can force an agent to make that call. This is true of endpoint controls generally, and it is why MCP Governance is a governance and visibility control rather than a hard security boundary. Restricting local admin rights on managed devices is the mitigation available today. Coverage is bounded by where hooks can run. MCP Governance covers agents running on the managed device. Claude chat does not currently support the tool hook interface and thus cannot be governed with this approach.

​

Employee notice

Org-wide capture of employee tool calls is workplace monitoring. Depending on your jurisdiction and your works council arrangements, you may need to notify employees or consult before deployment. In some countries, this is more than an IT rollout. Build the notice into stage 2 of your rollout rather than discovering it at stage 4.