Agent Harness

Claude Code und Codex laufen auf dem Rechner des Entwicklers, unter der Policy Ihrer Organisation: kontrollierter Modellverkehr, kontrollierte Tools, eine gemessene und versiegelte Audit-Spur.

Nichts am Agenten wandert in die Cloud. Claude Code und Codex laufen weiter auf dem Rechner des Entwicklers, mit eigenen Prozessen, Dateien, eingebauten Tools und eigener Agent-Schleife. Sluis kontrolliert den Verkehr, der hinausgeht: die Modellanfragen und die Tool-Aufrufe.

Der lokale Client authentifiziert sich bei Sluis mit einem Agent-Key und spricht den Eingang seines Protokolls an: /agent/claude spricht die Anthropic-API für Claude Code, /agent/codex/v1 die OpenAI-Responses-API für Codex, /agent/cursor das Connect-Protokoll von Cursor über Protobuf, und /agent/mcp ist ein zustandsloser Streamable-HTTP-MCP-Endpunkt für die kontrollierten Tools.

Claude Code und Codex sind Beispiele, keine Allowlist. Pi, T3 Code und jeder Client mit Anthropic-Messages-, OpenAI-Responses- oder MCP-URL und API-Key nutzen denselben Agent Harness.

Die Einrichtung läuft in einer Reihenfolge, und jeder Schritt braucht den vorigen:

• 1. Abonnement verbinden. Claude oder Codex, einmal pro Anbieterkonto verbunden.
• 2. Agent-Key erstellen. Das Secret wird einmal gezeigt, bei der Erstellung.
• 3. Key mit dem Konto verknüpfen. Ein Key gibt nur die Konten aus, mit denen er verknüpft ist.
• 4. Lokalen Client konfigurieren. Der Key liegt in SLUIS_AGENT_KEY, und die Basis-URL zeigt auf /agent/claude für Claude Code, /agent/codex/v1 für Codex oder /agent/cursor für Cursor, das denselben Key in Authorization: Bearer trägt.
• 5. Tool-Endpunkt registrieren. Tools kommen ausschließlich über /agent/mcp, separat registriert: eine Basis-URL bringt keine.

Abonnement verbinden

Eine Organisation verbindet ein oder mehrere Claude- und Codex-Abonnementkonten in der Agent-Harness-Ansicht. Claude wird mit einem Token aus claude setup-token verbunden, Codex über OpenAIs Geräteautorisierung. Sluis prüft die Zugangsdaten beim Anbieter, bevor etwas gespeichert wird.

Claude: Setup-Token

Sie brauchen Claude Code auf Ihrem Rechner, angemeldet an einem Claude-Abonnement, das Modellanfragen erlaubt.

• 1. Führen Sie claude setup-token im Terminal aus. Der Befehl gibt ein langlebiges Token aus, etwa ein Jahr gültig, beginnend mit sk-ant-oat.
• 2. Fügen Sie es in das Claude-Feld der Console ein. Das Feld ist maskiert, Autocomplete ist aus.
• 3. Beim Absenden prüft Sluis das Token bei Anthropic, bevor irgendetwas gespeichert wird.
• 4. Ein geprüftes Token wird verschlüsselt im Vault des Gateways versiegelt. Es wird nie wieder gezeigt, nie an einen Client zurückgegeben und nie irgendwohin außer zu Anthropic gesendet.

Ein Token, das Anthropic nicht bestätigt, wird mit 422 abgelehnt: kein Konto entsteht, nichts wird gespeichert und nichts abgerechnet. Wird dasselbe Abonnement später erneut verbunden, nutzt Sluis das bestehende Konto statt eines zweiten abrechenbaren.

Codex: Geräteautorisierung

Sie brauchen einen ChatGPT-Plan, der Codex enthält.

