Безопасные подключения Leina и приверженность открытому исходному коду

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

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

Leina получает доступ к бизнес-приложениям через авторизованные подключения и использует разрешения участников и групп для управления доступом. OpenConnector отвечает за подключения к приложениям. Исходные учетные данные аккаунта остаются в среде выполнения подключения, а агент использует операции и результаты, необходимые для задачи. Архитектура подключений

Мы публикуем код ключевых компонентов и документацию, чтобы разработчики могли изучить обработку учетных данных, объявления разрешений и логику вызовов, а также помочь их улучшить. Публичные проекты предоставляют детали реализации и записи о совместной работе; учетные данные и бизнес-данные остаются под управлением авторизации подключения и настроек доступа.

Делаем границы доступа открытыми для проверки

У дизайна безопасности должны быть конкретные детали реализации для изучения. Публичный исходный код позволяет разработчикам проверить:

• Обработку учетных данных: какая граница среды выполнения хранит исходные учетные данные и какие пути вызовов их используют.
• Необходимые разрешения: какие области объявляет коннектор и что требуется для авторизации чтения и записи.
• Проверку изменений: какую проблему решает исправление, какие проверки на регрессии оно добавляет и кто внес вклад.

Это дает сообществу публичную точку входа для проверки. Разработчики и исследователи безопасности могут изучать реализации, задавать вопросы и сообщать о потенциальных уязвимостях приватно через политику безопасности. Команды по-прежнему настраивают авторизацию аккаунта и доступ в соответствии со своими задачами.

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

Определение авторизации вокруг задачи команды

Представьте, что команда просит Leina:

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

Этот пример объясняет связь подключения. Доступные операции зависят от поддержки коннектора, авторизации аккаунта и настроек команды.

Leina должна интерпретировать запрос, выбрать операции для чтения почты и организовать результат. OpenConnector предоставляет возможности подключения и выполнения для этих операций: использует авторизованный аккаунт, проверяет соответствующие границы доступа и вызывает бизнес-приложение.

flowchart TB
  accTitle: От задачи к авторизованным приложениям
  accDescr: Команда запрашивает работу в чате. Leina выбирает необходимые операции и использует авторизацию и контроль доступа OpenConnector для достижения авторизованных бизнес-приложений.
  T("Командная задача"):::channel --> L("Leina"):::agent
  L --> G("OpenConnector\nАвторизация и контроль доступа"):::gateway
  G --> A("Авторизованные приложения\nЭлектронная почта, документы, деловые записи"):::resource

Leina обеспечивает командный опыт работы с ИИ. OpenConnector обеспечивает инфраструктуру подключения к приложениям. Шлюз может работать независимо, с доступом через SDK, CLI, MCP и HTTP/OpenAPI. Другие разработчики могут подключить его к своим агентам или приложениям. Архитектура и пути доступа

Как учетные данные, действия и доступ к данным сочетаются

Бизнес-приложения различаются методами авторизации, определениями разрешений, входными и выходными данными и обработкой ошибок. Чтение письма и изменение записи клиента также требуют разного доступа. По мере роста числа приложений и задач эти детали влияют на то, сможет ли агент надежно выполнить свою работу.

Мы поддерживаем возможности подключения в отдельном шлюзе. Клиенты могут обнаруживать действия, проверять схемы ввода и вывода и требуемые разрешения, а затем выбирать подключение для выполнения. Исходные учетные данные провайдера остаются за границей среды выполнения; агенты получают метаданные и результаты, необходимые для запуска. Возможности шлюза

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

Одни и те же идентификаторы провайдеров, идентификаторы действий и контракты могут обслуживать разные пути доступа. Разработчики могут организовывать задачи вокруг своих продуктов, повторно используя работу по подключению. Инструменты разработчика

Наш вклад в сообщество открытого исходного кода

Наш вклад в открытый исходный код включает независимо используемый шлюз, инструменты для его вызова и постоянное пространство для совместного поддержания этих проектов.

Разработчики могут изучить объявления разрешений, схемы действий и код исполнителя. Они также могут запустить свой собственный OpenConnector. Операторы самостоятельно развернутых экземпляров настраивают хранилище, аутентификацию и свои собственные приложения OAuth, а также поддерживают среду в соответствии с документацией по развертыванию. Настройка самостоятельного развертывания

