StepSecurity Dev Machine Guard: AI Agent and MCP Security Guide

StepSecurity Dev Machine Guard is an open-source Go tool that scans a developer machine for AI agents, MCP server configurations, IDE extensions, suspicious files, and package-manager risks. It is useful because modern AI-assisted development moves part of the software supply chain onto laptops: an agent can install a dependency, invoke an MCP server, execute a hook, or use credentials already available to the developer.

The right way to evaluate Dev Machine Guard is not as a replacement for EDR, MDM, or software composition analysis. It is a developer-tooling visibility layer. The community binary runs locally and can emit pretty terminal output, JSON, or HTML. The enterprise workflow adds fleet deployment, scheduled scans, policy, and telemetry. This guide covers what it detects, how to run it safely, how to interpret the output, and where its boundaries are.

What Dev Machine Guard actually does

The repository describes the project as a scan for AI agents, MCP servers, IDE extensions, suspicious files, and risky package-manager configurations. Its current detection catalog includes tools such as Claude Code, Codex, Gemini CLI, Kiro, GitHub Copilot CLI, Aider, OpenCode, Cursor Agent, Pi, Factory Droid, and Amp. It also checks configurations for MCP-capable clients, IDE extensions, local AI runtimes, and optional package ecosystems.

That scope matters. A conventional endpoint product may know that an editor is installed, while a dependency scanner may know what appears in a lockfile. Neither necessarily answers: which MCP servers are configured on this laptop, which AI agents are installed, which extensions are active, or which local package-manager settings can redirect downloads?

StepSecurity’s product page positions the tool as complementary to EDR and MDM. It is not a malware scanner and it does not provide general device-posture compliance. The useful mental model is an inventory and policy feed for the developer-tooling layer.

Why AI agents make the developer machine a security boundary

AI coding agents collapse several steps that used to be visibly separate. A developer may ask an agent to fix a failing test, and the agent can inspect the repository, choose a package, install it, run a command, and call an external tool. Each step can be legitimate, but each also creates an opportunity for an unsafe dependency, extension, hook, or MCP configuration to reach a privileged workstation.

StepSecurity’s January 2026 explanation connects this risk to credentials commonly present on developer machines: GitHub tokens, package-registry credentials, SSH keys, and cloud access. Independent coverage from Agent Wars likewise described Dev Machine Guard as an open-source scanner for AI agents, MCP configurations, IDE extensions, and suspicious Node.js packages. The point is not that every agent is malicious. The point is that organizations need to know which agent-facing components exist before they can decide what should be allowed.

A practical threat path looks like this:

Installation and first scan

For a single-machine community evaluation, use a release binary or build from source. The official repository documents platform-specific release assets and a source build that requires Go 1.26 or newer. The binary is intended to have no external runtime dependencies.

On Linux x64, the documented release flow is:

1curl -sSL https://github.com/step-security/dev-machine-guard/releases/latest/download/stepsecurity-dev-machine-guard_linux_amd64 \
2  -o stepsecurity-dev-machine-guard
3chmod +x stepsecurity-dev-machine-guard
4./stepsecurity-dev-machine-guard

Do not blindly pipe an installer from the internet into a shell on a sensitive workstation. Download from the official repository, inspect the release and checksum/signing process, pin a version for a controlled evaluation, and run the binary with an account that has only the access required for the scan.

For a source build:

1git clone https://github.com/step-security/dev-machine-guard.git
2cd dev-machine-guard
3make build
4./stepsecurity-dev-machine-guard

The default scan is designed for readable terminal output. For automation, prefer JSON:

1./stepsecurity-dev-machine-guard --json > dev-machine-scan.json
2python3 -m json.tool dev-machine-scan.json | less

Optional package scans can expand coverage but may increase scan time and output. The documented switches include --enable-npm-scan, --enable-python-scan, and --enable-brew-scan. Restrict the search area when testing a particular workspace:

1./stepsecurity-dev-machine-guard \
2  --search-dirs "$HOME/projects" \
3  --enable-npm-scan \
4  --enable-python-scan \
5  --color=never

How to read the results

Start with the summary rather than treating every finding as a vulnerability. An installed tool is not automatically unsafe. First classify each result into four buckets:

1. Known and approved. Record the owner, purpose, version, and expected configuration.
2. Known but over-privileged. Reduce tokens, filesystem access, network reach, or agent permissions.
3. Unknown. Identify who installed it and whether it is needed before allowing it into a managed baseline.
4. Flagged or suspicious. Preserve the report, isolate the component, rotate potentially exposed credentials, and investigate provenance.

JSON output is especially useful for CI or fleet processing. The README shows fields for AI-agent/tool inventory and summary counts, including MCP configuration and IDE-extension counts. Treat those fields as an inventory contract, not as a final risk score. A count of MCP servers tells you how many configurations exist; it does not prove that a server is malicious or that its permissions are safe.

For an initial review, ask these questions:

• Which agents can execute shell commands or write outside the repository?
• Which MCP servers are enabled, and what data or actions do their tools expose?
• Which IDE extensions can run code or load workspace files?
• Are package registries and authentication settings pointing to approved endpoints?
• Are there setup hooks, rules files, or binaries that appeared recently?
• Which findings are present on more than one machine, and who owns them?

Community mode versus fleet deployment

Community mode is the safer place to learn the data model. The repository documents pretty, JSON, and self-contained HTML output, plus scheduled-scan commands and an enterprise telemetry path. StepSecurity’s installation documentation describes a two-piece fleet architecture: a loader deployed through existing MDM or EDR, and a binary downloaded from GitHub Releases.

The documented loader flow verifies a signed version manifest, downloads the binary identified by that manifest, checks its SHA-256, and runs it only after verification. The documentation identifies an Ed25519 SSH signing key as the trust root. This is a meaningful supply-chain control because an organization is not forced to redeploy the loader for every binary update.

The same documentation says the agent does not collect source code, secrets, or personal data outside installed-tooling inventory. That is an important privacy claim to validate against your organization’s requirements and the exact telemetry configuration before enabling enterprise uploads. Local community scans are a good first step for teams that need to understand what would be collected.

Dev Machine Guard compared with adjacent controls

The distinction prevents a common deployment mistake: buying one more scanner and assuming it covers policy, malware, secrets, and device compliance. It does not. Use this tool to make the developer-tooling layer visible, then connect the results to existing identity, endpoint, and software-supply-chain controls.

A safer rollout plan for AI-assisted teams

Begin with a read-only inventory on a small group of developer machines. Include different operating systems and workflows: a terminal-heavy engineer, an IDE-focused engineer, and someone using local models or MCP servers. Export JSON reports and compare the findings with what teams believe they have installed.

Next, define an ownership baseline. Every approved agent, extension, MCP server, and package source should have an owner, a purpose, an update path, and a permission boundary. Do not block everything unfamiliar immediately; that creates shadow tooling. Instead, establish a review queue and a time-limited exception process.

Then connect inventory to least privilege. Use separate credentials for development, avoid long-lived tokens where possible, restrict agent write access to the repository, and require human review before actions that publish packages, change infrastructure, or access production data. For MCP specifically, review tool descriptions and server provenance as carefully as you review an OAuth application.

Finally, automate response. A JSON report can become a ticket, a policy check, or a fleet query. Keep the first policy narrow: block known malicious versions and disallowed registries, flag unknown MCP servers, and alert on drift in approved extensions. Expand only after measuring false positives.

Teams already designing controlled agent execution may also benefit from a verification-first guide to harness engineering, the GitHub Copilot SDK guide for agent applications, and the MCP stateless migration guide. These are complementary concerns: execution boundaries, application integration, and server architecture do not replace workstation inventory.

Common mistakes and debugging

The scan finds too much. Start with the default scan, then enable package scans one at a time. Use --search-dirs to avoid scanning unrelated home-directory content, and separate inventory from risk decisions.

The scan misses a tool. Check the project’s coverage catalog and version. Some tools are detected through known paths, configuration files, or package metadata. Run with --verbose, confirm the searched directories, and file a reproducible issue with the tool name and installation method.

JSON is polluted by progress output. Use the default quiet mode or --color=never; reserve --verbose for a separate diagnostic run. Save stdout and stderr independently when integrating with a parser.

A flagged package is treated as proof of compromise. A finding is an investigation signal. Confirm the installed version, provenance, file hashes, execution hooks, and whether credentials were accessible. If exposure is plausible, rotate credentials first and investigate second.

Enterprise deployment fails. Verify outbound HTTPS access to the documented StepSecurity API, GitHub, release-assets.githubusercontent.com, and telemetry endpoint. Confirm that the loader’s signature and checksum checks are permitted by endpoint controls. Windows fleets should evaluate the documented signed MSI path when PowerShell-based deployment is restricted.

FAQ

Is Dev Machine Guard an EDR replacement?

No. StepSecurity explicitly positions it as complementary to EDR and MDM. It focuses on the developer-tooling and software-supply-chain layer rather than general malware detection or device posture.

Does the community scan upload source code?

The tool is designed around local inventory, and StepSecurity’s documentation says the agent does not collect source code, secrets, or unrelated personal data. Still, review the current release, flags, and enterprise telemetry settings before adopting it for regulated environments.

Can it inspect MCP servers?

Yes. Its documented coverage includes MCP server configurations across several AI clients. That gives defenders visibility into what is configured; it does not, by itself, prove that every server is safe or that tool permissions are appropriate.

Who should use this guide?

Intermediate developers, platform engineers, and security engineers evaluating AI-assisted development controls. The commands are simple, but interpreting findings requires familiarity with endpoint identity, package provenance, credentials, and agent permissions.

Conclusion

AI-assisted development has made the laptop part of the application supply chain. Dev Machine Guard is valuable precisely because it does not pretend to solve every security problem: it inventories the agents, MCP servers, extensions, packages, and configuration files that other controls may overlook.

Use the official repository for a local, read-only evaluation. Validate the output, document ownership, reduce agent privileges, and integrate only the findings that map to a clear response. The strongest deployment is not “scan every developer and block everything.” It is a measured control loop: discover, verify, approve, constrain, monitor, and investigate drift.

Sources and visual credit

• StepSecurity Dev Machine Guard repository — official source for installation, commands, detection coverage, and release information.
• StepSecurity Dev Machine Guard product page — official product scope, deployment model, and control boundaries.
• StepSecurity installation documentation — official fleet architecture, signed manifest, checksum verification, network requirements, and data-collection notes.
• StepSecurity introduction — official threat model and rationale for developer-machine protection.
• Agent Wars independent coverage — independent description of the open-source scanner and its initial scope.

The Mermaid diagram is original to this article. Visual direction was informed by Superdesign’s VulnGuard AI SaaS landing-page reference, adapted into a text-rendered architecture diagram rather than copied artwork.

Visual: Security control path

This original threat-to-control diagram turns the security guidance in this article into a concrete sequence of gates.

Visual reading: security is layered. Blocking unsafe actions before execution is important, but allowed actions still need sandboxing, logging, and output validation.