Leina 블로그 팀 AI

Leina의 안전한 연결과 오픈 소스 약속

계정 권한 부여와 팀 권한이 Leina의 앱 접근을 어떻게 정의하는지, 그리고 공개된 컴포넌트 코드와 커뮤니티 기여가 이러한 경계를 검토 가능하게 만드는지 알아보세요.

작업이 권한 부여 경계를 통과해 애플리케이션 노드에 도달하며, 서로 다른 클라이언트가 동일한 연결 기반을 공유합니다

개념도: 팀 작업이 권한이 부여된 연결을 통해 비즈니스 앱에 도달합니다.

AI에게 이메일을 정리하거나, 문서를 찾거나, 비즈니스 기록을 업데이트하도록 요청하기 전에 팀은 명확한 접근 경계가 필요합니다. 어떤 계정이 사용되는지, 어떤 작업이 허용되는지, 누가 연결을 사용할 수 있는지, 그리고 누가 결과를 받는지 말입니다.

Leina는 권한이 부여된 연결을 통해 비즈니스 앱에 접근하고, 멤버 및 그룹 권한을 사용해 사용 가능한 접근을 관리합니다. OpenConnector는 앱 연결을 처리합니다. 원시 계정 자격 증명은 연결 런타임 내에 유지되며, 에이전트는 작업에 필요한 작업과 결과를 사용합니다. 연결 아키텍처

우리는 개발자가 자격 증명 처리, 권한 선언, 호출 로직을 검토하고 개선할 수 있도록 주요 컴포넌트 코드와 문서를 공개합니다. 공개 프로젝트는 구현 세부 사항과 협업 기록을 제공하며, 자격 증명과 비즈니스 데이터는 연결 권한 부여 및 접근 구성의 적용을 받습니다.

접근 경계를 검토 가능하게 만들기

보안 설계는 검토할 수 있는 구체적인 구현 세부 사항을 갖추어야 합니다. 공개 소스를 통해 개발자는 다음을 확인할 수 있습니다.

  • 자격 증명 처리: 어떤 런타임 경계가 원시 자격 증명을 보유하는지, 그리고 어떤 호출 경로가 이를 사용하는지.
  • 필요한 권한: 커넥터가 어떤 범위를 선언하는지, 그리고 읽기 및 쓰기 권한 부여에 무엇이 필요한지.
  • 변경 사항 검증: 수정이 어떤 문제를 해결하는지, 어떤 회귀 검사를 추가하는지, 누가 기여했는지.

이는 커뮤니티에 검토를 위한 공개 진입점을 제공합니다. 개발자와 보안 연구자는 구현을 검사하고, 질문을 제기하며, 보안 정책을 통해 잠재적 취약점을 비공개로 보고할 수 있습니다. 팀은 여전히 자신의 작업에 맞게 계정 권한 부여와 접근을 구성합니다.

이러한 기능을 유지하는 것과 함께, 우리는 연결, 워크플로, 클라이언트 프로젝트를 개발자가 자신의 제품에서 재사용할 수 있도록 제공합니다.

팀 작업을 중심으로 권한 부여 정의하기

한 팀이 Leina에게 다음과 같이 요청한다고 상상해 보세요.

이번 주 고객 이메일을 읽고, 후속 조치 항목을 식별하고, 원본 메시지 링크를 포함하고, 나를 위해 초안을 준비해 줘.

이 예시는 연결 관계를 설명합니다. 사용 가능한 작업은 커넥터 지원, 계정 권한 부여, 팀 설정에 따라 달라집니다.

Leina는 요청을 해석하고, 이메일을 읽기 위한 작업을 선택하고, 결과를 정리해야 합니다. OpenConnector는 이러한 작업을 위한 연결 및 실행 기능을 제공합니다. 권한이 부여된 계정을 사용하고, 관련 접근 경계를 확인하고, 비즈니스 앱을 호출합니다.

From a task to authorized apps

flowchart TB
  accTitle: From a task to authorized apps
  accDescr: A team requests work in chat. Leina selects the required operations and uses OpenConnector authorization and access controls to reach authorized business apps.
  T("팀 작업"):::channel --> L("Leina"):::agent
  L --> G("OpenConnector\n권한 부여 및 접근 제어"):::gateway
  G --> A("승인된 앱\n이메일, 문서, 업무 기록"):::resource
Leina organizes the task and calls authorized apps through OpenConnector; this shows the connection relationship.

