Access

「ちょっと気の利いた小さなユーティリティだ。」 — 私

時折、エージェントにこの存在を思い出させる必要がある。

この線より下のすべてはボットによって作成されました。

Bearerトークン1つで、すべてのサービスを管理。

Accessは、エージェントやスクリプトが認証情報を直接扱うことなく、OAuthやAPIキーで保護されたサービスに安全にアクセスできるようにします。シークレットの保存、トークンの自動更新、リクエストのプロキシ、すべてのアクティビティの監査を、HTTPおよびMCP経由の1つの安定したインターフェースで実現します。

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]

何ができるのか

APIキー、OAuthトークン、ボットトークン、エージェント認証情報、サービスシークレットなど、エージェントやスクリプトが必要とするあらゆる認証情報をここに保存します。そして、誰に何を許可するかを決定します。

• エージェントおよびフリートごとの権限設定 — 各エージェントやグループは、スコープ付きアクセス権を持つ独自のトークンを取得します。コーディングエージェントはGitHubとLinearを参照し、コミュニケーションエージェントはGmailとSlackを参照し、OpsエージェントはAWSを参照します。管理UIから設定可能で、設定ファイルやCLIの煩雑な操作は不要です。

• すべてを暗号化して保存 — APIキー、OAuthトークン、ボットトークン、エージェント間認証情報、サービスシークレットを保存します。保存時はAES-256-GCM、アクセストークンはHMACハッシュ化されます。

• OAuthを処理 — トークンの更新、同意フロー、Googleのマルチアカウント対応など、エージェントが直接関与することはありません。

• API呼び出しをプロキシ — アダプターがあるサービスの場合、エージェントはAccessを介してJSONを受け取るため、基盤となるキーを直接見ることはありません。

• 認証情報を直接提供 — その他のサービスについては、エージェントは /bootstrap または /secrets/by-env/WHATEVER を通じてキーを取得します。

• すべてをログに記録 — シークレットへのアクセス、API呼び出し、認証試行のすべてを、実行者とIPアドレスとともに記録します。

• セッションをブートストラップ — 1回の /bootstrap 呼び出しで、エージェントは許可された環境変数、ドキュメント、コンテキストのみを取得します。

ハッピーパス: エージェントがBearerトークンを送信 → Accessが認証、更新、プロキシを処理 → エージェントがJSONまたはブートストラップバンドルを受け取る。これだけです。

画面イメージ

ダッシュボード — サービス、キー、エージェント、監査履歴を一目で確認：

エージェントの権限設定 — 各エージェントは、スコープ付きアクセス権を持つ独自のトークンを取得：

エージェント詳細 — 信頼レベル、トークンプレフィックス、最終使用日時、付与された権限数：

30秒でわかる例

# 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"

MCPを使用すると、エージェントは gmail_search、calendar_list、drive_list などのツールを利用できます。サービスごとの設定や期限切れトークン、認証情報管理に悩まされることはありません。

対象ユーザー

適しているケース:

• 複数のセッションやマシンでAIエージェント（Claude Code, Cursor, Gemini CLI, Codexなど）を実行している場合

• エージェントが他のエージェント、ボット、内部サービスのために認証情報を必要とするマルチエージェント構成

• 個人または小規模チームのセルフホスト環境

• エージェントがGmail、Slack、GitHubなどを必要とするマルチサービスワークフロー

• .env ファイルが散乱したエージェントセッションのブートストラップに疲れている方

適していないケース:

• コンプライアンス要件があるエンタープライズレベルのシークレット管理（HashiCorp Vaultを使用してください）

• KMS/HSM要件がある高コンプライアンスなインフラ

• 大規模チームのIAMやマルチテナントアクセス制御

パスワードマネージャーとの違い: 1Passwordは人間がコピー＆ペーストするための認証情報を保存します。Accessは認証情報を保存し、それらを「使用」します。API呼び出しのプロキシ、OAuthトークンの更新、エージェントセッションのブートストラップを行います。プロキシされたサービスに対して、エージェントが生のキーを見ることはありません。

セキュリティ体制

Accessが防ぐもの:

• エージェントが生の認証情報を見たり保存したりすること

• 期限切れのOAuthトークンによってエージェントセッションが中断されること

• マシンをまたいだ認証情報アクセスの監査漏れ

• データベース内のプレーンテキストのシークレット（保存時はAES-256-GCMで暗号化）

• ブルートフォースによるトークン推測（HMAC-SHA256ハッシュ化、定数時間比較）

Accessが防がないもの:

• Accessインスタンス自体の侵害（サーバーが乗っ取られた場合、すべてが漏洩します）

• クラウドグレードのキー管理（KMS/HSM統合は未実装 — ロードマップを参照）

• マルチテナント分離（これは単一所有者システムです）

• ネットワークレベルの攻撃（HTTPSの背後にデプロイし、ファイアウォールを使用してください）

なぜ .env ファイルではいけないのか？

• OAuthトークンの期限切れ。 Googleのアクセストークンは60分で期限が切れます。エージェントは更新できませんが、Accessなら可能です。

• 認証情報の散乱。 各エージェントセッションにコピーが必要です。キーをローテーションするたびに6箇所を更新することになります。

• 監査証跡がない。 どのエージェントがどのサービスにアクセスしたか？いつ？どこから？全く分かりません。

• ブートストラップが面倒。 新しいセッションのたびに環境変数を読み込み、何も期限切れになっていないことを祈る必要があります。

既存のソリューション（Accessの立ち位置）

この問題の一部を解決するツールは存在しますが、ほとんどが一部のみをカバーしています：

• シークレットマネージャー (1Password CLI, Doppler, Infisical) — op run / doppler run を介して実行時に静的シークレットを注入します。APIキーには最適ですが、OAuthの更新やAPIプロキシは処理しません。