• 1. Starten Sie die Geräteanmeldung in der Console. Sluis fragt OpenAI und zeigt Ihnen eine Verifizierungs-URL und einen Benutzercode.
• 2. Öffnen Sie diese URL über die Schaltfläche, melden Sie sich bei OpenAI an, geben Sie den Code ein und bestätigen Sie. OpenAI kann MFA verlangen.
• 3. Die Console fragt währenddessen ab. Der Austausch läuft in diesem Browser-Tab: die Seite verlassen oder auf einen anderen Tab der Ansicht wechseln bricht die Anmeldung ab und speichert nichts, genau wie die Aktion Abbrechen.
• 4. Nach der Bestätigung legt Sluis Access- und Refresh-Token verschlüsselt im Vault des Gateways ab und erneuert sie für Sie; die Rotation des Refresh-Tokens ist über alle Replicas serialisiert.

Ein Benutzercode verfällt. Ein verfallener Ablauf meldet expired und muss neu gestartet werden — ebenso ein Konto, dessen gespeicherte Zugangsdaten OpenAI später ablehnt; es bedient nichts mehr, bis ein Mensch es neu verbindet.

Sluis verschlüsselt diese Zugangsdaten, hält sie im Vault des Gateways und erneuert sie dort. Ein Anbieter-Token erreicht niemals den lokalen Client, die Logs, die Audit-Einträge oder die Traces: Claude Code und Codex halten nur ihren Sluis-Agent-Key.

Das Verbinden ist Selbstbedienung, ein Mitglied kann sein eigenes Abonnement hinzufügen. Owner und Admins sehen jedes Konto der Organisation; ein Mitglied sieht und trennt nur sein eigenes.

Agent-Key erstellen

