XGuard — Secretless Agent Gateway

Kanonische Produktions-API

https://api.xguardgate.com

Kanonische Identität — v5.0.2: XGuard Secretless Agent Gateway. Secretless Egress ist das primäre Produkt. Action Rail und x402-Facilitator-Routing sind Kompatibilitätsschienen. Historische Beschreibungen, die XGuard ACE, Solana/BAM speed bumps, Child Safety, Web Extractor, Universal Facilitator Gateway, High-Velocity x402 Facilitator oder eine generische reine Ausgaben-Kontrollebene betreffen, sind nicht die aktuelle XGuard-Produktidentität. Siehe CANONICAL_IDENTITY.md.

XGuard hält wiederverwendbare Upstream-Zugangsdaten von KI-Agenten fern. Betreiber speichern einmalig Zugangsdaten für Stripe, GitHub, OpenAI, Anthropic, Slack, Notion, Cloudflare, Gemini oder eine benutzerdefinierte API und geben dem Agenten dann nur eine kurzlebige, bereichsgebundene XGuard-Fähigkeit.

Operator secret
     ↓
Encrypted XGuard credential vault
     ↓
Scoped capability
     ↓
AI agent
     ↓
XGuard Secretless Egress
     ↓
credential injected server-side
     ↓
upstream API

Der Agent erhält niemals die wiederverwendbaren Upstream-Zugangsdaten.

XGuard wird zu einem tatsächlichen Engpass, wenn ein Betreiber die wiederverwendbaren Zugangsdaten nur in XGuard aufbewahrt und Fähigkeiten delegiert, anstatt diese Zugangsdaten weiterzugeben. XGuard erhebt keinen Anspruch auf Kontrolle über unzusammenhängenden Internetverkehr.

Warum Secretless Egress

Ein wiederverwendbares Bearer-Token in einem autonomen Agenten kann kopiert, protokolliert, in den Kontext gelegt, außerhalb der beabsichtigten Anfrage verwendet oder an ein nicht vertrauenswürdiges Werkzeug weitergegeben werden. XGuard ändert das Primitiv von Geheimnisbesitz zu bereichsgebundenem Fähigkeitsbesitz.

Die aktuelle Egress-Grenze bietet:

• verschlüsselte Speicherung wiederverwendbarer Zugangsdaten;

• Provider-Voreinstellungen für OpenAI, Anthropic, GitHub, Stripe, Slack, Notion, Cloudflare und Gemini;

• benutzerdefinierte, headerbasierte Zugangsdaten, die auf explizite öffentliche HTTPS-Hosts beschränkt sind;

• kurzlebige Fähigkeiten;

• exakte Bindung an die HTTPS-Origin;

• Pfadpräfix-Zulassungslisten;

• HTTP-Methoden-Zulassungslisten;

• maximale Aufrufzahlen;

• Usage-Credit-Abrechnung vor der Freigabe des Geheimnisses und vor dem ausgehenden Netzwerk-Egress;

• keine automatische Weiterleitung von Zugangsdaten bei Redirects;

• Blockierung privater/lokaler Ziele;

• automatische Injektion von Idempotency-Key für unsichere Methoden;

• kein blindes automatisches Wiederholen nach Netzwerk-Mehrdeutigkeit;

• MCP-Erkennung und Egress-Ausführung, ohne die Bereitstellung von Zugangsdaten gegenüber dem Modellkontext offenzulegen.

Related MCP server: AgentGate

Egress API

Maschinenlesbarer Vertrag:

GET https://api.xguardgate.com/v1/egress
GET https://api.xguardgate.com/.well-known/xguard-egress.json
GET https://api.xguardgate.com/.well-known/xguard-egress-key.json
GET https://api.xguardgate.com/v1/egress/providers

1. Der Betreiber speichert wiederverwendbare Zugangsdaten

Die Bereitstellung von Zugangsdaten ist bewusst eine Betreiber-API und kein MCP-Tool.

POST /v1/egress/credentials
X-XGuard-Key: <usage-credit-key>
Content-Type: application/json

{
  "provider": "github",
  "value": "<github-token>",
  "label": "production-github",
  "allowed_paths": ["/repos/"],
  "allowed_methods": ["GET", "POST"]
}

XGuard gibt nur Zugangsdaten-Metadaten wie xcred_... zurück; das wiederverwendbare Geheimnis wird nicht zurückgegeben.

2. Der Betreiber gibt eine kurzlebige Fähigkeit aus

POST /v1/egress/capabilities
X-XGuard-Key: <usage-credit-key>
Content-Type: application/json

{
  "credential_id": "xcred_...",
  "target_origin": "https://api.github.com",
  "path_prefix": "/repos/",
  "allowed_methods": ["GET", "POST"],
  "ttl_seconds": 300,
  "max_calls": 10
}

Die zurückgegebene xgc_...-Fähigkeit ist das, was der Agent erhält.

3. Der Agent führt die Anfrage ohne das Upstream-Geheimnis aus

POST /v1/egress/fetch
Content-Type: application/json