OpenFlow помещает шаги рабочего процесса на проверяемый холст. Он может работать независимо и использовать среду выполнения коннектора, такую как OpenConnector, для обнаружения и выполнения действий приложений. Учетные данные аккаунта остаются на уровне подключения, а рабочие процессы ссылаются на идентификаторы подключений. Проект в настоящее время находится в бета-версии. Как OpenFlow подключает приложения

Эти проекты предоставляют возможности подключения, рабочих процессов и клиентского доступа. Лицензия каждого репозитория определяет его объем открытого исходного кода, в то время как сторонние сервисы и ресурсы сохраняют свои собственные условия. Наша страница открытого исходного кода объединяет проекты, количество звезд и пути участия.

Совместное улучшение авторизации и безопасности подключений

Ценность вклада становится ясна в решаемой им проблеме. Эти два объединенных пул-реквеста сообщества касаются объявлений разрешений и обработки жизненного цикла подключения. Они демонстрируют улучшения в публичном репозитории; они не подтверждают, что текущая производственная версия Leina развернула эти изменения.

Gmail: запрос доступа для задачи только для чтения

Предыдущее объявление Gmail использовало один список областей как для сервисных аккаунтов, так и для пользовательского OAuth. Этот список подходил для сервисных аккаунтов, но в нем отсутствовала область gmail.readonly среди областей, которые мог запросить пользовательский OAuth-интеграция. Интеграция, которой нужно только читать сообщения, не могла запросить доступ только для чтения только через это объявление.

В PR #586 участник @bakey разделил списки. Объявление пользовательского OAuth добавляет доступ только для чтения, в то время как сервисные аккаунты сохраняют свой существующий список областей. Это позволяет интеграциям только для чтения выбирать подходящее разрешение и сохраняет существующую авторизацию сервисных аккаунтов. PR также добавляет проверки на регрессии для этих границ.

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

OAuth: сохранение отключенного подключения отключенным

Авторизация может пересекаться с другими операциями. Обратный вызов OAuth, все еще выполняющийся, может завершиться после того, как пользователь отключился, и записать учетные данные обратно в хранилище.

Участник @powerfulZ устранил эту гонку в PR #698. Отключение увеличивает долговечное поколение вывода из эксплуатации. Перед сохранением учетных данных поток авторизации проверяет, действительно ли его захваченное поколение. Устаревший поток авторизации больше не может восстановить отключенное подключение, в то время как новое явное согласие может повторно подключить его.

Запись проверки PR охватывает соответствующие пути хранения SQLite, D1 и PostgreSQL. Улучшение делает изменение состояния, стоящее за «отключением», более полным и дает сопровождающим публичное покрытие регрессии для повторной проверки.

Эти результаты сочетают поддержку проекта с вкладом сообщества. Мы сохраняем признание участников и публикуем добавленные возможности, исправления и участников в примечаниях к выпуску.

Проверьте доказательства и сопоставьте доступ с задачей

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

Его использование по-прежнему требует проверки конкретного приложения, аккаунта и операции. OpenConnector различает покрытие каталога, локально исполняемые действия и действия с доказательствами проверки против реального вышестоящего API. Общие показатели подключений описывают покрытие; доступность конкретной задачи требует отдельной проверки. Язык проверки проекта

Для пользователей команды начните через Leina с четкой задачи только для чтения. Просмотрите результат и его источники, затем расширяйте доступ по мере необходимости. Прочитайте Безопасные подключения приложений для авторизации аккаунта и первой задачи, или Разрешения агента команды для общих границ доступа.

Для разработчиков запустите OpenConnector, изучите нужные вам действия и подключите своего агента или продукт. Сообщайте о проблемах с воспроизводимыми шагами. Следуйте руководству по вкладу при отправке кода, документации и результатов проверки. Сообщайте о раскрытии учетных данных или потенциальных уязвимостях приватно через политику безопасности.

Мы делаем реализации ключевых компонентов доступными для проверки разработчиками и используем публичное сотрудничество для улучшения авторизации и подключений. Команды могут изучить основу, лежащую в основе Leina, в то время как другие разработчики могут повторно использовать проекты и вносить улучшения обратно в сообщество.