AgentArmorHQ
Sign in
If something went wrong

I installed a bad AI skill or MCP server: what to do in the first hour

Remove it, change the keys it could read, then look at what it did. Most of this takes minutes, and the order matters. You do not need to know yet whether it was really malicious.

1.Stop it

Remove the tool from the place it is configured, then fully quit and reopen your client. A running MCP server keeps running until the client restarts.

  • Claude Desktop: claude_desktop_config.json. On macOS it is in ~/Library/Application Support/Claude/. On Windows it is in %APPDATA%\Claude\.
  • Claude Code: .mcp.json in the project and ~/.claude.json. See the Claude Code MCP docs.
  • Cursor: .cursor/mcp.json in the project and ~/.cursor/mcp.json.
  • Skills: the skills folder in your home or project directory, for example ~/.claude/skills.
Shell
# Claude Code
claude mcp list
claude mcp remove <server-name>

# a skill is a folder: move it out, then restart
mv ~/.claude/skills/<skill-name> ~/Desktop/removed-skill

Before you delete anything, write down the tool name, version and where you got it. Keep a copy of its folder or config entry. You will want it for steps 3 and 4.

Removing a tool stops new activity. It does not undo what already ran, so keep going.

2.Change every key and token it could read

An MCP server or skill usually runs with your user account. Assume it could read anything that account can read, and change those secrets. Do this from a different device if you think your machine is still affected. The OWASP secrets management guide covers the general practice: revoke the old secret, issue a new one, update the places that use it.

Where they usually live:

  • The tool's own config. The env block of its entry in your MCP config, and any .env file in its folder.
  • Environment variables. Anything exported in ~/.zshrc, ~/.bashrc or ~/.zprofile, and .env files in your projects.
  • Cloud credentials. ~/.aws/credentials, ~/.config/gcloud, ~/.azure. For AWS, follow rotating access keys.
  • Git and package registries. Saved GitHub tokens and credential helpers (~/.git-credentials, ~/.config/gh/hosts.yml), and ~/.npmrc. See revoking npm tokens.
  • SSH keys. Private keys in ~/.ssh. Replace them and remove the old public key from GitHub and your servers.
  • Browser sessions. Sign out of important accounts everywhere so old session cookies stop working, then sign in again. Do this for email, GitHub, cloud consoles and password managers.
  • AI provider keys. Anthropic, OpenAI and similar keys in your env or in app settings.

Start with the keys that can spend money or change production: cloud, payment, then source control. Then do the rest.

This is not extra caution. In the Nx "s1ngularity" incident, the malicious packages collected credentials from the machine. Nx's advisory told affected users to rotate GitHub, npm and any other credentials that were in their environment.

3.Check what it did

You are looking for commands you did not run, files you did not change, and connections you did not expect.

Shell
# commands the shell ran (check the last few hundred lines)
tail -n 300 ~/.zsh_history
tail -n 300 ~/.bash_history

# what git recorded in the last two days, in every branch
git log --all --since="2 days ago" --stat
git reflog --date=iso | head -50

# files changed in your home folder in the last day
find ~ -type f -mtime -1 -not -path "*/node_modules/*" -not -path "*/Library/*" 2>/dev/null | head -100
  • Provider logs. Your GitHub security log shows new tokens, new SSH keys and repositories you did not create. AWS CloudTrail shows API calls made with your keys. Look for activity since you installed the tool.
  • Recent commits and pushes. Check each repo the tool could reach for commits, branches and workflow changes you do not recognise.
  • Things left behind. New entries in your shell startup files, ~/Library/LaunchAgents or crontab -l, and new lines in ~/.ssh/authorized_keys.
  • Your MCP config. Look for commands or URLs you did not add. In CVE-2025-54136, a trusted Cursor MCP entry could be changed to a different command without a new prompt.

For outgoing traffic, there is no history unless you already ran a monitor or firewall. A snapshot of open connections is the next best thing:

Shell
# programs with open connections right now (macOS and Linux)
lsof -i -P -n | grep ESTABLISHED

Finding nothing does not prove nothing happened. It means you have fewer open questions. Keep the new keys either way.

4.Tell your team

Do this in the first hour, not after you have finished investigating. Teammates may have installed the same tool, and your shared keys may be among the ones you just changed.

Send three things: the tool name and version, where it came from, and which shared secrets you changed. If there is an incident page for it, every one of ours has a plain-text brief you can paste into Slack or a ticket. For example, the team brief for the Nx incident. Browse the incident library to find the one that matches.

If the tool is not in our library, report it to the maintainer and to the registry it came from, such as npm or PyPI.

5.Check everything else you have installed

One bad install often means others came from the same place. List every skill and MCP server you run, and check each one the same way. Look at who publishes it, whether the version is pinned, and what access it asks for.

Make this a habit. The Amazon Q Developer incident was a trusted extension that shipped a bad release. AWS removed the version and told users to remove it and upgrade. Pinning versions and updating on purpose gives you a moment to check first.