Agent-Keys entstehen in derselben Ansicht, getrennt von Ihren API-Keys, weil die beiden Zwecke isoliert sind. Ein Agent-Key authentifiziert nur auf /agent/*, ein gewöhnlicher API-Key nur auf /v1/*. Beides auf der falschen Fläche ergibt ein 401, und die Ablehnung nennt den Zweck des Keys nie.

Das Secret wird einmal bei der Erstellung gezeigt, gespeichert wird nur sein Hash. Jeder Key läuft über die Anbieterkonten, die Sie ihm zuweisen: ein zweites Mitgliedsabonnement leitet einen bestehenden Key niemals um.

Ein Key hält außerdem die Obergrenze der Organisation für die eingebauten Tools des lokalen Clients fest, geschrieben in der Tool-Grammatik von Claude Code und bei der Erstellung validiert. Der Client des Entwicklers setzt diese Liste auf dem Rechner durch; Sluis liest sie bei einer Anfrage nie, also kann kein Key-Inhaber seinen eigenen Key erweitern, und eine leere Liste hält einfach keine Obergrenze fest.

Die Tools, die Sluis selbst bei jeder Anfrage kontrolliert, sind die MCP-Tools, die es bereitstellt: siehe die Plugins unten.

Die Clients auf Sluis richten

Claude Code braucht eine Basis-URL und eine Zugangsdaten-Variable. Setzen Sie ANTHROPIC_BASE_URL auf den Claude-Eingang dieses Gateways und ANTHROPIC_API_KEY auf den Agent-Key aus SLUIS_AGENT_KEY. Die Console erzeugt den Block unten mit der öffentlichen URL Ihres Gateways.

Eine Basis-URL bringt keine Tools: das Anthropic-Protokoll kennt keine Plugin-Erkennung, Tools kommen also nur über einen MCP-Endpunkt, den Sie selbst registrieren, mit claude mcp add oder einem Eintrag in .mcp.json. Beide verweisen auf ${SLUIS_AGENT_KEY} statt auf den Key, damit kein Secret in einer eingecheckten Datei landet.

Codex liest seinen Provider-Block aus ~/.codex/config.toml. Richten Sie base_url auf den Responses-Eingang /agent/codex/v1, setzen Sie wire_api = "responses" und env_key = "SLUIS_AGENT_KEY" und tragen Sie denselben MCP-Endpunkt unter [mcp_servers.sluis] ein.

# the agent key is shown once, at creation: keep it in the environment
export SLUIS_AGENT_KEY='sluis-9f2c…'
export ANTHROPIC_BASE_URL='https://api.sluis.ai/agent/claude'
export ANTHROPIC_API_KEY="$SLUIS_AGENT_KEY"

# a base URL adds no tools: register the MCP endpoint separately
claude mcp add --transport http sluis 'https://api.sluis.ai/agent/mcp' \
  --header 'Authorization: Bearer ${SLUIS_AGENT_KEY}'

// .mcp.json: the same registration, kept with the project
{
  "mcpServers": {
    "sluis": {
      "type": "http",
      "url": "https://api.sluis.ai/agent/mcp",
      "headers": {
        "Authorization": "Bearer ${SLUIS_AGENT_KEY}"
      }
    }
  }
}

# Codex reads the key from SLUIS_AGENT_KEY, never from the config file
codex exec -m openai/gpt-5.4 'tighten the retry test'

# ~/.codex/config.toml
model = "openai/gpt-5.4"
model_provider = "sluis"

[model_providers.sluis]
name = "Sluis"
base_url = "https://api.sluis.ai/agent/codex/v1"
env_key = "SLUIS_AGENT_KEY"
wire_api = "responses"

[mcp_servers.sluis]
url = "https://api.sluis.ai/agent/mcp"
bearer_token_env_var = "SLUIS_AGENT_KEY"
default_tools_approval_mode = "approve"

Cursor zeigt auf dasselbe Gateway. Setzen Sie seine Basis-URL auf den Cursor-Eingang dieses Gateways, /agent/cursor, mit dem Agent-Key im Authorization-Header. Die dokumentierte Route ist POST /agent/cursor/agent.v1.AgentService/Run, über Connect mit dem Content-Type application/connect+proto. Ein Client, der keine Basis-URL setzen kann, darf stattdessen auf den bloßen Origin zeigen, weil das Protokoll von Cursor einen absoluten Pfad festlegt.

Sluis durchläuft diese Connect-Frames ohne Schema und wendet den Datenschutzmodus der Organisation auf den Prompt-Text darin an: tokenize ersetzt erkannte Werte durch umkehrbare Platzhalter und stellt die Originale in der gestreamten Antwort wieder her, mask redigiert sie vollständig, block lehnt den Turn ab, bevor irgendetwas Cursor erreicht, und ein Frame, den Sluis nicht dekodieren kann, wird abgelehnt statt weitergeleitet. Nur allow_log leitet ihn weiter, und der Audit-Trail hält fest, dass er nicht prüfbar war.

Zwei Grenzen gehören zu diesem Transport. Die Namenserkennung und der Prompt-Injection-Schutz lesen einen JSON-Request-Body, und Connect-Protobuf ist keiner: Sie laufen daher nicht, die Audit-Zeile führt sie als nicht ausgeführt, und eine Organisation, die die Namenserkennung verpflichtend gemacht hat, erhält eine Ablehnung statt einer ungeprüften Weiterleitung. Das Connect-Protokoll meldet außerdem keinen Token-Verbrauch, deshalb wird ein Cursor-Turn ohne Token-Zahlen im Audit-Trail versiegelt.

Jede Fläche akzeptiert ihre Zugangsdaten in genau einer Form: x-api-key am Claude-Eingang, was Anthropic-Clients senden, und Authorization: Bearer an den Codex-, Cursor- und MCP-Eingängen. Derselbe Key im anderen Header wird abgelehnt.

MCP-Plugins

Kontrollierte Tools kommen über einen einzigen zustandslosen Endpunkt, POST /agent/mcp. Er hält keine Session: jede Anfrage leitet die gesamte Autorisierungskette neu ab, ein widerrufener Key, ein widerrufenes Plugin oder ein widerrufener Signaturschlüssel wirkt also beim nächsten Aufruf.

Es gibt zwei Klassen. Von Sluis gepflegte Plugins sind kompilierter Sluis-Code, organisationsweit verfügbar, und führen keinerlei Mandantencode aus. Organisations-Plugins sind Ihre eigenen: ein TOML-Manifest, mit Ed25519 signiert.

Ein Manifest wird nur akzeptiert, wenn seine Signatur unter einem von Ihrer Organisation hinterlegten Signaturschlüssel verifiziert, und es ist unveränderlich pro (organisation, id, version): eine geänderte Tool-Definition ist eine neue Version, nie eine stille Korrektur. Jedes Plugin ist an einen kontrollierten HTTPS-MCP-Server gebunden, dessen Endpunkt exakt der URL im signierten Manifest entsprechen muss.

Der Betriebsablauf hat drei Schritte. Der Owner hinterlegt den Signaturschlüssel der Organisation. Ein Owner oder Admin registriert das signierte Manifest gegen einen kontrollierten MCP-Server. Danach wird das Plugin an die Agent-Keys gebunden, die es nutzen dürfen; ein Plugin ohne Bindung ist für niemanden sichtbar.

Server-URLs, Manifeste, Signaturen und Upstream-Zugangsdaten erreichen niemals einen Client. Ein Entwickler sieht Tool-Namen und Schemata, sonst nichts.

Kontext und Skills, die das Gateway injiziert

Ihre Engineering-Standards sind nur dann Richtlinie, wenn ein Entwickler sie nicht vergessen kann. Eine ins Repository eingecheckte CLAUDE.md ist ein Vorschlag: Sie lässt sich ändern, löschen oder einfach nicht lesen, und nichts hält fest, was davon passiert ist. Derselbe Text, den das Gateway in jede geregelte Agent-Anfrage schiebt, ist die Entscheidung der Organisation — schreibe den fehlschlagenden Test vor dem Fix, füge keine Abhängigkeit ohne genehmigtes ADR hinzu, dieses Repository enthält personenbezogene Daten, also pseudonymisieren Sie vor dem Einfügen. Das ist die Hälfte des Harness, die regelt, wie ein Agent arbeitet, und nicht, welches Modell und welche Tools er erreichen darf.

Zwei Plugin-Arten tragen das, und keine von beiden gewährt eine eigene Berechtigung:

• Kontext. Wortgetreuer Text, vor dem eigenen Prompt des Entwicklers injiziert, bis zu 16 KiB je Version.
• Skill. Ein Name, seine Anweisungen und die Tool-Namen, die er erwartet. Diese Namen werden mit der auf dem Key vermerkten Tool-Obergrenze geschnitten: Ein Skill erklärt, was er braucht, und kann einen Key niemals erweitern — ein Tool, das die Obergrenze nicht führt, wird dem Modell einfach nicht genannt.

Eine Version wird in einem von drei Geltungsbereichen gebunden, und jede Anfrage löst alle drei auf:

• Organisation. Jeder Agent-Key der Organisation, auch die nach der Bindung erstellten. Das ist der Bereich für eine Regel, an deren Anhängen niemand denken sollte.
• Benutzer. Jeder Agent-Key eines Mitglieds — ein Onboarding-Briefing oder eine strengere Haltung für eine einzelne Person.
• Key. Genau ein Agent-Key, also das, was eine Bindung bisher schon tat.

Die Auflösung ist deterministisch, denn die Injektionsreihenfolge verändert den Prompt. Sluis bildet die Vereinigung der drei Bereiche, prüft jedes Plugin genau wie bei den Tools erneut, verwirft doppelte Versionen und ordnet zuerst Organisation, dann Benutzer, dann Key: Die allgemeine Regel wird zuerst gelesen, die engere Ausnahme zuletzt. Kontext wird wortgetreu injiziert, ein Skill als benannter Abschnitt. Auf dem Claude-Ingress werden die Blöcke vorangestellt an system, in beiden von dieser API erlaubten Formen; auf dem Codex-Ingress an instructions, oder als führende developer-Anweisung, wenn die Anfrage keine trägt.

Alles, was in eine Anfrage injiziert wird, passt in 32 KiB. Darüber wird die Anfrage mit einem 422 abgewiesen, das die Plugins nennt, die das Limit überschritten haben. Nichts wird stillschweigend gekürzt: Eine halbe Anweisung ist schlimmer als keine, und eine Organisation, die eine Regel für wirksam hält, muss erfahren, wenn sie es nicht ist.

Injizierter Text wird vom Datenschutz nicht umgeschrieben, und die Reihenfolge ist einseitig: Zuerst wird der Prompt des Entwicklers geprüft und pseudonymisiert, dann wird Ihre Richtlinie vorangestellt. Diese Blöcke sind Ihr eigener geregelter Inhalt, in Ihrer eigenen Console verfasst — es gibt niemanden, vor dem sie zu schützen wären, und sie zu tokenisieren würde zerstören, was sie sagen. „Vor dem Einfügen an security@example.com eskalieren“, umgeschrieben zu „vor dem Einfügen an «EMAIL_1» eskalieren“, ist keine befolgbare Anweisung mehr.

Diese beiden Arten werden in der Console verfasst und tragen keine Signatur. Eine Signatur verhindert, dass ein Manifest ein geregeltes Credential auf einen Endpunkt richtet, den niemand genehmigt hat; ein Textblock richtet sich auf nichts. Alles andere, was eine Registrierung vertrauenswürdig macht, gilt weiter: Eine Version ist unveränderlich, ihre exakten Bytes werden gehasht, und die Zeile hält fest, wer sie geschrieben hat und wann. Ein Manifest mit einem MCP-Eintrag behält die verpflichtende Signatur und die Prüfung des registrierten Signaturschlüssels bei jeder Anfrage. Der Plugins-Tab zeigt, welche der beiden eine Version ist — „in der Console verfasst“ ist damit eine genannte Tatsache und kein fehlendes Feld — und er zeigt eine Vorschau der aufgelösten Blöcke in der Reihenfolge, in der das Gateway sie für einen gewählten Key oder ein gewähltes Mitglied injiziert.

Jeder injizierte Block hinterlässt eine Markierung auf der versiegelten Audit-Zeile, context:<plugin_id>@<version>#<digest8>, wobei der Digest die ersten acht Zeichen des Hashes dieser Version sind. Weil eine Version unveränderlich ist, genügt die Markierung, um den exakten an das Modell übergebenen Text zu rekonstruieren: Der Audit-Trail allein beantwortet, ob ein Agent zum Zeitpunkt seines Handelns einer bestimmten Regel unterlag.

Cursor ist die offen benannte Lücke. Sein Transport /agent/cursor ist ein proprietäres Binärschema: Sluis kann den Text in diesen Frames finden und umschreiben — so funktioniert dort der Datenschutz —, aber es kann nicht erkennen, welches Feld der System-Prompt ist, und in ein geratenes Feld zu schreiben würde die Anfrage beschädigen statt sie zu regeln. Auf diesem Ingress wird daher nichts injiziert, und ein Cursor-Turn trägt Ihren Kontext nur, wenn der Client des Entwicklers ihn selbst sendet. Die Vorschau in der Console sagt dasselbe.

Governance, die weiterhin gilt

Agent-Verkehr ist gewöhnlicher Sluis-Verkehr, mit einer Ausnahme. Pseudonymisierung und DLP laufen vor dem Dispatch, auch in den Protobuf-Frames von Cursor, Rate- und Budgetgrenzen des Keys greifen pro Anfrage, die MCP-Tools werden Aufruf für Aufruf freigegeben, und jeder Modell- und Tool-Aufruf wird auditiert und gemessen. Die Ausnahme ist Residency: Auf der Agent-Ebene wird die Policy aufgezeichnet und nicht erzwungen, aus dem Grund im Hinweis am Anfang dieser Seite.

Es gelten dieselben Regeln wie unter Datenschutz und Budgets & Caching beschrieben, und sie sind Organisations-Policy: ein Agent-Key kann sie nicht lockern.

Abrechnung

Jedes aktive von Sluis verwaltete Anbieterkonto kostet 16,50 € Listenpreis pro Kalendermonat, höchstens einmal pro Konto und Monat. Der Betrag geht an Ihre oberste Abrechnungswurzel und erscheint als eigene Rechnungszeile, getrennt von der gemessenen Nutzung. Mehrwertsteuer und der Zuschlag für die Zahlungsart gelten genau wie im Rest der Rechnung.

Trennen stoppt die folgenden Monate. Wird dasselbe Upstream-Abonnement wieder verbunden, nutzt Sluis das bestehende Konto, statt ein zweites abrechenbares anzulegen: Trennen und erneutes Verbinden im selben Monat kostet einmal.

Die Gateway-Nutzung selbst bleibt verbrauchsabhängig abgerechnet, genau wie bei API-Keys.

Verfügbarkeit

Die Agent-Harness-Ansicht erscheint in der Console, sobald das Rollout-Flag agent_harness für Ihre Organisation aktiviert ist. Sprechen Sie uns an, wenn Sie sie nicht sehen.

Fehlersuche