MCP-Leitplanken: sichere Berechtigungen für KI-Agenten

Ein MCP-Token ist Ihr Kontopasswort mit angeschlossener API. Geben Sie es einem Agenten, und Sie haben einen Nutzer, der nie müde wird, jede Webseite liest, auf die Sie ihn ansetzen, und genau das tut, was die letzte Anweisung in seinem Kontext sagt. Meistens ist das genau das, was Sie wollen. Diese Seite handelt vom Rest.

Alles hier wurde am Datum oben gegen den Live-Server geprüft: Die Tool-Liste stammt aus tools/list auf https://mcp.eqvps.com/mcp, die Limits aus der API selbst. Wenn Sie neu sind, lesen Sie zuerst MCP-Client verbinden und API-Tokens und kommen dann zurück.

Bedrohungsmodell: was tatsächlich schiefgeht

Drei Dinge, in der Reihenfolge, in der wir sie sehen:

1. Der Agent versteht falsch. Aus „räum die Testkiste auf" wird eine Neuinstallation des falschen Servers. Keine böse Absicht, nur ein Modell, das eine Lücke in der Anweisung füllt.
2. Prompt Injection. Der Agent liest Text, den Sie nicht geschrieben haben (eine README, eine Support-Antwort, eine gescrapte Seite), und dieser Text sagt ihm, er solle etwas tun. Hat der Agent ein Token mit vollen Rechten, hat die eingeschleuste Anweisung sie auch.
3. Das Token leakt. Es landet in einer Shell-History, einem öffentlichen Repo, einer geteilten MCP-Konfiguration oder einer Logzeile.

Der MCP-Server prüft, ob das Token gültig ist und ob der Server zu diesem Konto gehört (oder an es delegiert ist). Was Sie gemeint haben, weiß er nicht. Jede Leitplanke unten beantwortet eine Frage: Wie viel Schaden ist möglich, wenn die Anweisung falsch ist?

Alle MCP-Tools nach Risikostufe

Ein Kunden-Token sieht 45 Tools (MCP-Server 1.6.0). Ein Reseller-Token (rk_…) sieht einen eigenen Satz von 30 Reseller-Tools und keines von diesen, der Endpunkt hat also insgesamt 75. Ihr Client erhält über tools/list nur seinen eigenen Satz.

Diese Seite sortiert die Tools nach Risiko. Parameter und Beispielaufrufe jedes Tools stehen in der Parameterreferenz; alle Tools in je einer Zeile, inklusive der 30 Reseller-Tools, in der vollständigen Liste.

MCP-Tool-Annotationen (readOnlyHint, destructiveHint) liefern wir noch nicht aus, Ihr Client kann die Tools also nicht selbst einsortieren. Stellen Sie die Freigaben anhand der Stufen unten von Hand ein.

Stufe 0 — öffentlich, ohne Token (5)

Stufe 1 — Konto lesen, ohne Nebenwirkungen (15)

Stufe 2 — ändert den Zustand, gibt nichts aus (17)

Stufe 3 — gibt Geld aus, löscht Daten oder vergibt Zugriff (8)

Changelog des Tool-Satzes

Die laufende Version ist öffentlich: curl -s https://mcp.eqvps.com/healthz. Ändert sie sich, ändert sich diese Tabelle mit.

Das Guthaben ist das Ausgabenlimit

EQVPS ist Prepaid. Keine hinterlegte Karte, keine Kreditlinie, kein Minus: Ein Agent kann höchstens ausgeben, was auf dem Guthaben liegt. Drei Tools geben Geld aus: order_vps, change_plan und create_sandbox. Verlängerungen Ihrer bestehenden Server laufen über dasselbe Guthaben.

Der Agent kann Geldanforderungen erzeugen, aber nicht bezahlen. topup_balance und pay_invoice liefern einen Krypto-Checkout-Link, und ohne Wallet dahinter bewirkt ein Link nichts. Einen Auszahlungs-Endpunkt gibt es auch nicht: Geld auf dem Guthaben kann Dienste in Ihrem Konto kaufen, aber nicht abgezogen werden. Erstattungen bei sofortiger Kündigung gehen ebenfalls aufs Guthaben.

