아키텍처와 보안
결재해야 하는 분을 위해 썼습니다.
저희를 검토하고 계시다면 이 페이지는 당신을 위한 것입니다. 각 구성에서 데이터가 어디로 가고 무엇이 기록되는지, 그리고 그 주장을 신뢰가 아니라 검증으로 확인하는 방법을 적었습니다.
배치 토폴로지
세 가지 형태이며 진단 단계에서 결정합니다. 차이 중 나머지보다 중요한 한 가지는, 네트워크 경계를 넘는 연결이 있는지 여부입니다.
데이터는 어디로 가는가
정직한 답은 구성에 따라 달라지므로 전부 나열합니다. 가장 강한 주장이 항상 적용되는 것처럼 보이게 하기보다, 그 차이를 보시는 편이 낫습니다.
| 구성 | 프롬프트와 문서 | 경로상의 제3자 |
|---|---|---|
| 고객사 하드웨어에서의 로컬 추론 | 네트워크를 전혀 벗어나지 않습니다 | 없음 |
| 고객사 환경에서의 호스팅 추론 — 승인한 모델 API | 프롬프트와 함께 전송되는 컨텍스트가 해당 제공사에 도달합니다 | 해당 제공사만, 고객사와 그 회사 간 계약에 따라 |
| 저희가 호스팅하며 고객사 시스템을 조회 — 범위를 한정한 읽기 전용 접근 부여 | 필요할 때 읽고 메모리와 모델 컨텍스트에만 존재합니다. 저희 쪽에 정적 사본은 없습니다 | 저희(전송 중에 한해)와 모델 제공사 |
| 저희가 호스팅하며 사본 보유 — 고객사가 데이터를 복제 | 합의한 보관 기간 동안 저희 인프라에 저장됩니다 | 저희(고객사의 데이터 처리자로서)와 모델 제공사 |
앞의 두 구성에서는 저희로 돌아오는 텔레메트리 경로가 전혀 없습니다. 아웃바운드를 일절 허용하지 않아야 하는 배치라면 터널 구성 요소가 고객사 계정 안에서 실행되므로, 저희를 포함한 어떤 제3자도 트래픽 경로에 없습니다. 세 번째는 설계상 다릅니다. 저희가 호스팅하면 저희가 데이터를 처리하므로, 구두 약속이 아니라 데이터 처리 계약, 명시된 보관 기간, 침해 통지 확약이 함께 갑니다. 가장 강하게 들리는 행이 아니라, 귀사의 의무에 맞는 행을 고르십시오.
내부 시스템 접근
연결할 가치가 있는 시스템은 대개 인바운드 연결을 받지 않는 것들입니다. 예외를 요청하는 대신, 에이전트가 안에서 밖으로 도달합니다.
- 방향
- 클라이언트는 항상 밖으로 연결하며, 고객사 네트워크가 이미 허용하는 포트를 씁니다. 고객사 쪽에서 인바운드를 대기할 필요가 없습니다.
- HTTP 터널
- HTTP/2와 TLS 위의 지속적 양방향 gRPC 스트림으로 로컬 서비스에 전달합니다. 공개 엣지는 고객사 계정 안에 배치할 수 있습니다.
- 리버스 SOCKS5
- 내부 네트워크에 더 폭넓게 도달할 때. 한쪽에서 SOCKS5로 대기하고, 다른 쪽이 내부 네트워크의 대상에 연결합니다. TLS + yamux 또는 QUIC로 운반하므로 패킷 하나의 손실은 그 스트림만 멈춥니다.
- 도구 접근
- 내부 기능은 stdio 또는 streamable HTTP를 쓰는 Model Context Protocol 클라이언트를 통해 도구로 에이전트에 노출됩니다. 무엇을 노출할지는 고객사가 정하며, 자동으로 발견되는 것은 없습니다.
메시징 화면의 암호화
배치에 채팅 화면이 포함되는 경우, 메시지를 라우팅하는 허브는 「운영할 수 있음」이 「읽을 수 있음」을 뜻하지 않도록 설계되어 있습니다. 오프라인 수신자에게 갈 메시지는 암호문으로 대기하고 재연결 시 순서대로 전달됩니다.
- 키 합의
- X3DH와 PQXDH.
- 메시지 키
- 1:1 대화에는 Double Ratchet.
- 그룹
- sender key. 구성원 변경 시 재키잉하므로 제외된 구성원은 이후 내용을 읽을 수 없습니다.
- 메타데이터
- sealed sender.
- 검증
- 세이프티 넘버. 두 사람이 대역 외에서 키가 바뀌지 않았음을 확인할 수 있습니다.
- 기기
- 연결된 각 기기는 독립적인 서명 키와 메시지 키를 가지며 개별로 폐기할 수 있습니다.
무엇이 기록되는가
세션 이력, 에이전트의 판단, 도구 호출은 해당 배치를 실행하는 호스트의 디스크에 저장됩니다. 고객사가 운영하는 두 가지 구성 — 고객사 하드웨어 또는 클라우드 계정 — 에서는 그 호스트가 고객사 것이므로, 기록에는 고객사의 보관 정책과 접근 통제가 적용되고 저희는 사본을 보관하지 않습니다. 저희가 호스팅하는 경우에는 저희 인프라에 저장되며, 데이터 처리 계약에 명시한 보관 기간이 적용됩니다.
무엇을, 얼마나 오래 보관하고 누가 읽을 수 있는지는 「배치」 단계에서 고객사와 함께 정하는 구성상의 결정이며, 물려받는 기본값이 아닙니다.
이것을 검증하는 방법
위의 모든 내용은 주장이며, 거래 이력이 없는 회사의 주장을 받아들일 이유는 없습니다. 검증 방법은 세 가지입니다.
- 직접 시험해 보기
- 서비스에 포함되며 셋 중 가장 설득력이 있습니다. 고객사가 통제하는 네트워크에서 배치를 실행하고 무엇이 나가는지 관찰하십시오. 그 계측을 추가 비용 없이 돕습니다. 입장이 바뀌면 저희도 그 확인을 원할 것이기 때문입니다.
- 소스코드 검토
- 요청 시 NDA 하에 유료 옵션으로 견적합니다. 검토 환경 준비에는 엔지니어링 시간이, 문서 절차에는 법무 시간이 듭니다. 검토 절차가 코드 열람을 요구한다면 미리 말씀해 주시면 견적을 드립니다.
- 에스크로
- 요청 시 제3자 에스크로 기관을 통해 준비합니다. 기관 비용과 저희 초기 작업 시간은 실비로 견적해 전가하며 계약 단위로 가격을 정하므로, 예산에 들어갈 수 있도록 미리 말씀해 주십시오.
아웃바운드 점검 실제 기록
3분 동안 첫 번째 방법을 저희 자체 네트워크에서 실제로 수행한 기록입니다. 에이전트가 임상 데이터베이스에 질문하고 추론은 로컬에서 실행합니다. 이후 그 조회가 연 네트워크 소켓을 전부 표본 조사하여, 하나라도 공개 주소에 닿았다면 점검은 실패로 처리됩니다. 스스로의 한계도 밝힙니다 — 이 스크립트는 장비 한 대만 감시하므로, 검토자는 추론 호스트도 함께 감시해야 합니다.
영상은 본 도메인에서 직접 제공하며 외부 임베드가 아닙니다 — 제3자 플레이어도, 추적도 없습니다.