MCP-skyddsräcken: säkra behörigheter för AI-agenter

En MCP-token är ditt kontolösenord med ett API kopplat till sig. Ge den till en agent så har du en användare som aldrig blir trött, läser varje sida du pekar den mot och gör exakt det som den senaste instruktionen i dess kontext sa. För det mesta är det precis vad du vill. Den här sidan handlar om resten av tiden.

Allt nedan är kontrollerat mot den skarpa servern på datumet överst: verktygslistan kommer från tools/list på https://mcp.eqvps.com/mcp, gränserna från själva API:et. Är du ny, läs först ansluta en MCP-klient och API-tokens och kom sedan tillbaka.

Hotmodell: vad som faktiskt går fel

Tre saker, i den ordning vi ser dem:

1. Agenten missförstår. "Städa testmaskinen" blir en ominstallation av fel server. Ingen illvilja, bara en modell som fyller ett hål i instruktionen.
2. Promptinjektion. Agenten läser text som du inte skrivit (en README, ett supportsvar, en skrapad sida) och den texten säger åt den att göra något. Har agenten en token med fulla rättigheter, har den injicerade instruktionen det också.
3. Token läcker. Den hamnar i en skalhistorik, ett publikt repo, en delad MCP-konfiguration eller en loggrad.

MCP-servern kontrollerar att token är giltig och att servern tillhör det kontot (eller är delegerad till det). Vad du menade vet den inte. Varje skyddsräcke nedan svarar på en enda fråga: hur stor skada är möjlig när instruktionen är fel?

Alla MCP-verktyg efter risknivå

En kundtoken ser 45 verktyg (MCP-server 1.6.0). En återförsäljartoken (rk_…) ser en separat uppsättning med 30 återförsäljarverktyg och inga av dessa, så endpointen har 75 totalt. Din klient får bara sin egen uppsättning från tools/list.

Den här sidan sorterar verktygen efter risk. Parametrar och exempelanrop för varje verktyg finns i parameterreferensen; alla verktyg på en rad, inklusive de 30 återförsäljarverktygen, finns i den fullständiga listan.

Vi skickar ännu inte med MCP-verktygsannoteringar (readOnlyHint, destructiveHint), så din klient kan inte sortera dem själv. Ställ in godkännanden för hand utifrån nivåerna nedan.

Nivå 0 — publika, ingen token (5)

Nivå 1 — läsa kontot, inga sidoeffekter (15)

Nivå 2 — ändrar tillstånd, spenderar inget (17)

Nivå 3 — spenderar pengar, förstör data eller ger åtkomst (8)

Ändringslogg för verktygsuppsättningen

Den körande versionen är publik: curl -s https://mcp.eqvps.com/healthz. När den ändras, ändras den här tabellen med den.

Saldot är utgiftstaket

EQVPS är förbetalt. Inget sparat kort, ingen kreditlina, ingen möjlighet att gå minus: det mesta en agent någonsin kan spendera är det som ligger på saldot. Tre verktyg spenderar: order_vps, change_plan och create_sandbox. Förnyelser av dina befintliga servrar dras från samma saldo.

Agenten kan skapa betalningsförfrågningar men inte betala dem. topup_balance och pay_invoice returnerar en kryptobetallänk, och en länk gör ingenting utan en plånbok bakom. Det finns heller ingen endpoint för uttag: pengar på saldot kan köpa tjänster i ditt konto men inte föras ut. Återbetalningar vid omedelbar uppsägning går också tillbaka till saldot.

En reservation, och den är på riktigt. Håller du saldot väldigt lågt för att bromsa agenten börjar dina egna förnyelser misslyckas och servrar hamnar i respitperiod. Vår tumregel: en förnyelsecykel av det du redan kör, plus budgeten för agentens aktuella uppgift. Guiden för agentbudget räknar igenom det. Och ger du agenten en egen plånbok med pengar blir den plånboken ett andra tak som du också måste hålla koll på.

Minsta behörighet: någon skrivskyddad token finns inte (än)

Rakt svar: varje kundtoken har samma rättigheter som kontot i kontrollpanelen. Namn och livslängd för en token går att ställa in, scopes gör det inte.

Det snävaste som finns i dag är delegering. Du ger agenten ett eget konto med noll i saldo och delegerar en server till det:

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

Samma sak 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}'

Inbjudan måste accepteras medan man är inloggad med den e-postadressen (accept_delegation), och expires_days kan vara 1 till 365. Steg för steg med skärmbilder: delegera åtkomst och åtkomst i dokumentationen.

Lägg märke till de två sista raderna till vänster. En delegat kan inte spendera dina pengar, men kan radera den servern. Slå på säkerhetskopiering för alla servrar som en agent kan installera om.

Tokenhygien

En token per agent, med namn. Skapa den under Kontrollpanel → Inställningar → API-tokens för agenter, eller så här:

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}'

Token visas en gång. Livslängd 1 till 1825 dagar, 365 om du inte anger något. För agenter skulle vi välja 90.

