Access

„Es ist ein ziemlich raffiniertes kleines Dienstprogramm.“ — ich

Hin und wieder muss ein Agent daran erinnert werden, dass dies existiert.

Alles unterhalb dieser Linie wurde von den Bots entworfen.

Ein Bearer-Token für alle Ihre Dienste.

Access bietet Agenten und Skripten sicheren Zugriff auf OAuth- und API-Schlüssel-basierte Dienste, ohne dass Anmeldedaten direkt verarbeitet werden müssen. Speichern Sie Ihre Geheimnisse, aktualisieren Sie Tokens automatisch, proxen Sie Anfragen, protokollieren Sie alles — über eine stabile Schnittstelle via HTTP und MCP.

flowchart LR
    A[Any MCP client\nor HTTP caller] -->|Bearer token| B["Access\n(Next.js + Postgres)"]
    B -->|OAuth 2.0| C[Google · GitHub · Sentry · Oura]
    B -->|API key| D[HubSpot · Linear · Jira · Stripe\nNotion · Apollo · Cal · Porkbun]
    B -->|Token| E[Slack · Cloudflare · Vercel\nGitLab · AWS]

Was es tut

Sie legen jeden Anmeldedaten-Satz darin ab — API-Schlüssel, OAuth-Tokens, Bot-Tokens, Agenten-Anmeldedaten, Dienstgeheimnisse, was auch immer Ihre Agenten und Skripte benötigen. Dann entscheiden Sie, wer was bekommt.

• Berechtigungen pro Agent und pro Flotte — jeder Agent oder jede Gruppe erhält ein eigenes Token mit begrenztem Zugriff. Coding-Agenten sehen GitHub und Linear. Kommunikations-Agenten sehen Gmail und Slack. Ops-Agenten sehen AWS. Verwaltung über die Admin-UI — keine Konfigurationsdateien, kein CLI-Jonglieren.

• Speichert alles verschlüsselt — API-Schlüssel, OAuth-Tokens, Bot-Tokens, Agent-zu-Agent-Anmeldedaten, Dienstgeheimnisse. AES-256-GCM im Ruhezustand, HMAC-gehashte Zugriffstokens.

• Verwaltet OAuth — Token-Aktualisierung, Zustimmungsabläufe, Google-Multi-Account — Ihr Agent nimmt nie daran teil.

• Proxt API-Aufrufe — für Dienste mit Adaptern rufen Agenten Access auf und erhalten JSON zurück, ohne jemals den zugrunde liegenden Schlüssel zu sehen.

• Stellt Anmeldedaten direkt bereit — für alles andere ziehen Agenten Schlüssel über /bootstrap oder /secrets/by-env/WAS_AUCH_IMMER.

• Protokolliert alles — jeden Zugriff auf Geheimnisse, jeden API-Aufruf, jeden Authentifizierungsversuch, mit Akteur und IP.

• Bootstrapping von Sitzungen — ein /bootstrap-Aufruf gibt einem Agenten nur das, was er sehen darf — Umgebungsvariablen, Dokumente und Kontext.

Der Idealfall: Agent sendet Bearer-Token → Access verwaltet Authentifizierung, Aktualisierung und Proxying → Agent erhält JSON oder ein Bootstrap-Paket zurück. Das ist alles.

Wie es aussieht

Dashboard — Dienste, Schlüssel, Agenten und Audit-Verlauf auf einen Blick:

Agenten-Berechtigungen — jeder Agent erhält sein eigenes Token mit begrenzten Zugriffsberechtigungen:

Agenten-Details — Vertrauensstufe, Token-Präfix, letzte Verwendung und Anzahl der Berechtigungen:

30-Sekunden-Beispiel

# Set once per session (don't paste tokens directly in commands)
export TOKEN="your-token"
export ACCESS="https://your-access-instance"

# Your agent searches Gmail through Access
curl -H "Authorization: Bearer $TOKEN" "$ACCESS/api/v1/google/gmail?action=search&q=from:alice&account=work"

