9 MCP Security Best Practices to Control What AI Agents Can Access

On Monday your team approves a database MCP server for the analytics group. By Thursday, a contractor who left last month still holds an OAuth grant to the CRM's MCP connector, an update has quietly rewritten one of the server's tool descriptions, and an agent on an engineer's laptop is reading cloud credentials with a shell command no MCP control will ever see. MCP security best practices are the controls that limit what AI agents can reach and do through Model Context Protocol servers and the tools around them, and each one works by shrinking or checking the access an agent carries.

Most MCP security guidance is written for the people who build servers: how to validate a token, sanitize an input, or sign a release. Your job looks different. You're responsible for hundreds of engineers whose agents connect to servers someone else wrote, and the protocol leaves the hardest question to you: whose access each agent is using, and what checks it before a call runs.

In this article you will learn nine MCP security best practices that every team running AI agents should follow. Each one starts from the access an agent already holds, because every MCP attack worth worrying about ends with an agent using access somebody already granted. Every practice comes with the evidence behind it and a first step you can take this week.

1. Keep untrusted content and private data in separate MCP agent sessions

The most dangerous agent session is one that reads untrusted content, holds private data, and has a way to send it out. Each of those legs looks harmless on its own. Together they let anyone who can write text your agent reads borrow the access your agent holds.

Picture how that plays out in a support queue. Someone outside the company opens a ticket with instructions buried in the text, and a support engineer asks an AI assistant connected to the helpdesk's MCP server to summarize it. The assistant treats the planted text as part of the task, pulls internal records the engineer can see, and posts them back into the ticket thread, where the outsider reads the reply. The outsider never signed in to anything, because the engineer's access did all the work.

The per-call prompt won't catch this. We've found that coding agents are routinely run without permission checks, so the prompt that would have shown the engineer that write is often switched off. Netskope already uses Lumos to flag toxic combinations in its access reviews and route them to owners, and an agent session that reads customer tickets while holding internal data and write access is a toxic combination that lives for minutes.

Break the combination at the session level. Split agents that read outside content (tickets, issues, inboxes, and web pages) from agents that hold sensitive write access, and scope each session to one project or repository. Treat any write to a customer-visible or public destination after a private read as a call that needs a decision.

In practice, that usually means two agent setups where teams run one today. A triage setup reads tickets and issues with read-only connections and no access to internal data stores. A working setup holds the write access and internal data, and it picks up a task only after a person has handed it over, so planted text in a customer ticket never reaches the session that can act on it.

Start by listing the agents that read content from outside the company. Then check what else each one can write to.

2. Route MCP authorization and OAuth through your identity provider

Your identity provider should decide who can connect an agent to each MCP server. Standard MCP authorization asks each person to approve each server on a consent screen, and people pick the broadest scope so the integration works on the first try. That leaves the access decision to whoever clicks first.

Moving that decision to the identity provider puts MCP servers on the same footing as every other app you govern. An admin approves a server once, people get access through the groups and roles you already manage, and the conditional access rules that protect email and code apply to their agents too. Scope becomes a decision an admin makes once, which also makes it harder for someone to connect a personal account to a work tool by mistake.

Group-based MCP authorization is only as good as the path into the groups. If your identity governance software takes three days to add someone to the right group, engineers will paste a personal token and move on. ChargePoint shows the fast path is achievable: Lumos handles more than 80% of its access-request tickets across 70+ applications, approvals go to managers, and employees get access within minutes.

Plenty of servers can't hand sign-in to your identity provider yet. For those, use the app-approval controls most SaaS admin consoles already offer, so people can only authorize MCP clients an admin has approved, and ask for the narrowest OAuth scope the server accepts. A server that only accepts a pasted API key should run with read-only, non-production credentials until it offers something better.

The IdP has a limit worth naming. It decides who can connect and what a token can reach, and it can't see what an agent does with that token once it's issued, which is why the runtime check later in this list still matters. List the MCP servers your engineers use that can sign people in through your identity provider, and move those first.

3. Keep API keys, tokens, and cloud credentials out of AI agent reach

An agent can read every secret its user's shell can read, so a token pasted into a config file is a token the agent holds. The exposure reaches past MCP configs. API keys in environment variables and .env files, cloud CLI sessions, cluster contexts, and SSH keys all sit within reach of an agent that can run a command.

Each of those long-lived keys is a non-human identity that nobody reviews, and the ones pasted into MCP server configs tend to be the most broadly scoped. Many are service account keys, which turns MCP setup into a service account security problem the moment an agent can read them. They also undo your other controls. Block a database server, and a code-capable agent can reach the same data with a command-line client and a credential it found in the environment.

Lumos MCP Governance captures Bash commands and file edits alongside MCP calls, so a policy can stop an agent from reading a credentials file or dumping its environment. An MCP-only control never sees that call, because it never touches MCP.

Write those rules against paths and patterns: the cloud credentials file, cluster configs, the SSH directory, .env files, and commands that print the whole environment. Expect a little tuning in the first week. An engineer running the cloud CLI is ordinary work, and an agent reading the file the CLI depends on is the call the rule exists to stop.

