Endpoint Discovery is not an enforcement surface — it does not block, modify, or proxy any traffic. For runtime enforcement on endpoint devices, see the Endpoint enforcement surface under Runtime.
What the script discovers
The Device Discovery script enumerates the local filesystem and installed-application registry to build a per-device inventory. Each item is reported with the application name, version, install path, and any AI-relevant configuration (e.g. the contents of a parsed MCP config file).
For each MCP server discovered, the script reports the server name, command/URL, and declared tool names — never the contents of any tool call or any secret values referenced in the config.
What the script does not do
- It does not read user files outside the well-known AI configuration paths.
- It does not capture browser history, cookies, or any session content.
- It does not capture the contents of prompts, messages, or model responses.
- It does not transmit secrets, API keys, or environment variables — when an MCP config references an env var, the variable name is reported and the value is dropped client-side.
- It does not install, modify, or remove any software on the device.
- It does not run as a daemon or scheduled task on the device. Re-discovery happens on the MDM’s schedule.
How the script reports back
Each run produces a single signed JSON payload that is sent to a TrustLens ingestion endpoint over HTTPS. Authentication is a per-integration Discovery Token that you generate when configuring the integration. The token is scoped to write only to the inventory of that integration and cannot be used to read or modify any other resource.
Add
posture.neuraltrust.ai to any egress allowlist that applies to your managed devices.
Supported MDMs
Other MDMs that can run signed shell or PowerShell scripts on a schedule (e.g. Jamf, Workspace ONE, Mosyle) are not pre-packaged today but can deploy the same script. Contact support for a packaged Library Item.
Prerequisites
Before deploying, make sure you have:- An MDM administrator account with permission to upload and assign device scripts in Intune or Library Items in Kandji
- A target device group containing the macOS and Windows endpoints you want to inventory
- Network egress from the device fleet to
https://posture.neuraltrust.aion TCP 443 - For Windows: PowerShell 5.1 or later (default on Windows 10/11)
- For macOS: macOS 12 (Monterey) or later
Step-by-step setup
1
Create the Endpoint Discovery integration in TrustLens
- In the TrustLens console, go to Integrations → Add integration
- Pick your MDM under MDM: Microsoft Intune or Kandji
- Give the integration a name (e.g.
Corp macOS fleet) - Click Generate Discovery Token and copy the value — it is shown once
- Download the script bundle for your MDM and platform combination
2
Configure the Discovery Token on the script
Open
discover.sh (macOS) or discover.ps1 (Windows) and set the DISCOVERY_TOKEN variable at the top of the file to the value you copied:- macOS — discover.sh
- Windows — discover.ps1
3
Deploy the script via your MDM
- Microsoft Intune — macOS
- Microsoft Intune — Windows
- Kandji — macOS
- Kandji — Windows
- Go to Intune admin center → Devices → macOS → Shell scripts → + Add
- Basics: name it
NeuralTrust Device Discovery (macOS) - Script settings:
- Upload
discover.sh - Run script as signed-in user: No (run as root)
- Hide script notifications on devices: Yes
- Script frequency: Every 1 day
- Max number of times to retry if script fails: 3
- Upload
- Assignments: assign to your target macOS device group
- Review + add
Intune runs macOS shell scripts via the Microsoft Intune Management Extension. The script needs root to enumerate per-user installs across all profiles on shared devices.
4
Verify ingestion in TrustLens
- Wait for the next MDM script execution window — for daily-scheduled scripts in Intune, this is typically within 8 hours; in Kandji it is within an hour
- In the TrustLens console, open the integration you created in Step 1
- The Last sync timestamp should update and the Endpoint Host count should increment as devices report in
- Open Inventory → Endpoint Hosts to see per-device discovery results
Token delivery options
Embedding the Discovery Token directly in the script is the simplest setup, but you have alternatives if your security policy requires the token to live outside the script body:Re-discovery cadence and bandwidth
Security considerations
- The script is signed by NeuralTrust. Verify the signature before deploying — Intune can enforce this automatically; on macOS you can verify with
codesign -dv discover.sh.signedor check the SHA-256 against the published value in the integration page. - The Discovery Token is scoped to write to one integration’s inventory only. It cannot read existing inventory, modify other integrations, or access the rest of the platform.
- Rotate Discovery Tokens when team members with MDM admin access leave — the integration page has a Rotate token action that invalidates the old value immediately.
- The script never writes to disk outside
/tmp(macOS) or%TEMP%(Windows), and cleans up after itself on exit. - All credentials and ingested device payloads are encrypted at rest.
- The script source is available for review on request — contact your account team.
Known limitations
Troubleshooting
No devices reporting after 24 hours
No devices reporting after 24 hours
- Check the MDM’s script execution log on a sample device:
- Intune (macOS):
/Library/Logs/Microsoft/Intune/IntuneMDMDaemon.log - Intune (Windows):
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log - Kandji:
Kandji.app→ Activity tab on the device
- Intune (macOS):
- Confirm the device can reach
https://posture.neuraltrust.ai/v1/devices/reportwithcurl -I(macOS) orInvoke-WebRequest(Windows) - Confirm the Discovery Token in the script matches the one shown on the integration page (or has not been rotated since deploy)
Device shows up but inventory is empty
Device shows up but inventory is empty
- The script may be running but failing to enumerate due to permissions. On macOS, ensure the script is set to run as root (Intune: Run script as signed-in user = No; Kandji: default for Custom Scripts).
- On Windows, running as the logged-in user instead of SYSTEM will miss installs in other user profiles. Switch to SYSTEM or schedule a per-user run for shared devices.
- Some endpoint protection products block unsigned PowerShell. Enable Enforce script signature check in Intune and confirm the signed
discover.ps1.signedis the file you uploaded.
MCP servers from a tool I use are not appearing
MCP servers from a tool I use are not appearing
- The script reads from a known list of MCP config locations. If your IDE or agent CLI uses a non-standard path, file an issue with your account team and we will add the path to the next script release.
- Verify the config file exists on the device by running
cat ~/.cursor/mcp.json(or the equivalent path) — if it is missing, no servers are declared.
Duplicate hosts appearing for the same device
Duplicate hosts appearing for the same device
- The script uses the device’s hardware UUID (macOS
IOPlatformUUID/ WindowsMachineGuid) as the stable host identifier. If a device was re-imaged, the new identity is intentionally a new entry. Archive the old host entry from the inventory page.
Script runs but Intune marks it as failed
Script runs but Intune marks it as failed
- Intune treats any non-zero exit code as failure. The Discovery script exits 0 on success and 2 on a non-fatal warning (e.g. one of many config files unreadable). Check the script log under
/Library/Logs/NeuralTrust/discover.log(macOS) orC:\ProgramData\NeuralTrust\Discovery\discover.log(Windows) to see the warning detail.