# Or bootstraps an entire session in one call
curl -H "Authorization: Bearer $TOKEN" "$ACCESS/api/v1/bootstrap"

Mit MCP erhält Ihr Agent Tools wie gmail_search, calendar_list, drive_list — keine Konfiguration pro Dienst, keine abgelaufenen Tokens, keine Verwaltung von Anmeldedaten.

Für wen ist das gedacht?

Gut geeignet für:

• Ausführung von KI-Agenten (Claude Code, Cursor, Gemini CLI, Codex) über mehrere Sitzungen oder Maschinen hinweg.

• Multi-Agenten-Setups, bei denen Agenten Anmeldedaten für andere Agenten, Bots und interne Dienste benötigen.

• Selbst gehostete Setups für Einzelpersonen oder kleine Teams.

• Multi-Dienst-Workflows, bei denen Agenten Gmail, Slack, GitHub usw. benötigen.

• Jeden, der es leid ist, Agenten-Sitzungen mit verstreuten .env-Dateien zu starten.

Nicht geeignet für:

• Enterprise-Geheimnisverwaltung mit Compliance-Anforderungen (verwenden Sie HashiCorp Vault).

• Infrastruktur mit hoher Compliance und KMS/HSM-Anforderungen.

• IAM für große Teams oder Multi-Tenant-Zugriffskontrolle.

Wie es sich von einem Passwort-Manager unterscheidet: 1Password speichert Anmeldedaten für Menschen zum Kopieren und Einfügen. Access speichert Anmeldedaten und verwendet sie — durch Proxying von API-Aufrufen, Aktualisierung von OAuth-Tokens und Bootstrapping von Agenten-Sitzungen. Ihr Agent sieht niemals den Rohschlüssel für geproxte Dienste.

Sicherheitsstatus

Wovor Access schützt:

• Agenten, die Rohdaten sehen oder speichern.

• Abgelaufene OAuth-Tokens, die Agenten-Sitzungen unterbrechen.

• Nicht geprüfte Zugriffe auf Anmeldedaten über Maschinen hinweg.

• Geheimnisse im Klartext in Datenbanken (AES-256-GCM-Verschlüsselung im Ruhezustand).

• Brute-Force-Token-Raten (HMAC-SHA256 gehasht, Vergleich in konstanter Zeit).

Wovor Access nicht schützt:

• Eine kompromittierte Access-Instanz (wenn jemand Ihren Server bekommt, bekommt er alles).

• Cloud-Grade-Schlüsselverwaltung (noch keine KMS/HSM-Integration — siehe Roadmap).

• Multi-Tenant-Isolierung (dies ist ein System für einen einzelnen Besitzer).

• Angriffe auf Netzwerkebene (hinter HTTPS bereitstellen, Firewall verwenden).

Warum nicht einfach .env-Dateien verwenden?

• OAuth-Tokens laufen ab. Google-Zugriffstokens halten 60 Minuten. Ihr Agent kann sie nicht aktualisieren — Access kann das.

• Anmeldedaten verstreuen sich. Jede Agenten-Sitzung benötigt eine eigene Kopie. Wenn Sie einen Schlüssel rotieren, aktualisieren Sie ihn an 6 Stellen.

• Kein Audit-Trail. Welcher Agent hat auf welchen Dienst zugegriffen? Wann? Von wo? Keine Ahnung.

• Bootstrapping ist mühsam. Jede neue Sitzung beginnt mit dem Laden von Umgebungsvariablen in der Hoffnung, dass nichts abgelaufen ist.

Bestehende Lösungen (und wo Access hineinpasst)

Es gibt echte Werkzeuge für Teile dieses Problems. Die meisten lösen nur einen Teilbereich:

• Geheimnis-Manager (1Password CLI, Doppler, Infisical) — injizieren statische Geheimnisse zur Laufzeit via op run / doppler run. Großartig für API-Schlüssel. Verarbeiten keine OAuth-Aktualisierung oder API-Proxying.