The longer-term fix is fewer secrets on disk. Replace pasted tokens with OAuth through the IdP or the OS keychain, keep tokens short-lived, and give agents task-scoped credentials in place of an engineer's admin session. This week, search the MCP config files on engineering laptops for static tokens and rotate every one you find.

4. Sandbox local MCP servers and review every change to their config

A local MCP server is somebody else's code running with your engineer's privileges, and its config file decides what runs. Over the STDIO transport, the agent client launches the server as a process on the laptop, using the command and arguments written in that file. Whoever can write the file can run code as the engineer.

That file is easier to change than most teams assume. An engineer pastes a setup snippet from a README, a coding agent edits its own config while following instructions it read on a web page, or an unpinned package pulls a new version the next time the server starts. Each one runs new code with the engineer's access, often before anyone has read the command.

Take them at their word, because the sandbox is your job. Run local servers in a container with no host credentials, mount only the project directory each one needs, and deny network access unless the server has a reason to call out. Treat MCP config files as code: changes go through review, and nothing a web page or a pasted snippet writes into them runs until a person has seen the full command.

Reviewers should know what a risky launch command looks like. Watch for package runners pulling an unpinned latest version, anything piped into a shell, sudo, and arguments that point at home directories or SSH keys. Pin each package to a version in the config, so an update arrives as a reviewed change and never as a surprise on the next restart.

Then watch for drift. A new local server on one laptop is worth an alert, and so is an existing server whose launch command changed. Start by inventorying the local servers on your ten heaviest agent users' machines and checking which ones can read cloud credentials.

5. Vet remote MCP servers with the same third-party risk review as any vendor

A hosted MCP server is a vendor holding a live connection into your accounts, so review it the way you'd review any vendor with that reach. Most security teams already run a third-party risk process. Hosted MCP servers tend to skip it, because an engineer can connect one in a minute without a purchase order. A flaw in a vendor's hosted server is one of the MCP security risks you can't patch yourself, so the review has to happen before anyone connects.

The danger runs toward the laptop as well as the data. In July 2025, JFrog disclosed CVE-2025-6514, a critical flaw (CVSS 9.6) in mcp-remote, a package desktop agents use to reach remote MCP servers. A malicious or hijacked server could trigger OS command execution on the machine that connected to it, with full command control on Windows, until the fix in version 0.1.16. The researchers' advice was to connect only to trusted servers over HTTPS, which assumes someone decided which servers count as trusted.

The first question in any disclosure is who's exposed. Lumos MCP Governance shows every MCP server your agents call, including ones individuals connected without approval, with the person behind each call. The day a server or a client library discloses a flaw, finding the affected people becomes a lookup.

Bridge packages like mcp-remote sit in your supply chain whether anyone approved them or not. Where an agent client can connect to remote servers natively, prefer that over a bridge, and where a bridge is unavoidable, pin it and patch it like any other dependency on an engineer's machine.

Build MCP server security best practices into your vendor intake with five questions: how the server isolates tenants, what it logs and for how long, whether it lets your identity provider manage sign-in, how quickly it commits to disclose, and how you revoke every user's grant at once. Add hosted MCP servers to that intake this quarter, starting with the ones connected to customer data.

6. Expire AI agent OAuth grants when the work ends or the owner leaves

Agent connections outlast the work they were created for, and every idle one is access an agent can still use. Retiring those connections is the step AI agent lifecycle management most often skips, because nobody files a ticket when a project ends. Dormant connections come from finished work, such as an OAuth grant to an MCP client for a project that ended in March. Orphaned ones belong to people who changed teams or left, and their grants and refresh tokens keep working until someone revokes them.

Leaver workflows usually stop at the identity provider, and that's too early. Disabling a person's SSO account doesn't always revoke tokens an app issued directly, so offboarding has to reach the grants themselves. Mover workflows need to re-check agent connections the same way they re-check roles, because AI agent identity governance only works if an agent's access follows the person behind it.

Lumos Labs puts the stakes plainly: a permission that sits dormant for a person can be exercised thousands of times by an agent. Code42 runs the fix with Lumos, where time-based access for its most critical apps reduced privileged access 67%, and Christian Wimpelmann, its Manager of Identity and Access Management, describes least privilege as "the right employees the right access for the right amount of time." The same rule applies to MCP connections, on a shorter clock.

Finding the grants is the first job. Most SaaS admin consoles list the third-party apps and OAuth clients each user has authorized, with grant dates, and comparing that list with recent agent activity shows which connections nobody has used in weeks. Those are the ones to expire first.

Expiry works best alongside the two habits at the center of AI agent access management: a named sponsor for every agent, and just-in-time grants that end with the task. For MCP connections, write the expiry rule into your MCP governance policy. Start with a window for unused grants (30 days is a reasonable start), run it against current grants in report-only mode, and enforce it once owners have had a week to object.

7. Check every AI agent tool call at runtime, including shell and file actions

