How to secure tool access in an MCP hub. A practical six-step playbook for AI agent governance.

An MCP hub is the place every agent passes through on its way to the tools it actually changes things with. It is also the place every mistake an agent makes will land — the over-permissioned token, the payload that should have been scrubbed, the call that should never have been allowed to fire.

Getting an MCP hub stood up is easy. Securing it so it’s safe to put real agents behind is the part that takes work. Below is the six-step playbook we’ve seen hold up across teams that put agents into production — distilled into something you can hand a platform engineer Monday morning.

1. Inventory the tools each agent actually needs.

Skip the catalog. Open the activity log for one week of real traffic and list the tools each agent has called. The list is almost always smaller than what the agent has access to — often by an order of magnitude. The gap between “tools available” and “tools used” is the surface you’re about to take back.

If you don’t have an activity log yet, that’s step zero. Instrument the hub end-to-end before you tighten anything, or you’ll tighten the wrong things.

2. Give every agent its own non-human identity.

A shared OAuth grant, a service-account key pasted into a config, or a single bearer token reused across agents — all of these collapse to one identity at the hub. When something goes wrong, your audit trail will say “agent”, and that’s as far as the investigation goes.

Mint a distinct identity per agent, short-lived, scoped, and revocable. The identity should name the run: which harness, which team, which use case. Long-lived credentials should never touch the agent — the hub holds them and brokers each call on the agent’s behalf.

This is the foundation for the next five steps. None of the downstream controls — tool scope, payload policies, audit, drift detection — mean anything if you can’t tell two agents apart.

3. Constrain at the payload level, not just the tool level.

Tool on/off is necessary but not sufficient. Most agent misbehavior we’ve seen lives inside an allowed tool: the right tool called with the wrong arguments. A send_message to the wrong recipient. A drop_table against a production schema. A create_secret with a value the model hallucinated.

For every allowed tool, write down what the agent is actually expected to do with it. Then encode that as constraints on the payload: argument shapes, value ranges, allow-lists for recipients or resource IDs, fields that must be redacted before they leave your network, and fields the model isn’t allowed to see in the response.

The aim is to make the expected behavior the only allowed behavior. Most misuses then simply can’t be expressed.

4. Make every call replayable.

The hub is where every agent action becomes recorded fact. Write down five things on every call: the agent identity, the tool, the arguments, the policy bundle in force at that moment, and the verdict the policy returned. Add latency for good measure.

Replayability matters because investigations always run in the past tense. When a tool call lands somewhere it shouldn’t have, the question is never “what is the policy now?” — it’s “what was the policy when this fired, and would today’s policy have caught it?” You can only answer that if both the call and the policy in force at the time are written down.

Append-only is the right default. Signed evidence exports are what turn the trail into something audit and security teams can stand on.

5. Ship policies as code, review them in PRs.

Click-ops policy is fine for a prototype and a problem at scale. Once more than one person is writing policies, you need diffs, PRs, environments, and a deployment story — the same loop you already trust for the rest of your stack.

Put the policy bundle in the repo, next to the application code. Plan shows what changes — which tools open, which payload constraints tighten, which agents pick up the new bundle. Apply ships it, atomically, as one signed event in the audit trail.

6. Watch adoption and drift over time.

The set of tools an agent uses drifts. New tools get added to the catalog, old ones go quiet, the model finds creative combinations of arguments. None of this is bad on its own, but it all needs to be visible.

Track per-agent tool usage by week. Alert on the first appearance of a tool an agent has never called before. Alert on a sudden spike in deny verdicts — that’s often a sign the policy needs to loosen, or the agent needs to be redirected. Push the data into whatever observability stack you already run.

The endgame is a feedback loop. Adoption data informs the next tightening; the next tightening updates the audit trail; the audit trail funds the next investigation. The hub stops being a piece of infra you set up once and becomes a system that gets safer the longer it runs.

Where to start tomorrow.

If you’re standing up an MCP hub from zero, do them in order. Identity first, then scope, then constraints, then audit. If you already have a hub in production and you’ve been putting some of these off, start with whichever step has the largest gap between the policy you’d like to have and the policy that actually runs today. That’s almost always the payload step.

The expected behavior is the only allowed behavior. Everything else is a matter of where you put the work.