Leina는 팀 AI 경험을 제공합니다. OpenConnector는 앱 연결 인프라를 제공합니다. 게이트웨이는 SDK, CLI, MCP, HTTP/OpenAPI 접근을 통해 독립적으로 실행될 수 있습니다. 다른 개발자는 이를 자신의 에이전트나 애플리케이션에 연결할 수 있습니다. 아키텍처 및 접근 경로

자격 증명, 작업, 데이터 접근이 함께 맞춰지는 방식

비즈니스 앱은 권한 부여 방법, 권한 정의, 입력, 출력, 오류 처리에서 차이가 있습니다. 이메일을 읽는 것과 고객 기록을 변경하는 것도 서로 다른 접근이 필요합니다. 앱과 작업의 수가 늘어남에 따라 이러한 세부 사항은 에이전트가 작업을 안정적으로 완료할 수 있는지에 영향을 미칩니다.

우리는 연결 기능을 별도의 게이트웨이에서 유지 관리합니다. 클라이언트는 작업을 발견하고, 입력 및 출력 스키마와 필요한 권한을 검사한 다음, 실행할 연결을 선택할 수 있습니다. 원시 공급자 자격 증명은 런타임 경계 뒤에 유지되며, 에이전트는 실행에 필요한 메타데이터와 결과를 받습니다. 게이트웨이 기능

이러한 분리는 개선 사항에 명확한 위치를 부여합니다. 공급자가 읽기 전용 범위 선언을 필요로 할 수도 있고, 작업이 수정된 입력 스키마를 필요로 할 수도 있으며, 파일 다운로드가 더 나은 처리를 필요로 할 수도 있습니다. 각각은 연결 계층에서 검토하고 변경할 수 있으며, 작업에 대한 공개 기록이 남습니다.

동일한 공급자 ID, 작업 ID, 계약이 서로 다른 접근 경로를 지원할 수 있습니다. 개발자는 연결 작업을 재사용하면서 자신의 제품을 중심으로 작업을 구성할 수 있습니다. 개발자 도구

오픈 소스 커뮤니티에 대한 우리의 기여

오픈 소스에 대한 우리의 기여에는 독립적으로 사용 가능한 게이트웨이, 이를 호출하기 위한 도구, 그리고 이러한 프로젝트를 함께 유지 관리하기 위한 지속적인 공간이 포함됩니다.

프로젝트기능라이선스
OpenConnector자격 증명 처리, 작업 발견 및 실행, 런타임 접근 제어, 자체 호스팅 배포Apache-2.0
OpenFlow코드 및 AI 작업이 포함된 시각적 워크플로, 분기, 사람 승인, 자체 호스팅 배포 (베타)Apache-2.0
OO-CLI로컬 에이전트를 위해 명령줄에서 커넥터 작업을 발견, 검사, 호출MIT
Connector SDK애플리케이션 코드에서 게이트웨이를 호출하기 위한 경량 TypeScript HTTP 클라이언트MIT

개발자는 권한 선언, 작업 스키마, 실행기 코드를 검사할 수 있습니다. 또한 자체 OpenConnector를 실행할 수도 있습니다. 자체 호스팅 운영자는 스토리지, 인증, 자체 OAuth 앱을 구성하고 배포 문서에 따라 환경을 유지 관리합니다. 자체 호스팅 설정

OpenFlow는 워크플로 단계를 검사 가능한 캔버스에 배치합니다. 독립적으로 실행될 수 있으며 OpenConnector와 같은 커넥터 런타임을 사용해 앱 작업을 발견하고 실행할 수 있습니다. 계정 자격 증명은 연결 계층에 유지되며 워크플로는 연결 ID를 참조합니다. 이 프로젝트는 현재 베타입니다. OpenFlow가 앱을 연결하는 방식

이러한 프로젝트는 연결, 워크플로, 클라이언트 접근 기능을 제공합니다. 각 저장소의 라이선스는 오픈 소스 범위를 정의하며, 타사 서비스와 자산은 자체 약관을 유지합니다. 우리의 오픈 소스 페이지는 프로젝트, Star 수, 참여 경로를 한데 모아 보여줍니다.

권한 부여와 연결 보안을 함께 개선하기

기여의 가치는 해결하는 문제에서 분명해집니다. 다음 두 개의 병합된 커뮤니티 풀 리퀘스트는 권한 선언과 연결 수명 주기 처리를 다룹니다. 이는 공개 저장소에서의 개선을 보여주며, Leina의 현재 프로덕션 버전이 이러한 변경 사항을 배포했음을 입증하지는 않습니다.

