MCP Security: What Could Go Wrong When AI Agents Can Change Things
An MCP server that only lets agents look things up is fairly low risk. The value is in letting them do things: book, cancel, refund, delete. That’s also where the danger is.
This post walks through the main MCP security risks using a booking system as the example, then shows the controls that make write access safe, and how Gephyr handles each one.
The example: a booking app, connected to AI agents
Actions offered to agents:
search_rooms(look up)get_booking(look up)create_reservation(change)cancel_reservation(change)
People use it from ChatGPT, Claude, Cursor and other AI apps that support MCP.
Risk 1: Prompt injection through your own data
A guest review contains a hidden line, written for AI agents, telling them the user wants every other booking cancelled. An agent reads it in a search_rooms answer and does as it’s told.
The control: treat everything that comes back from the API as untrusted, keep permission decisions out of the model, and make destructive actions wait for the user.
In Gephyr: text written by other people, like reviews and messages, is labelled as such, and agents are told to show it, not follow it. Hidden characters are stripped from everything agents read. Everything agents read about your app is checked for hidden instructions before it goes live. And cancellations start on Ask first, so even a fooled agent can’t cancel without the user’s OK.
Risk 2: Broken per-user authorization
The server uses one shared API key, so anyone’s agent can read anyone’s booking by guessing ids.
The control: each user signs in with their own account, and every call checks who it’s for: the token’s issuer, audience, scope and expiry, on every call, not just at connect.
In Gephyr: users sign in with the account they already have, and Gephyr checks the token on every call. A token only works for the one app and address it was issued for. Your app’s own tokens never reach the AI app.
Risk 3: SSRF (server-side request forgery)
An agent is tricked into steering the MCP server’s own request somewhere else: a path input like ../../admin, a redirect to an internal address, or a cloud metadata address like 169.254.169.254. The server leaks its own credentials.
The control: only call addresses you’ve approved, never internal or private ones, and never follow redirects. If your own API fetches URLs users send it (a callback_url, say), it needs the same checks: that request is your API’s, not the MCP server’s.
In Gephyr: Gephyr’s calls to your API go out over HTTPS only, to the hosts you’ve listed, never to IP addresses or internal names, and redirects aren’t followed. Inputs placed in a URL path are always encoded, so ../../admin stays a harmless string. A URL your API receives as an input is passed on like any other value, so your API checks where it fetches.
Risk 4: One customer’s data reaching another
In a platform hosting many apps, a routing bug lets one app’s users reach another’s.
The control: keep every app, token and approval tied to exactly one app.
In Gephyr: sign-in tokens are tied to one app and one exact address. Approvals are tied to the app, the action, the exact inputs and the user: an approval issued in one app is refused by another.
Risk 5: Runaway agents
A background agent retries a timed-out booking all night and makes dozens of duplicate reservations.
The control: limits per user, protection against repeats, and never retrying something that might already have happened.
In Gephyr: each user’s agent can use each action only so many times a minute and a day, and the same change sent twice within seconds goes through once. An approval works exactly once. If Gephyr can’t tell whether an approved change happened, it says so and never tries again on its own. Your dashboard lists those for you to check.
Risk 6: Leaked credentials
Upstream keys turn up in tool answers, logs or error messages.
The control: keep secrets encrypted and out of everything agents and logs see.
In Gephyr: your users’ tokens for your app are encrypted and only used for the moment of a call. Logs record a pseudonymous user id, never tokens or what your API returned. When your API refuses a call, the agent gets the reason, with the user’s token taken out. Sign-in errors, server errors and HTML pages give the agent only the status.
MCP security checklist for write access
| Control | Why it matters |
|---|---|
| Offer only the actions you choose | Nothing is exposed by accident |
| Ask first for high-impact actions | Limits what prompt injection can do |
| Per-user sign-in, checked on every call | No reading other people’s data |
| Validate every input against its schema | Rejects malformed or malicious input |
| Approved outbound hosts only, and your API checks URLs it fetches | Blocks SSRF |
| Limits and repeat protection | Stops runaway agents |
| Approvals that work once | No double bookings |
| Secrets kept out of answers and logs | Contains leaks |
| A way to switch it off | Stops incidents fast |
Can prompt injection be fully prevented?
No. Today’s defences reduce it, but nothing removes it entirely. The realistic aim is that when an agent is fooled, the damage is small, visible and reversible: it can only do what the user could, and anything that matters waits for their OK.
Frequently asked questions
Does the MCP specification handle security for me? It defines how sign-in works. Enforcing permissions, approvals, isolation and outbound controls is up to whoever runs the server.
Should agents be allowed to make changes at all? Yes, if that’s where the value is. Start with look-ups if you’re unsure, then add changes with approvals and limits.
Are background agents riskier than chat assistants? Generally yes. They may run with no one checking each step, so the controls on the server side matter more.
Security built in
Gephyr sits between AI agents and your app. Every call is signed in, checked, limited and logged without secrets, and changes that matter wait for the user. You can pause your app or switch off an action at any time, and users can disconnect whenever they like. More in our security overview.
Start free or see what breaks when real agents use real APIs.