Does the agent read our API keys or database passwords?

It opens configuration files that may contain them, and takes only server names, package names and hostnames. Tokens, env values, arguments and paths are not kept, logged or sent. The agent's tests run its parsers over files full of fake secrets and fail if any of them appears in the report.

Can it block or remove an MCP server?

No. It reports what is configured. Approval status is a record for reviewers; nothing is enforced on the device.

Does it see MCP servers checked into a repository?

No. It reads user-level configuration only. Project-level files such as .mcp.json are not read.

Does it show what an agent actually did?

No. It shows what an agent is configured to reach. It does not observe tool calls, prompts or responses.

Yes, per organization, on the AI agents and MCP servers screen under Devices. It takes effect at each agent's next policy check.

See which AI agents can act on company systems, and what they are wired to.

A chatbot answers questions. An AI agent connected to an MCP server can read files, query a database or push code. GhostAudit's desktop agent lists the agent clients configured on each computer and the MCP servers they point at, so you can review them before something goes wrong.

Start 14-day trial

Example workspace. The AI agents and MCP servers view, with illustrative figures.

Devices/AI agents & MCP servers

Discovery on

Agent clients

Seen on 58 devices

MCP servers

Distinct, across devices

High reach

Files, code, databases

Not reviewed

No decision recorded

MCP servers

Names, packages and hostnames only. No tokens, arguments or paths.

@modelcontextprotocol/server-filesystemstdio · npx
Reads and writes files in the folders it is pointed at on the device.
Configured as “filesystem” in Claude Desktop, Cursor · 23 devices
High reachTo review
@modelcontextprotocol/server-postgresstdio · npx
Every table the database user can query, which may include customer or personal data.
Configured as “prod-db” in Cursor · 4 devices
High reachNot approved
api.githubcopilot.comhttp
Source code, issues and pull requests in every repository the token can access; can push changes.
Configured as “github” in VS Code, Claude Code · 41 devices
High reachApproved
mcp.linear.apphttp
Issues and projects in the connected workspace.
Configured as “linear” in Claude Code, Cursor · 17 devices
Medium reachApproved
acme-internal-toolsstdio · node
Not recognised. Review what it connects to.
Configured as “acme-internal-tools” in Cursor · 2 devices
UnrecognisedTo review

Agent clients recognised: 11
Reported per server: Name, package or hostname
Never reported: Tokens, arguments, paths
Refreshed: Every 6 hours

01Why it matters

The risk moved from what people type to what the assistant can reach.

The Model Context Protocol, MCP, is the common way AI assistants are connected to other systems. A developer adds a few lines to a configuration file, and their coding assistant can now read a folder, open pull requests, query the production database or post to Slack, with the developer's own credentials.

That is useful, which is why it spreads. It also means that the question "which AI tools do we use" is no longer enough. Two people can use the same approved assistant, and one of them has connected it to the customer database.

None of this shows up in a browser, a single sign-on log or a network proxy. An MCP server launched on the developer's own machine is a local process started by a configuration file. The place to look is the configuration file, and that is where GhostAudit looks.

One row per distinct MCP server, across every device it appears on
Which clients it is configured in, and on how many devices
A plain-language note on what a server of that kind can reach

Example workspace. Names and figures are illustrative.

Agent clients

Configured on enrolled desktops

Client	Devices	MCP servers
Cursor	34	9
VS Code	31	5
Claude Code	22	6
Claude Desktop	19	4
Windsurf	3	2

02What is read

Names, package names and hostnames. Nothing else from those files.

MCP configuration files are sensitive. They routinely contain API tokens, database passwords and file paths, so what the agent takes from them matters more than anything else on this page.

For each configured server the agent reports: which client it is configured in, the name the user gave it, the transport, and then either the launcher and package name (for example npx and @modelcontextprotocol/server-github) or the hostname of the server's address (for example mcp.linear.app).

Never read into the report: environment variables and their values, headers, tokens, any argument other than the package name, working directories, file paths, the address's scheme, port, path or query string, and credentials. The record the agent builds has no field that could hold them. A package argument that looks like a URL, a path, a git reference or a credential is dropped. The server validates every field again and discards anything that is not a plain name, package name or hostname.

Scope. The agent reads user-level configuration for the person signed in at the computer. It does not read per-project configuration or .mcp.json files inside repositories.

One thing to know. The server name is free text chosen by the user, and it is reported, cleaned to letters, digits and a few punctuation marks. Someone who names a server after a customer has put that name in the report.

You can see exactly what would be sent from a given machine with ghostaudit-agent inventory --dry-run. It prints the report and sends nothing.

A configuration file with made-up values, and the record built from it.

On the device~/.cursor/mcp.json

{ "mcpServers": {
    "prod-db": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://app:••••••@db.internal:5432/prod"],
      "env": { "PGSSLROOTCERT": "/Users/dana/certs/ca.pem" }
    }
} }

Struck through: read past and never kept. The record the agent builds has no field for arguments, connection strings, env values or paths.