Ein Haken, und zwar ein echter. Halten Sie das Guthaben sehr niedrig, um den Agenten zu bremsen, scheitern Ihre eigenen Verlängerungen und Server gehen in die Grace-Periode. Unsere Faustregel: ein Verlängerungszyklus dessen, was Sie bereits betreiben, plus das Budget des aktuellen Agenten-Jobs. Der Leitfaden zum Agenten-Budget rechnet das durch. Und wenn Sie dem Agenten eine eigene, gefüllte Wallet geben, wird diese Wallet zu einem zweiten Limit, das Sie im Blick behalten müssen.

Least Privilege: Ein Read-only-Token gibt es (noch) nicht

Klartext: Jedes Kunden-Token hat dieselben Rechte wie das Konto im Dashboard. Name und Laufzeit eines Tokens sind einstellbar, Scopes nicht.

Das Engste, was es heute gibt, ist Delegation. Sie geben dem Agenten ein eigenes Konto ohne Guthaben und delegieren ihm einen Server:

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

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

Die Einladung muss angenommen werden, während man mit dieser E-Mail angemeldet ist (accept_delegation), und expires_days liegt zwischen 1 und 365. Schritt für Schritt mit Screenshots: Zugriff delegieren und Zugriff in der Doku.

Beachten Sie die letzten beiden Zeilen links. Ein Delegierter kann Ihr Geld nicht ausgeben, diesen Server aber löschen. Aktivieren Sie Backups auf jedem Server, den ein Agent neu installieren kann.

Token-Hygiene

Ein Token pro Agent, mit Namen. Legen Sie es unter Dashboard → Einstellungen → API-Tokens für Agenten an, oder so:

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

Das Token wird einmal angezeigt. Laufzeit 1 bis 1825 Tage, 365 ohne Angabe. Für Agenten würden wir 90 nehmen.

Bewahren Sie es in einer Datei auf, die nur Sie lesen können, nicht im Repo, nicht im Prompt, nicht in einer Shell-Variable, die Sie herumkopieren:

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   # erwartet: -rw-------

Laden Sie es dann im Dienst des Agenten mit EnvironmentFile= (systemd) oder set -a; . ~/.config/eqvps/agent.env; set +a.

Vor Ablauf rotieren. Das Tool refresh_token oder POST /auth/tokens/{id}/refresh stellt ein neues Token mit demselben Namen aus und widerruft das alte sofort. Steht das Token fest in der Konfiguration Ihres MCP-Clients, aktualisieren Sie es direkt danach, sonst bekommt die nächste Sitzung ein 401.

Prüfen, wer was nutzt: GET /auth/tokens listet jedes Token mit Name, Ablauf und last_used_at. Ein Token, das Sie nicht kennen, oder eines, das nach dem Abschalten des Agenten benutzt wurde, ist Ihr Signal.

Wenn ein Token leakt

In dieser Reihenfolge:

1. Widerrufen. Dashboard → Einstellungen → API-Tokens für Agenten → Widerrufen, oder curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Ab der nächsten Anfrage funktioniert es nicht mehr.
2. Nach neuen Tokens suchen, die Sie nicht angelegt haben, und diese ebenfalls widerrufen.
3. Die Angriffsfläche prüfen: den Dienstverlauf jedes Servers, Rechnungen und Guthaben sowie list_delegations auf Zugriffe, die Sie nicht vergeben haben.
4. Root-Passwörter rotieren auf jedem Server, den das Token sehen konnte. get_vps_status mit reveal: true gibt das Root-Passwort heraus, ein geleaktes Token ist also ein geleaktes Root-Passwort. Prüfen Sie dabei gleich ~/.ssh/authorized_keys.
5. Die Passwort-Tür schließen. Hatte Ihr Konto nie ein Passwort, konnte der Token-Inhaber mit set_password eines setzen. Melden Sie sich per E-Mail-Code an und ändern Sie es.