Gmail: 읽기 전용 작업을 위한 접근 요청

이전 Gmail 선언은 서비스 계정과 사용자 OAuth 모두에 하나의 범위 목록을 사용했습니다. 그 목록은 서비스 계정에 적합했지만, 사용자 OAuth 통합이 요청할 수 있는 범위에서 gmail.readonly를 누락했습니다. 메시지를 읽기만 하면 되는 통합은 그 선언만으로는 읽기 전용 접근을 요청할 수 없었습니다.

PR #586에서 기여자 @bakey가 목록을 분리했습니다. 사용자 OAuth 선언은 읽기 전용 접근을 추가하고, 서비스 계정은 기존 범위 목록을 유지합니다. 이를 통해 읽기 전용 통합은 적절한 권한 부여를 선택할 수 있고 기존 서비스 계정 권한 부여는 보존됩니다. 이 PR은 또한 이러한 경계에 대한 회귀 검사를 추가합니다.

이메일 요약 작업의 경우, 이와 같은 세부 사항은 통합에 필요한 접근량에 영향을 미칩니다. 선언과 변경 사항을 공개하면 개발자가 경계를 검사하고 자신의 통합에 적합한 범위를 선택할 수 있습니다.

OAuth: 연결이 끊긴 연결을 끊긴 상태로 유지하기

권한 부여는 다른 작업과 겹칠 수 있습니다. 진행 중인 OAuth 콜백이 사용자가 연결을 끊은 후에 완료되어 자격 증명을 스토리지에 다시 쓸 수 있습니다.

기여자 @powerfulZ가 PR #698에서 이 경쟁 조건을 해결했습니다. 연결을 끊으면 내구성 있는 폐기 세대가 진행됩니다. 자격 증명을 저장하기 전에 권한 부여 흐름은 캡처된 세대가 여전히 유효한지 확인합니다. 오래된 권한 부여 흐름은 끊긴 연결을 더 이상 복원할 수 없으며, 새로운 명시적 동의는 연결을 다시 연결할 수 있습니다.

이 PR의 검증 기록은 관련 SQLite, D1, PostgreSQL 스토리지 경로를 다룹니다. 이 개선은 “연결 끊기” 뒤의 상태 변경을 더 완전하게 만들고 유지 관리자에게 다시 확인할 수 있는 공개 회귀 커버리지를 제공합니다.

이러한 결과는 프로젝트 유지 관리와 커뮤니티 기여를 결합합니다. 우리는 기여자 공로를 보존하고 추가된 기능, 수정 사항, 참여자를 릴리스 노트에 게시합니다.

증거를 확인하고 작업에 접근을 맞추기

공개 소스는 사용자와 개발자에게 검토할 수 있는 구체적인 것들을 제공합니다. 커넥터가 선언하는 권한, 작업이 허용하는 입력, 실행기가 업스트림 앱을 호출하는 방식, 수정으로 추가된 검사 등입니다.

이를 사용하려면 여전히 특정 앱, 계정, 작업을 확인해야 합니다. OpenConnector는 카탈로그 범위, 로컬에서 실행 가능한 작업, 실제 업스트림 API에 대해 검증 증거가 있는 작업을 구분합니다. 연결 총계는 범위를 설명하며, 특정 작업의 가용성은 별도로 확인해야 합니다. 프로젝트 검증 언어

팀 사용자의 경우, 명확한 읽기 전용 작업으로 Leina를 통해 시작하세요. 결과와 출처를 검토한 다음 필요에 따라 접근을 확장하세요. 계정 권한 부여와 첫 작업에 대해서는 안전한 앱 연결을, 공유 접근 경계에 대해서는 팀 에이전트 권한을 읽어보세요.

개발자의 경우, OpenConnector를 실행하고 필요한 작업을 검사한 다음 에이전트나 제품을 연결하세요. 재현 가능한 단계와 함께 문제를 보고하세요. 코드, 문서, 검사 결과를 제출할 때는 기여 가이드를 따르세요. 자격 증명 노출이나 잠재적 취약점은 보안 정책을 통해 비공개로 보고하세요.

우리는 주요 컴포넌트 구현을 개발자가 검토하고 사용할 수 있도록 제공하며, 공개 협업을 통해 권한 부여와 연결을 개선합니다. 팀은 Leina 뒤의 기반을 검사할 수 있고, 다른 개발자는 프로젝트를 재사용하고 개선 사항을 커뮤니티에 다시 기여할 수 있습니다.