• ワークロードID / OIDC (GitHub Actions OIDC) — 短命な認証情報のためにIDを証明することで、長期的なシークレットを回避します。CI/CDには最適ですが、ローカルのエージェントセッションには役立ちません。

• 動的シークレット (Vault dynamic secrets) — 必要に応じて期限付きの認証情報を発行します。本格的なインフラであり、ほとんどのエージェント構成には過剰です。

• OAuthブローカー (Nango, Composio) — OAuth認証、トークン保存、更新を処理します。独自のダッシュボードと課金体系を持つクラウドファーストのプラットフォームです。

成熟した組織は、Vault + OIDC + OAuthブローカー + 内部プラットフォームツールを組み合わせて問題を解決します。小規模チームは静的シークレットに1Password/Dopplerを使用し、OAuthで苦労しています。

Accessはこれらの層を1つのセルフホストアプリに統合します。認証情報の保存、OAuthの更新、API呼び出しのプロキシ、エージェントセッションのブートストラップ、すべてを監査します。Vault + KMSよりはセキュリティが劣りますが、4つのツールを管理する代わりに1つで済み、実際に動作します。

クイックスタート

前提条件

• Node.js 20+

• PostgreSQL (または付属のDocker Composeを使用)

• Google Cloud OAuthアプリ (Google APIプロキシを使用する場合)

1. クローンとインストール

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

2. データベースのセットアップ

# 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. 環境設定

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

.env を編集して値を設定します。最低限必要なもの：

• DATABASE_URL / DIRECT_DATABASE_URL

• SECRET_ENCRYPTION_KEY

• NEXTAUTH_SECRET

• OWNER_EMAILS (ログインを許可するメールアドレスのカンマ区切りリスト)

• 1つの認証プロバイダー (Google OAuth、メールマジックリンク、または所有者パスワード)

4. マイグレーションとシードの実行

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

5. アプリの起動

npm run dev

http://localhost:3000 にアクセスし、OWNER_EMAILS リストにあるメールアドレスでサインインします。

6. エージェントスキルのインストール + MCP設定

bash scripts/install.sh

インストールされているエージェントハーネス（Claude Code, Cursor, Gemini CLI, Windsurf, VS Code, Codex）を検出し、ヘルスチェックスキルをインストールし、それぞれのMCP設定を表示します。各ステップで承認または拒否が可能です。

対応サービス

/api/v1/* 配下に27のサービスエンドポイントがあります。各アダプターは認証を処理し、アップストリームへのリクエストをプロキシします。

Google Workspace (OAuth 2.0, マルチアカウント) — Gmail, Calendar, Drive, Sheets, Docs, Contacts, Analytics, Search Console, Tag Manager, Admin Reports, Profile

開発者ツール — GitHub, GitLab, Linear, Jira, Notion, Sentry, Vercel

ビジネス — HubSpot, Slack, Stripe (読み取り専用), Apollo.io, Cal.com

インフラ — AWS (S3, EC2, Lambda, CloudWatch — オプションのSDK依存関係), Cloudflare

その他 — Oura Ring, Porkbun

Googleサービスはマルチアカウントをサポートしています。GOOGLE_ACCOUNTS 環境変数で設定してください（例: work:me@company.com,personal:me@gmail.com）。新しいアダプターの追加は約100行で可能です。新しいサービスの追加 を参照してください。

コアエンドポイント

これらはサービスプロキシではなく、Access自体の機能です：

認証

Accessはエージェント認証のために3種類のトークンタイプをサポートしています：

エージェントまたはフリートごとの権限設定

コンシューマートークンを使用すると、役割ごとにアクセスをセグメント化できます。各コンシューマーは独自のID、トークン、スコープ付き権限を取得します：

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

権限は2つのレベルで機能します — サービス全体（エージェントはそのサービスのすべてを参照可能）または 個別のシークレット（エージェントは特定のキーのみを参照可能）。エージェントが /bootstrap を呼び出すと、許可されたものだけが返されます。

# 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"

管理UIの人間用認証は、Google OAuth、メールマジックリンク、または単純なパスワードを使用します（環境変数で設定）。OWNER_EMAILS に含まれるメールアドレスのみがログインできます。

新しいサービスの追加

各プロキシアダプターは src/app/api/v1/<service>/route.ts にあるNext.jsルートハンドラーです。追加するには：

1. src/app/api/v1/your-service/route.ts を作成します。

2. 認証のために @/lib/access から authenticateRequestActor() を使用します。

3. 暗号化されたストア（Prisma経由）または環境変数からAPIキーを読み取ります。

4. アップストリームAPIにリクエストをプロキシします。

5. 結果を返します。

ほとんどのアダプターは100行以下です。クリーンな例として src/app/api/v1/hubspot/route.ts を参照してください。

エージェントへの指示

このリポジトリの AGENTS.md には2つのセクションがあります：

1. Accessを開発するエージェント向け — アーキテクチャ、パターン、データモデル、コマンド

2. Accessを使用するエージェント向け — CLAUDE.md やエージェントの指示にそのまま貼り付けられるブロック。ブートストラップ、認証情報の取得、プロキシエンドポイントの使用方法をエージェントに伝えます。

「Accessを使用するエージェント向け」セクションをエージェントの指示ファイルにコピーし、環境変数に ACCESS_BASE_URL と ACCESS_TOKEN を設定してください。

MCPサーバー

Accessには、stdioトランスポートを介してGoogle Workspaceツールを公開するMCPサーバー (mcp-server.mjs) が含まれています。MCP互換クライアントであれば何でも動作します。

クライアントに以下の設定を追加してください。JSONは同じで、クライアントごとにファイルパスのみが異なります：