MCP-vangrails: veilige rechten voor AI-agents

Een MCP-token is je accountwachtwoord met een API eraan. Geef het aan een agent en je hebt een gebruiker die nooit moe wordt, elke pagina leest waar je hem naartoe stuurt en precies doet wat de laatste instructie in zijn context zei. Meestal is dat wat je wilt. Deze pagina gaat over de rest van de tijd.

Alles hieronder is op de datum bovenaan gecontroleerd tegen de live server: de toollijst komt uit tools/list op https://mcp.eqvps.com/mcp, de limieten uit de API zelf. Ben je nieuw, lees dan eerst een MCP-client verbinden en API-tokens en kom daarna terug.

Dreigingsmodel: wat er in de praktijk misgaat

Drie dingen, in de volgorde waarin we ze zien:

1. De agent begrijpt het verkeerd. "Ruim de testbak op" wordt een herinstallatie van de verkeerde server. Geen kwade wil, gewoon een model dat een gat in de opdracht invult.
2. Prompt injection. De agent leest tekst die jij niet schreef (een README, een antwoord van support, een gescrapete pagina) en die tekst zegt hem iets te doen. Heeft de agent een token met volledige rechten, dan heeft de geïnjecteerde instructie die ook.
3. Het token lekt. Het belandt in een shellgeschiedenis, een openbare repo, een gedeelde MCP-config of een logregel.

De MCP-server controleert of het token geldig is en of de server bij dat account hoort (of eraan gedelegeerd is). Wat je bedoelde, weet hij niet. Elke vangrail hieronder beantwoordt één vraag: hoeveel schade is mogelijk als de opdracht fout is?

Alle MCP-tools per risiconiveau

Een klanttoken ziet 45 tools (MCP-server 1.6.0). Een resellertoken (rk_…) ziet een aparte set van 30 resellertools en geen van deze, dus het endpoint heeft er in totaal 75. Je client krijgt uit tools/list alleen zijn eigen set.

Deze pagina sorteert de tools op risico. Parameters en voorbeeldaanroepen per tool staan in de parameterreferentie; alle tools op één regel, inclusief de 30 resellertools, staan in de volledige lijst.

MCP-toolannotaties (readOnlyHint, destructiveHint) leveren we nog niet mee, dus je client kan ze niet zelf sorteren. Stel de goedkeuringen met de hand in op basis van de niveaus hieronder.

Niveau 0 — openbaar, zonder token (5)

Niveau 1 — account lezen, zonder bijwerkingen (15)

Niveau 2 — wijzigt de status, geeft niets uit (17)

Niveau 3 — geeft geld uit, vernietigt data of verleent toegang (8)

Changelog van de toolset

De draaiende versie is openbaar: curl -s https://mcp.eqvps.com/healthz. Verandert die, dan verandert deze tabel mee.

Het saldo is de bestedingslimiet

EQVPS is prepaid. Geen kaart op het account, geen kredietlijn, geen roodstand: het meeste dat een agent ooit kan uitgeven, is wat er op het saldo staat. Drie tools geven geld uit: order_vps, change_plan en create_sandbox. Verlengingen van je bestaande servers gaan van hetzelfde saldo af.

De agent kan geldverzoeken aanmaken, maar niet betalen. topup_balance en pay_invoice geven een crypto-betaallink terug, en zonder wallet erachter doet een link niets. Er is ook geen opname-endpoint: geld op het saldo kan diensten in je account kopen, maar niet naar buiten. Terugbetalingen bij een directe opzegging gaan ook terug naar het saldo.

Eén kanttekening, en die is echt. Houd je het saldo heel laag om de agent af te remmen, dan mislukken je eigen verlengingen en gaan servers in de grace-periode. Onze vuistregel: één verlengingscyclus van wat je al draait, plus het budget van de huidige taak van de agent. De gids voor agentbudgetten rekent het voor. En geef je de agent een eigen gevulde wallet, dan wordt die wallet een tweede limiet die je in de gaten moet houden.

Least privilege: een alleen-lezentoken bestaat (nog) niet

Eerlijk antwoord: elk klanttoken heeft dezelfde rechten als het account in het dashboard. Naam en looptijd van een token zijn in te stellen, scopes niet.

Het nauwste wat er vandaag is, is delegatie. Je geeft de agent een eigen account met nul saldo en delegeert er één server aan:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

Hetzelfde via REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

De uitnodiging moet worden geaccepteerd terwijl je met dat e-mailadres bent ingelogd (accept_delegation), en expires_days ligt tussen 1 en 365. Stap voor stap met screenshots: toegang delegeren en toegang in de docs.

Let op de laatste twee regels links. Een gedelegeerde kan je geld niet uitgeven, maar die server wel wissen. Zet back-ups aan op elke server die een agent kan herinstalleren.

Tokenhygiëne

Eén token per agent, met een naam. Maak het aan via Dashboard → Instellingen → API-tokens voor agents, of zo:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

Het token wordt één keer getoond. Looptijd 1 tot 1825 dagen, 365 als je niets opgeeft. Voor agents zouden wij 90 kiezen.