Vorbeugung für Schritt 5 kostet nichts: Setzen Sie jetzt selbst ein Kontopasswort, dann liefert set_password für alle anderen 409.

Human in the Loop

Was der Server durchsetzt:

• reinstall_vps, reset_password und cancel_service mit type: immediate brauchen confirm gleich dem exakten Hostnamen (DELETE geht auch bei Neuinstallation und Reset).
• change_plan braucht confirm: true.
• Gekündigt wird standardmäßig zum Periodenende (end_of_period): Der Server läuft bis zum Ende der bezahlten Periode, undo_cancel macht es rückgängig.
• Rate-Limits pro Konto: Neuinstallation 4/Min., Passwort-Reset 6/Min., Power 20/Min., Bestellungen 20/Min. Genug, damit eine Schleife es nicht fünfzigmal tut, aber nicht genug, um einen einzelnen falschen Aufruf zu verhindern.

Seien Sie sich im Klaren, was confirm ist. Es hält einen Agenten davon ab, auf „räum das auf" loszulegen. Einen Angreifer hält es nicht auf, denn der Hostname ist einen get_vps_status-Aufruf entfernt. Die echte Freigabe sitzt in Ihrem MCP-Client. Die meisten Clients können vor jedem Tool-Aufruf nachfragen: Stufe 0 und 1 frei laufen lassen, Stufe 3 immer fragen lassen. In Clients mit Berechtigungen pro Tool, etwa in der settings.json von Claude Code (Server registriert 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"]
  }
}

Ergänzen Sie außerdem eine Zeile in den Anweisungen des Agenten. Für sich allein ist das keine Sicherheitsmaßnahme, aber es reduziert die Missverständnisse (lassen Sie sie auf Englisch, Modelle verstehen sie gleich gut):

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.

Wenn sich der Agent per E-Mail-Code anmeldet, statt ein langlebiges Token zu halten, siehe Agenten-Login über MCP.

Audit: was Sie hinterher sehen

• Token-Liste (GET /auth/tokens oder Einstellungen → API-Tokens für Agenten): Name, erstellt, Ablauf, last_used_at. Deshalb lohnt es sich, Tokens pro Agent zu benennen.
• Dienstverlauf (Dashboard, Serverseite): Power-Aktionen, Neuinstallationen, Passwort-Resets, Tarifwechsel, Zahlungen, jeweils mit Zeit und Auslöser: Sie, Support oder automatisch. Welches Token oder welcher Delegierte gehandelt hat, zeigt er nicht, nur dass es von Ihrer Seite kam.
• Rechnungen und Guthaben: jede Abbuchung und Erstattung.
• list_delegations: wer worauf Zugriff hat und bis wann.

Diese Lücke im Dienstverlauf ist heute die ehrliche Grenze des serverseitigen Audits. Wenn Sie wissen müssen, welcher Agent was getan hat, protokollieren Sie jeden Tool-Aufruf mit seinen Argumenten (ohne Secrets) auf der Seite des Agenten.

Das Setup, das wir nehmen würden

Für einen Agenten, der einen Produktivserver betreut:

1. Ein eigenes Konto für den Agenten, Guthaben null, der Server delegiert mit expires_days: 90.
2. Ihr Eigentümer-Token bleibt bei Ihnen und steht in keiner Agenten-Konfiguration.
3. Backups auf diesem Server, weil ein Delegierter neu installieren kann.
4. Stufe-3-Tools im Client auf „ask" oder „deny".
5. Das Token des Agenten in einer 600-Datei, rechtzeitig vor Ablauf erneuert.

Für einen Agenten, der Server bestellen oder Sandboxes starten muss, reicht Delegation nicht, denn er braucht Guthaben. Dann ist das Guthaben Ihr Limit: pro Job aufladen, das Token benennen und einmal pro Woche last_used_at lesen. Wenn ein Read-only-Token verändern würde, wie Sie Agenten einsetzen, sagen Sie es uns im Support: Genau solches Feedback entscheidet, was wir als Nächstes bauen.