Доступ

«Это довольно изящная маленькая утилита». — я

Время от времени агенту нужно напоминать, что это существует.

Все, что ниже этой строки, было написано ботами.

Один Bearer-токен для всех ваших сервисов.

Access предоставляет агентам и скриптам безопасный доступ к сервисам, использующим OAuth и API-ключи, без необходимости напрямую работать с учетными данными. Храните секреты, автоматически обновляйте токены, проксируйте запросы, ведите аудит всего — через единый стабильный интерфейс по HTTP и 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]

Что он делает

Вы помещаете в него все учетные данные — API-ключи, OAuth-токены, бот-токены, учетные данные агентов, сервисные секреты, все, что нужно вашим агентам и скриптам. Затем вы решаете, кто что получает.

• Управление правами доступа для каждого агента и группы — каждый агент или группа получает собственный токен с ограниченным доступом. Агенты-программисты видят GitHub и Linear. Агенты по коммуникациям видят Gmail и Slack. Агенты по операциям видят AWS. Управление осуществляется через админ-панель — никаких конфигурационных файлов или манипуляций с CLI.

• Хранит все в зашифрованном виде — API-ключи, OAuth-токены, бот-токены, учетные данные между агентами, сервисные секреты. AES-256-GCM при хранении, HMAC-хешированные токены доступа.

• Обрабатывает OAuth — обновление токенов, потоки согласия, Google с несколькими аккаунтами — ваш агент никогда в этом не участвует.

• Проксирует API-вызовы — для сервисов с адаптерами агенты обращаются к Access и получают JSON обратно, никогда не видя базовый ключ.

• Предоставляет учетные данные напрямую — для всего остального агенты получают ключи через /bootstrap или /secrets/by-env/WHATEVER.

• Логирует все — каждый доступ к секрету, каждый API-вызов, каждая попытка авторизации, с указанием субъекта и IP.

• Инициализирует сессии — один вызов /bootstrap дает агенту только то, что ему разрешено видеть — переменные окружения, документацию и контекст.

Счастливый путь: Агент отправляет Bearer-токен → Access обрабатывает авторизацию, обновление и проксирование → Агент получает JSON или пакет инициализации обратно. Это все.

Как это выглядит

Панель управления — сервисы, ключи, агенты и история аудита на одном экране:

Управление правами агентов — каждый агент получает собственный токен с ограниченными правами доступа:

Детали агента — уровень доверия, префикс токена, время последнего использования и количество предоставленных прав:

Related MCP server: AI Service Gateway MCP

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.

• Управление доступом для больших команд или мультиарендные системы.

Чем это отличается от менеджера паролей: 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.

• Идентичность рабочих нагрузок / OIDC (GitHub Actions OIDC) — позволяют полностью избежать долгоживущих секретов, подтверждая личность для получения краткосрочных учетных данных. Отлично для CI/CD. Не помогает с локальными сессиями агентов.

• Динамические секреты (Vault dynamic secrets) — создают учетные данные с ограниченным сроком действия по запросу. Серьезная инфраструктура. Избыточно для большинства настроек агентов.

• OAuth-брокеры (Nango, Composio) — обрабатывают авторизацию OAuth, хранение токенов и обновление. Облачные платформы со своими панелями управления и биллингом.

Зрелые организации разделяют проблему между Vault + OIDC + OAuth-брокерами + внутренними инструментами платформы. Небольшие команды используют 1Password/Doppler для статических секретов и все равно страдают с OAuth.

Access объединяет эти уровни в одно самохостируемое приложение: хранение учетных данных, обновление OAuth, проксирование API-вызовов, инициализация сессий агентов, аудит всего. Это менее безопасно, чем Vault + KMS, но это одна вещь вместо четырех — и она реально работает.

Быстрый старт

Предварительные требования

• 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 (список email-адресов через запятую, которым разрешен вход)

• Один провайдер авторизации (Google OAuth, email magic link или пароль владельца)

4. Запуск миграций и сидинг

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

5. Запуск приложения

npm run dev

Перейдите по адресу http://localhost:3000 и войдите с помощью email из вашего списка OWNER_EMAILS.

6. Установка навыка агента + конфигурация MCP

bash scripts/install.sh

Это обнаружит установленные у вас инструменты агентов (Claude Code, Cursor, Gemini CLI, Windsurf, VS Code, Codex), установит навык проверки работоспособности и покажет конфигурацию MCP для каждого. Вы можете принять или отклонить каждый шаг.

Поддерживаемые сервисы

27 конечных точек сервисов через /api/v1/*. Каждый адаптер обрабатывает авторизацию и проксирует запросы к вышестоящему API.

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 поддерживает три типа токенов для аутентификации агентов:

Управление правами по агенту или группе

Потребительские токены позволяют сегментировать доступ по ролям. Каждый потребитель получает свою идентичность, токен и ограниченные права:

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

Права работают на двух уровнях — весь сервис (агент видит все в этом сервисе) или отдельные секреты (агент видит только конкретные ключи). Когда агент вызывает /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"

Аутентификация людей для админ-панели использует Google OAuth, email magic links или простой пароль — настраивается через переменные окружения. Только email-адреса в OWNER_EMAILS могут войти.

Добавление нового сервиса

Каждый прокси-адаптер — это обработчик маршрута Next.js в src/app/api/v1/<service>/route.ts. Чтобы добавить новый:

1. Создайте src/app/api/v1/your-service/route.ts

2. Используйте authenticateRequestActor() из @/lib/access для авторизации

3. Прочитайте API-ключ из зашифрованного хранилища (через Prisma) или переменных окружения

4. Проксируйте запрос к вышестоящему API

5. Верните результат

Большинство адаптеров занимают менее 100 строк. См. src/app/api/v1/hubspot/route.ts для чистого примера.

Инструкции для агентов

AGENTS.md в этом репозитории имеет два раздела:

1. Для агентов, разрабатывающих на Access — архитектура, паттерны, модель данных, команды

2. Для агентов, использующих Access — готовый блок для вставки в ваш CLAUDE.md или инструкции агента, который говорит агентам, как инициализировать сессию, получать учетные данные и использовать прокси-конечные точки

Скопируйте раздел «Для агентов, ИСПОЛЬЗУЮЩИХ Access» в файл инструкций вашего агента и установите ACCESS_BASE_URL и ACCESS_TOKEN в вашем окружении.

MCP-сервер

Access включает MCP-сервер (mcp-server.mjs), который предоставляет инструменты Google Workspace через транспорт stdio. Работает с любым MCP-совместимым клиентом.

Добавьте следующую конфигурацию в ваш клиент. JSON одинаковый — меняется только путь к файлу для каждого клиента: