@hackzero/mcp

Beta. New software, pointed at production credentials. Read what it does below before you run it.

SOC 2 evidence collection that runs on your machine, with your credentials, inside the editor you already use.

Instead of taking screenshots of forty console pages, your assistant runs read-only commands against your own systems and files the output as audit evidence, with the exact command attached so your auditor can re-run it themselves.

Install

You need a key from your HackZero workspace: dashboard.hackzero.ai → Trust → MCP.

Claude Code

claude mcp add hackzero -- npx -y @hackzero/mcp@latest --token hz_pat_YOUR_KEY

Cursor, ~/.cursor/mcp.json

{
  "mcpServers": {
    "hackzero": {
      "command": "npx",
      "args": ["-y", "@hackzero/mcp@latest", "--token", "hz_pat_YOUR_KEY"]
    }
  }
}

Codex, ~/.codex/config.toml

[mcp_servers.hackzero]
command = "npx"
args = ["-y", "@hackzero/mcp@latest", "--token", "hz_pat_YOUR_KEY"]

Windsurf, Zed, Cline and Continue take the same command + args shape in their own config files.

The -y matters. Without it, npx stops to ask permission to install on first run, and your editor just sees a server that never starts.

You can use HACKZERO_TOKEN in the environment instead of --token if you'd rather keep it out of a config file.

Using it

Say "continue my SOC 2", or run /soc2. It works out where you are and does the next thing.

> continue my soc 2

  HackZero SOC 2 (beta) · Umami · Type 2 · 3-month window

  22 of 57 collected. Waiting on you:
    6 questions            ~4 min, here
    3 policies to sign     browser, ~5 min
    ClickHouse open to the internet   [critical] due in 5 days

It takes weeks, not one sitting, and that's expected. All state lives on the server, so a fresh session on a different laptop six weeks later picks up exactly where you left off. Nothing depends on the conversation.

Commands

/soc2            do the next most useful thing
/soc2:next       the single next action, and nothing else
/soc2:findings   what is blocking, and whose move it is
/soc2:draft      draft a policy for a control that needs one
/soc2:quarter    what has come due, and what is about to go stale
/soc2:help       what this can and cannot do, for your workspace

Plain English works just as well. The commands are shortcuts, not a separate interface, and every one of them starts by re-reading the server. Not every editor renders MCP commands, so if yours doesn't show them, ask for the same thing in a sentence.

The questions

Some of SOC 2 is facts about your systems, which is what the read-only commands are for. The rest is decisions only you can make: how often you review policies, how fast you fix a critical issue, where your policies live.

Those come up as multiple choice, in the chat, a few at a time. Most take a few seconds.

It will not answer them for you, and that is deliberate rather than cautious. Your answers are what the policy drafts are written from, so a guessed answer doesn't stay a guess: it becomes a sentence in a document you sign, in your name, that nobody will ever notice is wrong. An unanswered question is a to-do the platform keeps showing you. A wrong answer is silent forever.

If a question doesn't fit any of the choices, you can answer in your own words. If you don't know yet, skip it.

What it does to your machine

Fair question before running an unknown package against production credentials.

• Runs read-only commands only. Describe, list, get. Never create, modify or delete.
• Asks first. Your editor prompts before anything executes, and the assistant explains what it's about to run and why.
• Reads your repo locally. Your source never leaves your laptop. Only command output for a specific control is uploaded.
• Uses credentials you already have. Your aws, gh, gusto logins, on your machine. We never receive them and never call those APIs on your behalf.
• Runs on your subscription, not our bill.
• Uploads output exactly as captured. Nothing rewrites it on the way in. That is what makes it acceptable audit evidence, and it is why the commands are configuration reads (aws iam list-users, gh api user) and never anything that prints a secret value.

The key is scoped to one workspace and to SOC 2 only. It cannot read your pentests, open pull requests, or reach any other workspace.

What gets stored

Every artifact carries six fields, because that's what our CPA requires for command output to be acceptable audit evidence:

command      aws s3api get-bucket-encryption --bucket umami-events
output       complete and unedited, stdout + stderr
executed     2026-08-25T14:03:22Z
identity     the account your key was issued to
exit code    0
sha256       9f2a1c…

Output is never truncated. A shortened output is an edited output, and an edited output isn't acceptable evidence.

Identity is the account, not the person at the keyboard. It comes from your API key, server-side. There is deliberately no self-reported operator name: a field an auditor can't rely on is worse than a missing one, because it invites reliance. The machine's hostname is recorded separately, and is labelled as self-reported wherever it's shown.

Failed collections are recorded too, with the same command, exit code, timestamp and hash. A command that couldn't run is not a failed control, and it's kept apart from your evidence so it can never satisfy one. It's there because "show me a collection that didn't work" is a fair question and we should be able to answer it.

What it won't do

This matters more than the feature list.

• It won't record a gap it didn't observe. If hcloud isn't installed, AC-14 hasn't failed for Hetzner. It just couldn't look. It says so and asks for a screenshot. Inventing a finding is as damaging in an audit as inventing a pass.
• It won't submit output it didn't capture. No relaying or summarising another tool's response. The model chooses what to run; the server captures the bytes.
• It won't manufacture evidence for things that have to actually happen. A penetration test, an incident response drill, staff completing training, a quarterly access review. It tells you what needs doing instead.
• It won't answer a setup question for you. It shows you the choices and waits.
• It won't sign anything for you. Signing is a legal act. It hands you a link.
• It won't write a statement you didn't make.

A couple of controls can only be proved by a picture of a screen that no CLI exposes, so there is no command to run and it doesn't pretend otherwise. It hands you a link straight to that control with a line on what to capture. Handing you a link is the finished version of that job, not the tool giving up.

Troubleshooting

"Could not start". The key may be revoked, expired, or for a different workspace. Issue a new one from the MCP tab.

A CLI you have installed reports as missing. It checks PATH plus the places tools actually install into (~/.gusto/bin, ~/.local/bin, /opt/homebrew/bin). If yours lives somewhere else, add it to PATH.

Nothing appears in your editor. Confirm -y is in the args, then restart the editor. Most hosts only read MCP config at startup.

The /soc2 commands don't show up. MCP prompts are supported unevenly across editors. Nothing depends on them: ask for the same thing in a sentence and you get identical behaviour.

MIT · hackzero.ai