{
  "capability": "xgc_...",
  "target": "https://api.github.com/repos/org/repo/issues",
  "method": "POST",
  "body_json": {
    "title": "Example"
  }
}

XGuard validiert den Fähigkeitsumfang und die Abrechnung, injiziert die GitHub-Zugangsdaten serverseitig, sendet eine HTTPS-Anfrage und legt das wiederverwendbare GitHub-Token niemals gegenüber dem Agenten offen.

Preisvertrag:

GET /v1/egress/pricing

Die aktuelle Konfiguration verbraucht 1 XGuard Usage Credit pro autorisiertem, zugangsdatengestütztem Egress-Versuch. Die Abrechnung wird vor der Entschlüsselung der Zugangsdaten und vor dem ausgehenden Netzwerk-Egress verbindlich zugesagt. Wenn die Abrechnung nicht zugesagt werden kann, wird keine Upstream-Anfrage gesendet.

MCP

Kanonischer MCP-Endpunkt:

https://api.xguardgate.com/mcp

Die für Agenten verfügbaren Tools umfassen:

xguard_secretless_egress
xguard_egress_fetch
xguard_action_rail

Die Erstellung wiederverwendbarer Zugangsdaten ist bewusst nicht als MCP-Tool verfügbar gemacht.

Action Rail darunter

Secretless Egress ist die primäre Produktgrenze. XGuard Action Rail bleibt darunter für strengere Ausführungskontrollen rund um Zahlungen, Käufe, Buchungen, Nachrichten, Bereitstellungen, Löschungen, API-Schreibvorgänge und Tool-Aufrufe verfügbar.

POST /v1/mandates
POST /v1/actions/permits
POST /v1/actions/execute
GET  /v1/actions/permits/{permit_id}

Action Rail ergänzt bereichsgebundene Mandate, anfragegebundene kryptografische Berechtigungen, Replay-Ablehnung, dauerhaften Ausführungszustand und Belege.

Universelle und Edge-Bereitstellung

Für eine vom Betreiber kontrollierte Infrastruktur kann XGuard auch vor einer Origin platziert werden:

Internet / Ingress
      ↓
XGuard Universal Gate
      ↓
private origin

Das Repository enthält Cloudflare Edge Gate, portable Node-Bereitstellung, Docker, Docker Compose, Kubernetes und OpenAPI AutoGate-Komponenten.

Native x402-Kompatibilität

x402 bleibt eine Kompatibilitätsschiene, nicht die Definition von XGuard.

GET  /supported
POST /verify
POST /settle
GET  /facilitator
GET  /.well-known/x402
GET  /v1/facilitator/route

XGuard bleibt ein nicht verwahrendes x402-v2-Facilitator-Gateway mit fähigkeitsbewusstem Routing, Replay-Schutz, Base-USDC-Abgleich und Fail-Closed-Abwicklungsverhalten bei Mehrdeutigkeit.

Sicherheitsmodell

• wiederverwendbare Upstream-Zugangsdaten werden im Ruhezustand mit AES-GCM-Schlüsseln pro Datensatz verschlüsselt, die von einer XGuard-RSA-OAEP-Autorität umhüllt werden;

• Geheimniswerte sind nicht in Agentenfähigkeiten enthalten;

• XGuard-Usage-Credit-Schlüssel des Betreibers sind in den Fähigkeitszustand verschlüsselt und werden nicht an Agenten ausgehändigt;

• Fähigkeiten binden eine Origin, einen Pfadpräfix, Methoden, Ablaufdatum und maximale Aufrufzahlen;

• benutzergelieferte Header können den injizierten Zugangsdaten-Header oder XGuard-Kontroll-Header nicht überschreiben;

• private/lokale Ziele und XGuard-Selbstziele werden blockiert;

• Weiterleitungen werden nicht automatisch mit injizierten Zugangsdaten verfolgt;

• die Abrechnung wird vor der Entschlüsselung des Geheimnisses und vor dem Netzwerk-Egress verbindlich zugesagt;

• unsichere Methoden erhalten einen von XGuard generierten Idempotency-Key, wenn der Aufrufer keinen bereitgestellt hat;

• XGuard wiederholt eine zugangsdatengestützte Anfrage nach einer Netzwerk-Mehrdeutigkeit nicht automatisch.

Maschinen-Discovery

GET /.well-known/xguard-egress.json
GET /.well-known/xguard-actions.json
GET /.well-known/xguard.json
GET /.well-known/ai-plugin.json
GET /.well-known/agent-card.json
GET /architecture
GET /v1/protocols
GET /openapi.json
GET /llms.txt
GET /skill.md
GET /sitemap.xml

Produktions-Domains

https://xguardgate.com
https://api.xguardgate.com

Die Cloudflare-Worker-Konfiguration deaktiviert die öffentliche workers.dev-Route, sodass die Produktionsidentität von XGuard auf die benutzerdefinierten XGuard-Domains beschränkt ist.

Repository:

https://github.com/moelayyan90/XGuard