Connect Claude to a Security Tool: Step-by-Step Build

Architecture diagrams are comforting, but at some point you have to open an editor and actually connect Claude to a security tool that can hurt you if you get it wrong. This post is the hands-on version: a step-by-step build that starts with a read-only integration against a vulnerability scanner and ends with gated, audited remediation. I will use a generic CSPM-style scanner as the example, but the same steps transfer to an EDR, a SIEM, or a compliance platform.

The build is deliberately incremental. You will have something safe and useful after step three, and every later step adds capability without rewriting what came before. That ordering is not just pedagogical — it is how you should actually ship this in a regulated environment, proving each layer before granting the next.

Step 1: Scope the integration before writing code

Start by writing down, in plain language, the exact questions and actions you want Claude to handle. Be specific: "list critical findings for internet-facing assets," "summarize a finding and its remediation steps," "open a Jira ticket for a confirmed issue," "suppress a false positive with a reason." This list becomes your tool surface. Anything not on it should not exist as a tool — the smallest possible surface is the most defensible one.

Then classify each action as read or write, and each write by blast radius. Reads are almost always safe to grant immediately. Writes split into low-risk (open a ticket), medium-risk (suppress a finding), and high-risk (trigger an automated remediation). You will gate these differently. Writing this table first means your code has a clear target and your security reviewer has something concrete to approve.

Step 2: Build a read-only MCP server

Create a small MCP server whose only job is to expose read operations against the scanner. Give it two or three typed tools to start: list_findings(severity, exposure), get_finding(id), and get_asset(id). Each tool validates its inputs, calls the scanner's API using a credential read from the server's environment, and returns a normalized, typed result — not the raw vendor payload. Normalization matters: you want Claude to see a stable shape so your skills and prompts do not break when the vendor reshuffles their JSON.

Keep the credential scoped to read-only at the source if the vendor supports it. Defense in depth means the API token itself cannot write, even if your server had a bug. Add a per-tool rate limit and a hard cap on result size so a vague query cannot pull the entire findings database into context. At this point you can connect Claude to the server and start asking real questions. You now have a useful, low-risk security assistant.

flowchart TD
  A["Define tool surface & risk table"] --> B["Build read-only MCP server"]
  B --> C["Connect Claude & test queries"]
  C --> D["Add triage skill"]
  D --> E{"Add write tools?"}
  E -->|Ticket| F["Low-risk write, log only"]
  E -->|Suppress/remediate| G["Gate: require approval token"]
  F --> H["Append-only audit sink"]
  G --> H
  H --> I["Review trail & expand"]

Step 3: Add a triage skill

The read-only server tells Claude what it can fetch; a skill tells it how you want findings triaged. Create a skill folder with a markdown instruction file describing your severity logic, what "internet-facing" means in your environment, which finding categories are usually false positives, and the format you want summaries in. Add a small script if you have deterministic enrichment — for example, cross-referencing an asset ID against an ownership table.

This is the step where the assistant stops being generic and starts sounding like your team. Without the skill, Claude gives competent but generic security advice. With it, Claude applies your playbook: it knows your crown-jewel systems, your escalation thresholds, and the phrasing your tickets need. Version this skill in Git so changes to your triage policy go through review — that history is itself audit evidence.

Step 4: Introduce the first write, behind an audit log

Now add the lowest-risk write: opening a ticket. Extend the server with create_ticket(finding_id, summary, severity). Before it does anything else, this tool writes an append-only audit record: session identity, finding id, the proposed summary, and a timestamp. Only after the record is committed does it call the ticketing API, and it writes a second record with the result. The audit log is not optional decoration; it is the first line of the function body.

Even though opening a ticket is low-consequence, threading it through the audit sink now means the plumbing is proven before you add anything dangerous. Test that you can reconstruct the full story of a ticket from the log alone, with no access to the model transcript. If you cannot, fix the logging before going further — this is exactly the capability an auditor will ask for.

Step 5: Gate the dangerous writes

For suppression and remediation, the audit log is necessary but not sufficient; you need a gate. Implement the gate as deterministic code that runs before execution and decides among allow, deny, and require-approval. A clean pattern is to make high-risk tools require an approval token in their arguments. When Claude proposes remediate(finding_id) without a token, the gate returns a structured response: "approval required, here is what will happen." A human reviews the proposed action and supplies the token, and only then does the tool execute.

This turns the model into a proposer and a human into the approver for exactly the actions that warrant it, while leaving low-risk work fully automated. Crucially, the gate's logic lives in code you control, not in a prompt. A prompt can be talked around; a function that checks for a valid, single-use approval token cannot. Log every gate decision, including denials and the rationale, so the trail shows not just what happened but what was prevented.

Step 6: Validate, then widen

Before declaring victory, run an adversarial pass. Ask Claude to do things outside its scope — delete a finding you never gave it a tool for, remediate without approval, pull more results than the cap allows — and confirm each attempt fails cleanly and is logged. Try a confusing multi-step request and verify the gate still fires on the dangerous sub-step. This is your evidence that the controls are real, not aspirational.

With one tool fully proven — read, triage, ticket, gated remediation, complete audit trail — you widen by repetition. Add the next security system as its own MCP server, reuse the gate and audit sink, and extend the skill. The build never gets harder than the first one; you have already solved the hard parts once. That is the payoff of doing step one through six properly.

Frequently asked questions

How long does a first integration realistically take?

A read-only integration with two or three tools and a basic skill is often a day or two of focused work, because MCP servers are small and the hard thinking is in scoping. The gating and audit layers add more time but are reusable across every subsequent tool. Budget the bulk of your effort for the first integration and expect the second to be dramatically faster.

Should the approval token be human-supplied or system-generated?

For high-risk security actions, a human-in-the-loop approval is the safer default early on. As you build confidence, you can let a separate, well-audited system mint scoped, single-use tokens for specific automated playbooks. The key invariant is that the token is verified by deterministic code in the gate, is single-use, and is recorded in the audit log along with who or what authorized it.

What do I do when the scanner's API changes shape?

That is exactly why the MCP server normalizes results into your own stable types. When the vendor changes their payload, you update the server's mapping in one place and everything downstream — skills, prompts, the model's expectations — keeps working. Without that normalization layer, a vendor's minor release can silently break your agent's behavior.

Can I skip the skill and just put instructions in the prompt?

You can for a quick prototype, but you will regret it at scale. A skill is versioned, reviewable, and loaded only when relevant, which keeps your context lean and your triage policy auditable. Inline prompt instructions are invisible to review, bloat every request, and tend to drift. Promote anything that encodes real policy out of the prompt and into a skill early.

Bringing agentic AI to your phone lines

CallSphere applies this same build-it-safely discipline to voice and chat — agents that connect to your tools, act through gated, audited operations, and handle calls and messages 24/7. Watch the pattern in action at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.