• Workload-Identität / OIDC (GitHub Actions OIDC) — vermeiden langlebige Geheimnisse vollständig, indem Identität für kurzlebige Anmeldedaten nachgewiesen wird. Großartig für CI/CD. Hilft nicht bei lokalen Agenten-Sitzungen.

• Dynamische Geheimnisse (Vault dynamic secrets) — erstellen zeitlich begrenzte Anmeldedaten bei Bedarf. Ernsthafte Infrastruktur. Overkill für die meisten Agenten-Setups.

• OAuth-Broker (Nango, Composio) — verarbeiten OAuth-Autorisierung, Token-Speicherung und Aktualisierung. Cloud-First-Plattformen mit eigenen Dashboards und Abrechnung.

Reife Organisationen teilen das Problem auf Vault + OIDC + OAuth-Broker + interne Plattform-Tools auf. Kleinere Teams verwenden 1Password/Doppler für statische Geheimnisse und leiden weiterhin unter OAuth.

Access fasst diese Ebenen in einer einzigen selbst gehosteten App zusammen: Anmeldedaten speichern, OAuth aktualisieren, API-Aufrufe proxen, Agenten-Sitzungen booten, alles auditieren. Es ist weniger sicher als Vault + KMS, aber es ist eine Sache statt vier — und es funktioniert tatsächlich.

Schnellstart

Voraussetzungen

• Node.js 20+

• PostgreSQL (oder verwenden Sie das enthaltene Docker Compose)

• Eine Google Cloud OAuth-App (wenn Sie Google API-Proxying wünschen)

1. Klonen und installieren

git clone https://github.com/Scottpedia0/access.git
cd access
npm install

2. Datenbank einrichten

# Option A: Use Docker Compose
docker compose up -d

# Option B: Use your own Postgres
# Set DATABASE_URL and DIRECT_DATABASE_URL in .env

3. Umgebung konfigurieren

cp .env.example .env

# Generate required secrets
openssl rand -base64 32  # -> SECRET_ENCRYPTION_KEY
openssl rand -base64 32  # -> NEXTAUTH_SECRET
openssl rand -base64 32  # -> CONSUMER_TOKEN_HASH_SECRET

Bearbeiten Sie .env mit Ihren Werten. Mindestens benötigen Sie:

• DATABASE_URL / DIRECT_DATABASE_URL

• SECRET_ENCRYPTION_KEY

• NEXTAUTH_SECRET

• OWNER_EMAILS (durch Kommas getrennte Liste von E-Mails, die sich anmelden dürfen)

• Einen Authentifizierungsanbieter (Google OAuth, E-Mail-Magic-Link oder Besitzer-Passwort)

4. Migrationen ausführen und Seed

npx prisma migrate deploy
npm run db:seed  # Creates example services and a consumer token

5. App starten

npm run dev

Besuchen Sie http://localhost:3000 und melden Sie sich mit einer E-Mail aus Ihrer OWNER_EMAILS-Liste an.

6. Agenten-Skill + MCP-Konfiguration installieren

bash scripts/install.sh

Dies erkennt Ihre installierten Agenten-Harnesses (Claude Code, Cursor, Gemini CLI, Windsurf, VS Code, Codex), installiert den Health-Check-Skill und zeigt Ihnen die MCP-Konfiguration für jeden an. Sie können jeden Schritt akzeptieren oder ablehnen.

Unterstützte Dienste