Agents act faster than anyone can review, so each tool call needs a decision before it runs, including calls that never touch MCP. Coding agents spend much of their time in built-in tools: they run shell commands, edit files, and drive browsers. A control that only watches MCP traffic misses all of it.

The volume settles the timing question. Across fewer than 200 employees, Lumos counted more than 450,000 agent actions in a single week, a pace no after-the-fact review can follow. Lumos MCP Governance puts a hook in front of every tool call that returns allow or deny before it runs, targeting under 50 milliseconds per check across MCP calls, Bash commands, file edits, and browser use, with no traffic rerouted.

Be clear-eyed about the hardest part. Agents that work through authenticated browser sessions reach apps without touching MCP, which leaves that activity invisible to MCP-only controls, and we treat browser use as one of the open problems in agent security. Your MCP governance policy should name that gap and every other place a control can't see, and give each one an owner and a compensating control, such as keeping browser agents away from accounts with admin rights.

Start with a short block list. Deletes against production, publishing or deploying, sending data to an external destination after a private read, reading credential paths, and any call to an approved server whose tool descriptions changed since you approved it all deserve a rule on day one.

Read the log-only week before you turn anything on. A rule that would have blocked a nightly build script needs a condition for that script's owner, and a rule that never fired may be aimed at the wrong path. Tune by person, group, and target until the would-have-blocked list holds only calls you'd want stopped.

Runtime checks also let you say yes more often. One customer held back an integration for its marketing team because too many people had access to the underlying tool, and that decision cost pipeline. Write your first three block rules from the list above and run them in log-only mode for a week before you enforce them.

8. Build an MCP incident response runbook that cuts off agent access in minutes

When a server goes bad, the number that matters is how many minutes it takes to cut every agent off from it. Disclosures don't wait for change windows, and an agent keeps calling a compromised server until something stops it. Write the runbook now, then time it.

‍

Scoping is the hard part of the first hour. Albus, the AI agent inside Lumos, answers questions about agent activity in plain language: which teams used the server, which calls carried the most risk, and what caused a spike. That turns an hour of log queries into a few questions.

The 15-minute step only works if it's wired before you need it. A deny rule that applies to every agent on its next call is your kill switch, disabling the server at the IdP covers every connection the IdP manages, and revoking grants at the app covers everything else.

Decide now who can pull that switch without a change ticket, and write their names into the runbook and your MCP governance policy. Blocking a server will interrupt somebody's work, and the on-call engineer shouldn't have to win that argument at 2 a.m. Run the first step as a drill this quarter against a server you'd be willing to block for an hour.

9. Measure MCP security controls with six metrics you can track today

Six numbers tell you whether your MCP controls work, and all six come from data you can collect today. An exposure count tells you how much risk you carry, while these tell you whether the controls are running.

‍

The approval rate is the one teams misread most often. When people are asked to approve dozens of agent calls a day, they stop reading the requests, so a rising approval rate usually means routine calls are reaching people when a rule should be deciding them. Move the routine cases into rules until each approval is rare enough to get a real look.

Certification is the one most teams can start on now. Sun Country has its privileged and managed service accounts fully certified in Lumos access reviews, with delta reviews that focus on what changed since the last cycle, and it saves 50 hours a quarter doing it. Agent connections belong in that same campaign, since AI agent access management treats every agent connection as access someone has to sign off on.

These numbers double as the core of an MCP security audit. Write each one into your MCP governance policy with an owner and a target, so an auditor sees controls that run on a schedule and the evidence that proves it. The first two also show where you stand in an MCP governance framework, since maturity comes down to how much of what agents do you can see and whether every call names a person. Report the first three to leadership next month, even if they look bad, because a baseline is the point.

Build your MCP threat model around the access each AI agent holds

Every MCP attack that matters ends the same way: an agent uses access someone already granted it. Most lists of security considerations for MCP start from attack names, and the names multiply every month. The access those attacks need stays the same, which makes it the steadier place to build a threat model.

We've argued since launching runtime controls for agents that agent security is largely an access problem, because the connections that make an agent useful are the same ones that make it risky. A person might delete one CRM record by mistake, and an agent working on the same access could delete a thousand in seconds. That's why the MCP security risks to rank first are the ones that reach the most access, whatever the attack technique happens to be called.

MCP security best practices are the other half of that map: the controls that take a piece of access away or check it at the moment it's used. Here are the nine practices above, the access each removes or checks, and a first step you can take this week.

‍

The table also tells you where to start. Pick the two threats your agents are most exposed to today, find the practices that cover them, and take those first steps before anything else.

Make every AI agent action pass an access check before it runs

Your agents already hold access. The open question is whether anything checks that access at the moment they use it.

So check it. Map your threats to access this week, pull the static tokens out of your MCP configs next week, and run the revocation drill before the quarter ends. Each step takes away access an attacker could borrow, and together they put a decision in front of every call your agents make.

The attack techniques will change every month, and the access behind every call is the part you control. To see every tool call your agents made this week and the person behind each one, book a demo of Lumos MCP Governance.

‍