Bewaar het in een bestand dat alleen jij kunt lezen, niet in de repo, niet in de prompt, niet in een shellvariabele die je overal rondkopieert:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # verwacht: -rw-------

Laad het daarna in de service van de agent met EnvironmentFile= (systemd) of set -a; . ~/.config/eqvps/agent.env; set +a.

Roteer vóór het verloopt. De tool refresh_token, of POST /auth/tokens/{id}/refresh, geeft een nieuw token met dezelfde naam uit en trekt het oude direct in. Staat het token hard in de config van je MCP-client, werk die dan meteen bij, anders krijgt de volgende sessie een 401.

Controleer wie wat gebruikt: GET /auth/tokens toont elk token met naam, vervaldatum en last_used_at. Een token dat je niet herkent, of een dat gebruikt is nadat je de agent uitzette, is je signaal.

Als een token lekt

In deze volgorde:

1. Trek het in. Dashboard → Instellingen → API-tokens voor agents → Intrekken, of curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Vanaf het volgende verzoek werkt het niet meer.
2. Zoek naar nieuwe tokens die jij niet hebt aangemaakt, en trek die ook in.
3. Bekijk wat geraakt kan zijn: de servicegeschiedenis van elke server, je facturen en saldo, en list_delegations op toegang die jij niet hebt verleend.
4. Wijzig de rootwachtwoorden van elke server die dat token kon zien. get_vps_status met reveal: true geeft het rootwachtwoord vrij, dus een gelekt token is een gelekt rootwachtwoord. Controleer meteen ook ~/.ssh/authorized_keys.
5. Sluit de wachtwoorddeur. Had je account nooit een wachtwoord, dan kon de tokenhouder er een instellen met set_password. Log in met een e-mailcode en wijzig het.

Voorkomen van stap 5 kost niets: stel nu zelf een accountwachtwoord in, dan geeft set_password 409 aan iedereen na jou.

Menselijke goedkeuring

Wat de server afdwingt:

• reinstall_vps, reset_password en cancel_service met type: immediate vereisen confirm gelijk aan de exacte hostname (DELETE werkt ook bij herinstallatie en reset).
• change_plan vereist confirm: true.
• Opzeggen gebeurt standaard per einde periode (end_of_period): de server draait tot het eind van de betaalde periode en undo_cancel draait het terug.
• Ratelimieten per account: herinstallatie 4/min, wachtwoordreset 6/min, power 20/min, bestellingen 20/min. Genoeg om een lus het niet vijftig keer te laten doen, niet genoeg om één foute call te stoppen.

Wees helder over wat confirm is. Het voorkomt dat een agent op "ruim het op" gaat handelen. Een aanvaller houdt het niet tegen, want de hostname zit één get_vps_status-call verderop. De echte goedkeuring zit in je MCP-client. De meeste clients kunnen voor elke toolcall vragen: laat niveau 0 en 1 vrij lopen en laat niveau 3 altijd vragen. In clients met rechten per tool, zoals de settings.json van Claude Code (server geregistreerd als eqvps):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

Zet ook een regel in de instructies van de agent. Op zichzelf is dat geen beveiliging, maar het scheelt misverstanden (laat hem in het Engels staan, modellen begrijpen hem even goed):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

Logt de agent in met een e-mailcode in plaats van een langlevend token vast te houden, zie dan agentlogin via MCP.

Audit: wat je achteraf ziet

• Tokenlijst (GET /auth/tokens, of Instellingen → API-tokens voor agents): naam, aangemaakt, vervalt, last_used_at. Daarom loont het om tokens per agent een naam te geven.
• Servicegeschiedenis (dashboard, serverpagina): power-acties, herinstallaties, wachtwoordresets, pakketwissels, betalingen, elk met tijd en actor: jij, support of automatisch. Het vertelt niet welk token of welke gedelegeerde het deed, alleen dat het van jouw kant kwam.
• Facturen en saldo: elke afschrijving en terugbetaling.
• list_delegations: wie waar toegang toe heeft, en tot wanneer.

Dat gat in de servicegeschiedenis is vandaag de eerlijke grens van serveraudit. Moet je weten welke agent wat deed, log dan elke toolcall met zijn argumenten (zonder secrets) aan de kant van de agent.

De opzet die wij zouden kiezen

Voor een agent die één productieserver beheert:

1. Een apart account voor de agent, saldo nul, de server gedelegeerd met expires_days: 90.
2. Jouw eigenaarstoken blijft bij jou en staat in geen enkele agentconfig.
3. Back-ups op die server, omdat een gedelegeerde kan herinstalleren.
4. Niveau 3-tools op "ask" of "deny" in de client.
5. Het token van de agent in een 600-bestand, vernieuwd vóór het verloopt.

Voor een agent die servers moet bestellen of sandboxes moet starten, is delegatie niet genoeg, want hij heeft saldo nodig. Dan is het saldo je limiet: waardeer het per taak op, geef het token een naam en kijk eens per week naar last_used_at. Zou een alleen-lezentoken veranderen hoe je agents inzet, laat het ons weten via support: juist dat soort feedback bepaalt wat we hierna bouwen.