Förvara den i en fil som bara du kan läsa, inte i repot, inte i prompten, inte i en skalvariabel som du kopierar runt:

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   # förväntat: -rw-------

Läs sedan in den i agentens tjänst med EnvironmentFile= (systemd) eller set -a; . ~/.config/eqvps/agent.env; set +a.

Rotera innan den går ut. Verktyget refresh_token, eller POST /auth/tokens/{id}/refresh, utfärdar en ny token med samma namn och återkallar den gamla direkt. Står token hårdkodad i din MCP-klients konfiguration, uppdatera den direkt efteråt, annars får nästa session 401.

Kontrollera vem som använder vad: GET /auth/tokens listar varje token med namn, utgångsdatum och last_used_at. En token du inte känner igen, eller en som användes efter att du stängt av agenten, är din signal.

Om en token läcker

I den här ordningen:

1. Återkalla den. Kontrollpanel → Inställningar → API-tokens för agenter → Återkalla, eller curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Den slutar fungera vid nästa anrop.
2. Leta efter nya tokens som du inte har skapat, och återkalla dem också.
3. Gå igenom vad som kan ha påverkats: tjänstehistoriken för varje server, dina fakturor och ditt saldo, och list_delegations efter åtkomst du inte gett.
4. Byt root-lösenord på varje server som den token kunde se. get_vps_status med reveal: true lämnar ut root-lösenordet, så en läckt token är ett läckt root-lösenord. Kontrollera ~/.ssh/authorized_keys när du ändå är där.
5. Stäng lösenordsdörren. Har ditt konto aldrig haft ett lösenord kan den som hade token ha satt ett med set_password. Logga in med en kod via e-post och byt det.

Att förebygga steg 5 kostar ingenting: sätt ett kontolösenord själv nu, så returnerar set_password 409 till alla som kommer efter dig.

Mänskligt godkännande

Det här upprätthåller servern:

• reinstall_vps, reset_password och cancel_service med type: immediate kräver confirm lika med det exakta värdnamnet (DELETE fungerar också för ominstallation och återställning).
• change_plan kräver confirm: true.
• Uppsägning sker som standard vid periodens slut (end_of_period): servern kör till slutet av den betalda perioden och undo_cancel ångrar det.
• Hastighetsgränser per konto: ominstallation 4/min, lösenordsåterställning 6/min, ström 20/min, beställningar 20/min. Tillräckligt för att en loop inte ska göra det femtio gånger, inte för att stoppa ett enda felaktigt anrop.

Var klar över vad confirm är. Det hindrar en agent från att agera på "städa upp där". Det stoppar inte en angripare, eftersom värdnamnet bara är ett get_vps_status-anrop bort. Det riktiga godkännandet finns i din MCP-klient. De flesta klienter kan fråga före varje verktygsanrop: låt nivå 0 och 1 köra fritt och låt nivå 3 alltid fråga. I klienter med behörigheter per verktyg, som settings.json i Claude Code (servern registrerad som 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"]
  }
}

Lägg också till en rad i agentens instruktioner. Ensam är den ingen säkerhetskontroll, men den minskar missförstånden (behåll den på engelska, modellerna förstår den lika bra):

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.

Loggar agenten in med en e-postkod i stället för att hålla en långlivad token, se agentinloggning via MCP.

Granskning: vad du ser i efterhand

• Tokenlistan (GET /auth/tokens, eller Inställningar → API-tokens för agenter): namn, skapad, utgår, last_used_at. Därför lönar det sig att namnge tokens per agent.
• Tjänstehistorik (kontrollpanelen, serversidan): strömåtgärder, ominstallationer, lösenordsåterställningar, planbyten, betalningar, var och en med tid och aktör: du, supporten eller automatiskt. Den säger inte vilken token eller delegat som agerade, bara att det kom från din sida.
• Fakturor och saldo: varje debitering och återbetalning.
• list_delegations: vem som har åtkomst till vad, och till när.

Den luckan i tjänstehistoriken är i dag den ärliga gränsen för granskning på serversidan. Behöver du veta vilken agent som gjorde vad, logga varje verktygsanrop med argument (utan hemligheter) på agentens sida.

Upplägget vi skulle välja

För en agent som sköter en produktionsserver:

1. Ett separat konto för agenten, noll i saldo, servern delegerad med expires_days: 90.
2. Din ägartoken stannar hos dig och ligger inte i någon agentkonfiguration.
3. Säkerhetskopiering på den servern, eftersom en delegat kan installera om.
4. Nivå 3-verktyg på "ask" eller "deny" i klienten.
5. Agentens token i en 600-fil, förnyad innan den går ut.

För en agent som måste beställa servrar eller köra sandlådor räcker inte delegering, eftersom den behöver saldo. Då är saldot ditt tak: fyll på per uppgift, namnge token och titta på last_used_at en gång i veckan. Om en skrivskyddad token skulle ändra hur du sätter agenter i arbete, säg det till oss i supporten: det är just sådan återkoppling som avgör vad vi bygger härnäst.