27 Dienst-Endpunkte über /api/v1/*. Jeder Adapter verarbeitet die Authentifizierung und leitet Anfragen an den Upstream weiter.

Google Workspace (OAuth 2.0, Multi-Account) — Gmail, Calendar, Drive, Sheets, Docs, Contacts, Analytics, Search Console, Tag Manager, Admin Reports, Profile

Entwickler-Tools — GitHub, GitLab, Linear, Jira, Notion, Sentry, Vercel

Business — HubSpot, Slack, Stripe (schreibgeschützt), Apollo.io, Cal.com

Infrastruktur — AWS (S3, EC2, Lambda, CloudWatch — optionale SDK-Abhängigkeiten), Cloudflare

Sonstiges — Oura Ring, Porkbun

Google-Dienste unterstützen mehrere Konten — konfigurieren Sie dies über die Umgebungsvariable GOOGLE_ACCOUNTS (z. B. work:me@company.com,personal:me@gmail.com). Das Hinzufügen eines neuen Adapters dauert etwa 100 Zeilen — siehe Adding a New Service.

Kern-Endpunkte

Dies sind keine Dienst-Proxys — sie sind Access selbst:

Authentifizierung

Access unterstützt drei Token-Typen für die Agenten-Authentifizierung:

Berechtigungen pro Agent oder Flotte

Consumer-Tokens ermöglichen es Ihnen, den Zugriff nach Rolle zu segmentieren. Jeder Consumer erhält seine eigene Identität, sein eigenes Token und begrenzte Berechtigungen:

Coding agents (Claude Code, Cursor)  →  GitHub, Linear, Sentry
Comms agents                         →  Gmail, Slack, Calendar
Ops agents                           →  AWS, Cloudflare, Vercel
Intake-only (team members)           →  Write keys, can't read anything

Berechtigungen funktionieren auf zwei Ebenen — ganzer Dienst (Agent sieht alles in diesem Dienst) oder einzelne Geheimnisse (Agent sieht nur bestimmte Schlüssel). Wenn ein Agent /bootstrap aufruft, erhält er nur das zurück, was er sehen darf.

# Search Gmail with a global token
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "http://localhost:3000/api/v1/google/gmail?action=search&q=from:alice&account=work"

# Bootstrap an agent session — pull only what this token is authorized for
curl -H "Authorization: Bearer YOUR_TOKEN" \
  "http://localhost:3000/api/v1/bootstrap"

Die menschliche Authentifizierung für die Admin-UI verwendet Google OAuth, E-Mail-Magic-Links oder ein einfaches Passwort — konfiguriert über Umgebungsvariablen. Nur E-Mails in OWNER_EMAILS können sich anmelden.

Hinzufügen eines neuen Dienstes

Jeder Proxy-Adapter ist ein Next.js-Routen-Handler unter src/app/api/v1/<service>/route.ts. Um einen hinzuzufügen:

1. Erstellen Sie src/app/api/v1/your-service/route.ts

2. Verwenden Sie authenticateRequestActor() von @/lib/access für die Authentifizierung

3. Lesen Sie den API-Schlüssel aus dem verschlüsselten Speicher (via Prisma) oder Umgebungsvariablen

4. Proxyen Sie die Anfrage an die Upstream-API

5. Geben Sie das Ergebnis zurück

Die meisten Adapter sind unter 100 Zeilen lang. Siehe src/app/api/v1/hubspot/route.ts für ein sauberes Beispiel.

Agenten-Anweisungen

AGENTS.md in diesem Repository hat zwei Abschnitte:

1. Für Agenten, die an Access entwickeln — Architektur, Muster, Datenmodell, Befehle

2. Für Agenten, die Access verwenden — ein Block zum Kopieren für Ihre CLAUDE.md oder Agenten-Anweisungen, der Ihren Agenten sagt, wie sie booten, Anmeldedaten ziehen und Proxy-Endpunkte verwenden sollen

Kopieren Sie den Abschnitt „Für Agenten, die Access verwenden“ in die Anweisungsdatei Ihres Agenten und setzen Sie ACCESS_BASE_URL und ACCESS_TOKEN in Ihrer Umgebung.

MCP-Server

Access enthält einen MCP-Server (mcp-server.mjs), der Google Workspace-Tools über stdio-Transport bereitstellt. Funktioniert mit jedem MCP-kompatiblen Client.

Fügen Sie die folgende Konfiguration zu Ihrem Client hinzu. Das JSON ist gleich — nur der Dateipfad ändert sich je nach Client: