Auditing Security on Your MCP and Agent Tool Stack

Before you write any rule, list every MCP server any agent in your environment can reach: internal servers you built, third-party servers you connected, and anything a developer wired up locally that later got promoted. For each one, record who registered it, what credentials it runs under, and when it was last reviewed. Teams that skip this step end up writing security policy for a system they cannot fully describe.

A spreadsheet is fine for this. The goal is a single place that answers "what can our agents touch" without anyone having to read source code to find out.

A tool named "read_customer_record" that was written to fetch a name and email can often also update fields, because the underlying API client wasn't scoped down when the tool was built. Read each tool's implementation, not just its description, and classify it as read-only, write, or destructive.

• Read-only: returns data, cannot change state.
• Write: creates or updates records the agent didn't originate.
• Destructive: deletes data, moves money, sends external communications, or changes permissions.

Destructive tools deserve a human confirmation step before an agent can call them in production, regardless of how well the model has behaved so far.

Ask each tool owner two questions: what does this tool do if it receives malformed input, and what does it do if the model calls it with a value that's technically valid but wrong, such as the right shape of customer ID pointing at the wrong customer. Tools that trust the model's output without validating it against real business rules are the ones that cause incidents.

Critical, internet-accessible vulnerabilities in the broader software supply chain are expected to be remediated within about 15 days under CISA's federal directives¹, and it's reasonable to hold your own agent-facing tools to a similar bar once a flaw in one is confirmed.

New MCP servers get added faster than most security reviews can keep up with, especially once individual engineers can register their own for a side project. Set a standing quarterly review where every registered server gets re-justified: who still uses it, does the access level still match the use case, and has the underlying API added new capabilities since the tool was written.

Tie new-server registration to the same review, so nothing goes live without at least a one-line answer to "what's the worst thing this tool could be told to do."

Manually re-justifying every tool connection works at ten integrations and breaks down at fifty. Continuous compliance platforms can automatically flag access grants that haven't been reviewed on schedule and keep an audit trail of who approved what, which matters as much for your own peace of mind as for a customer's security questionnaire.

Say a ten-person engineering team runs this checklist for the first time. The inventory turns up fourteen registered MCP servers, three more than anyone expected, because two engineers had wired up personal integrations during a hackathon and never told the rest of the team. Scoring each tool by capability finds one, a customer-notes editor, that can technically delete records even though nobody ever intended an agent to have that power; the underlying API client it was built on simply had broader access than the tool's stated purpose needed.

None of this required exotic tooling to find, just the discipline of reading each tool's implementation instead of trusting its name. The fix in this case was narrow: rescope the customer-notes tool to remove delete access and add the two hackathon servers to the regular quarterly review. That is usually what a first audit looks like: not a dramatic breach, but a handful of access grants nobody would have approved on purpose if they had been asked directly.