As I watched a 60-second clip of the 2005 DARPA Grand Challenge, one of the first self-driving car races, I realized it was the perfect visualization of the risks in how organizations are pursuing AI today. Driven by industry leaders racing to be first, organizations and individuals, myself included, are pursuing AI with reckless abandon.
The short answer to the permission side of MCP security risks is the standard early self-driving cars were held to. Before an AI agent or MCP server touches production, test it where a failure costs nothing: try the destructive prompt on purpose in a non-production environment, confirm the removed permission is really gone, then connect it to the business.
Racing in an Empty Desert
The analogy fits because of where those early tests happened. Twenty-one years before a self-driving Tesla brought two coworkers and me back from dinner to our hotel in Austin during SailPoint Navigate, early autonomous vehicles were racing through the Mojave Desert. The footage is striking: a small, well-barricaded crowd, then about 132 miles of open desert, which Stanford's team ultimately won with its car, Stanley. The worst possible outcome was the destruction of the machine itself and maybe a few bushes. It was as if the test was performed in the most pristine, isolated sandbox available.
In the physical world, risk is easier to assess. A car could crash into a crowd of people, and nobody wants that. In business, stories of AI deleting production databases can't be compared to the loss of human life, but for the companies affected, they are devastating. My point isn't to compare physical and digital risk. It's to highlight how carefully those early AI technologies were tested.
How We Connect Agents Today
Today, when I connect my Claude Cowork instance to the MCP servers for our CRM or our project tracker, I'm prompted with a set of permissions. I glance at the list, maybe uncheck a couple with "delete" capabilities, set a few to "prompt for permission," and then I start driving my digital AI car right through the downtown heart of our business.
For most of us, that permission screen is the whole security model. An MCP server lets an AI model call tools in another system, through an account and scopes someone granted once, and the model picks the tools based on your prompt. If a delete tool is on the list, only that screen stands between a misread instruction and a deleted record.
What I Did Not Test
As I flew home reflecting on this, I realized how much trust I had extended. Did I test a Claude prompt that tried to delete a landing page or a set of records in our CRM? No, I took it at its word that it didn't have the permissions. Did I connect to a sandbox environment first? No, I went straight to production. So far, as far as I can tell, nothing has gone wrong. But is it only a matter of time before I miss a permission setting and write a prompt that ends up misaligned with my intentions?
The MCP specification's guidance on tools says there should always be a human in the loop with the ability to deny tool invocations. A permission list I skimmed once is not that human.
The Mojave Test, Step by Step
Here is the Mojave Desert test as a checklist:
- Start in a sandbox tenant. Connect to a non-production instance first, with test records you can afford to lose. No sandbox? Start with a small pilot scope, the way a phased identity rollout begins with a pilot population.
- Grant least-privilege scopes. Only the scopes the job needs, read-only where possible: the least-privilege discipline (NIST SP 800-53 AC-6) already expected of human administrators.
- Deny destructive tools outright. Turn off delete, bulk-update and export tools rather than leaving them on "ask." A disabled tool is a control. A prompt you click through at five o'clock is a hope.
- Test a deliberately destructive prompt. In the sandbox, ask the agent to delete something it should not be able to touch, and confirm the system refuses, not just the model. That is the test I skipped.
- Require human approval for writes. Keep a person in the loop for anything that creates, changes or sends data, and log what was approved.
- Review the identity like any other non-human identity. Every MCP connection runs as an account or token with an owner, scopes and a lifespan. Inventory it, name an owner and include it in access reviews. Platforms such as C1 now extend governance to AI agents.
Promote only after all six pass, and retest whenever the server's tool list changes. What an agent should be allowed to do in the first place is a design question I take up in whether agent access should follow the job or the person.
Desert First, Boston Second
I think it's prudent for all of us to apply the Mojave Desert test to every agent, MCP server, and non-human identity we bring online. Did you take this great new technology straight into the twisted streets of Boston, or did you first test it extensively in an isolated, safe environment like the desert?
If you already have agents on the road, start by finding out which of your systems AI can touch. The Mojave test is one control, not a program; for the program, see why your AI governance program cannot wait for the experts.
Frequently Asked Questions
Is MCP safe to use?
MCP is as safe as the servers you choose to trust, the permissions you grant and the testing you do before production. The protocol connects an AI model to tools in other systems; the scopes and access controls behind those tools decide what it can do.