What is sentPOST /api/fleet/inventory

{ "client": "cursor", "name": "prod-db",
  "transport": "stdio", "command": "npx",
  "package": "@modelcontextprotocol/server-postgres" }

One record per configured server. Print it yourself with ghostaudit-agent inventory --dry-run.

03Review

A hint about reach, and a decision on record.

GhostAudit recognises well-known MCP servers by package name or hostname and attaches a note about what a server of that kind can reach once someone has given it credentials: files on the device, source code, databases, mail and documents, cloud infrastructure, payments. Each is rated high, medium or low reach. Servers it does not recognise are shown as unrecognised, which is usually the more interesting list: in-house servers and one-off scripts.

The note is a hint for a reviewer, not a verdict. GhostAudit knows that a Postgres server is configured. It does not know which database it points at, because it never reads the connection string.

For each server you record a decision, approved or not approved, with a note. The list sorts unreviewed, high-reach servers to the top.

This is a record, not enforcement. Marking a server not approved does not remove it or stop it running. Nothing is pushed to the device. What you get is the list of devices where it is configured, so that someone can have the conversation.

More than twenty kinds of well-known server recognised, from filesystem and shell to CRM and payments
Approve or mark not approved, with a note; changes are written to the audit log
People are shown by name, as a count, or not at all, following your identity mode

One server opened for review. Device names and figures are illustrative.

@modelcontextprotocol/server-postgres

High reach

What a server of this kind can reach

Every table the database user can query, which may include customer or personal data.

Matched by package name. GhostAudit does not know which database it points at.

Device	Client	User	Last seen
NW-MBP-0412	Cursor	9f2c…e41a	Today
NW-MBP-0388	Cursor	51ab…07cd	Today
NW-LT-2207	Cursor	c80e…2b19	Yesterday

ApprovedNot approved

Production data must not be reachable from a coding assistant. Use the read replica with masked columns. Raised with the platform team.

A record for reviewers. Nothing is sent to the device and nothing is blocked.

04Coverage and limits

What is covered today, stated plainly.

Clients. Claude Desktop, Claude Code, Cursor, VS Code (including Insiders and VSCodium), Windsurf, Cline, Roo Code, Zed, Continue, Gemini CLI and Codex CLI.

Requirements. The desktop agent, version 1.1 or later, on macOS or Windows. The browser extension plays no part. Discovery is on by default once such an agent is enrolled, and an admin can turn it off for the organization on the same screen; reports that arrive while it is off are acknowledged and dropped.

Timing. A full snapshot shortly after the agent starts and then every six hours. A server removed from a configuration file is marked removed at the next snapshot.

What it does not see. Servers configured per project or inside a repository. Agent clients not on the list above. Remote agents that run entirely in a vendor's cloud and are configured in a web console. Whether a configured server has ever been used: the agent reads configuration, it does not watch tool calls.

Maturity. The file locations come from each vendor's documentation and are tested against fixture files laid out as on macOS and Windows; clients move these files between releases, so a new release of a client can go unseen until we update the agent. The desktop agent's installers are not yet code-signed, which affects how you roll it out; see security.

Specification

Discovery details

For the security review. The field list is the complete report.

Reported fields: Client, server name, transport (stdio, http or sse), launcher base name, package name without version, or hostname. Plus the time collected and the user, as your identity mode allows.
Never reported: Env values, headers, tokens, arguments other than the package name, working directories, file paths, URL scheme, port, path and query, per-project configuration.
File handling: Regular files up to 48 MB. A symbolic link is followed only when its target stays inside the user's home directory. Parsing runs with a timeout.
Server-side checks: Every field is validated again on arrival; anything that is not a plain name, base name, package name or hostname is discarded. At most 300 servers per report.
Schedule: At start, then every 6 hours, never more often than hourly.
Control: On or off per organization, under Devices. Approval decisions are records for reviewers and are not sent to devices.
Verify: ghostaudit-agent inventory --dry-run prints the report without sending it.
Plans: Included in every plan. See pricing.

FAQ

Questions

Does the agent read our API keys or database passwords?: It opens configuration files that may contain them, and takes only server names, package names and hostnames. Tokens, env values, arguments and paths are not kept, logged or sent. The agent's tests run its parsers over files full of fake secrets and fail if any of them appears in the report.
Can it block or remove an MCP server?: No. It reports what is configured. Approval status is a record for reviewers; nothing is enforced on the device.
Does it see MCP servers checked into a repository?: No. It reads user-level configuration only. Project-level files such as .mcp.json are not read.
Does it show what an agent actually did?: No. It shows what an agent is configured to reach. It does not observe tool calls, prompts or responses.
Can we turn it off?: Yes, per organization, on the AI agents and MCP servers screen under Devices. It takes effect at each agent's next policy check.

Find out what your coding assistants are connected to.

Start a 14-day trial and enroll the desktop agent on a handful of engineering machines. The first snapshot arrives minutes after the agent starts. No card is needed.

Start 14-day trial Talk to us See pricing