읽기 권한
연결된 에이전트가 상대방의 트랜스크립트, 화면, 노트를 읽도록 허용합니다 — 한 번에 하나씩 명시적으로 부여하며, 언제든 철회할 수 있고, 기본값으로는 절대 켜지지 않습니다.
상대방에게 보내기만 할 수 있는 에이전트는 질문을 던지고 기다려야 합니다. 상대방을 읽을 수 있는 에이전트는 상대가 무엇을 하고 있는지 살펴보고 그 답을 같은 턴에서 바로 활용할 수 있습니다 — 최근 트랜스크립트를 가져오거나, 터미널 화면을 들여다보거나, 노트를 읽거나, 아니면 그냥 "내가 마지막으로 본 이후로 뭔가 바뀌었어?"라고 물어볼 수 있습니다.
이것은 분명 유용하지만, 동시에 분명한 데이터 공유 결정이기도 합니다. 1DevTool은 이를 그렇게 다룹니다.
직접 허용하기 전에는 아무것도 읽을 수 없습니다
읽기 권한은 기본적으로 꺼져 있으며, 링크별로 부여됩니다. 이때 표시되는 대화상자에는 그 내용에 접근할 수 있는 모든 에이전트의 이름이 명시됩니다.
권한은 하나의 스위치가 아니라 개별적으로 나뉩니다.
- 제한된 트랜스크립트 — 최근 대화의 일정 구간
- 전체 트랜스크립트 — 대화 전체
- 터미널 화면 — 지금 이 순간 화면에 실제로 표시된 내용
화면 권한에는 명확한 경고가 따라붙는데, 그럴 만한 이유가 있습니다. 이 권한은 터미널 서식만 제거할 뿐입니다. 키, 토큰, .env 출력은 그대로 노출됩니다.
이 대화상자는 잊기 쉬운 부분도 함께 알려줍니다 — 에이전트가 읽은 내용은 곧 해당 벤더의 대화의 일부가 됩니다. 권한을 철회하면 다음 읽기는 막을 수 있지만, 이미 복사된 내용을 되돌릴 수는 없습니다.
철회하기
AI 설정에서 해당 링크 항목을 통해 언제든 권한을 철회할 수 있습니다. 이미 진행 중인 읽기 요청은 결과가 반환되기 전에 차단됩니다.
요청자 검증
macOS에서는 읽기 요청이 운영체제 수준에서 검증됩니다 — 오직 그 링크를 소유한 터미널 안에서 실제로 실행 중인 프로세스만 해당 링크를 통해 읽을 수 있습니다. 올바른 식별자를 알고 있을 뿐인 이웃 에이전트는 아무것도 얻지 못합니다.
Linux와 Windows는 더 약한 검증을 받아들이는 대신 현재로서는 이러한 읽기 요청 자체를 거부합니다. 이들 플랫폼에서도 보내기, 묻기, 응답하기 등 나머지 기능은 정상적으로 동작합니다 — 동일한 수준의 검증이 가능해질 때까지 보류되는 것은 읽기 권한뿐입니다.
상대방에게 게시하기
폭넓은 읽기 권한을 부여하는 대신, 에이전트는 특정 링크가 가져갈 수 있도록 무언가를 게시할 수 있습니다 — 파일이나 결과물을 한 상대에게 건네고, 오직 그 링크만 읽을 수 있게 하는 방식입니다. 목표가 "리뷰어에게 이 diff를 전달하기"일 때는, 게시가 더 작고 더 안전한 방법입니다.
설정의 링크 목록
설정 → AI에서는 에이전트가 가진 모든 링크를 한곳에서 확인할 수 있습니다.
- 활성 링크, 끊어진 링크, 그리고 에이전트가 요청했지만 아직 승인되지 않은 링크
- 요청된 링크를 승인 또는 거부
- 기존 링크가 할 수 있는 작업을 편집
- 읽기 권한이 부여될 경우 정확히 누구의 콘텐츠가 노출되는지 검토
- 터미널이 재시작되어 끊긴 링크를 재연결
- 링크를 완전히 제거
보내기·묻기 권한을 가진 링크는 트랜스크립트나 화면 읽기 권한이 꺼져 있어도 계속 검색 가능한 상태로 남아 있으므로, 읽기 권한이 꺼져 있다는 이유만으로 상대방이 "상대가 존재하지 않음"이라고 잘못 보고하는 일은 없습니다.
신뢰에 관한 참고 사항
읽기 권한은 오케스트레이션에서 안전한 기본값이 대가를 요구하는 유일한 부분입니다 — 이 권한이 없는 에이전트는 더 느리게 동작합니다. 이 트레이드오프는 의도적으로 여러분의 몫으로 남겨져 있으며, 링크별로, 그 결정을 내리는 순간 화면에 영향을 받는 에이전트들의 이름이 표시된 상태에서 이루어집니다.
관련 문서
- 연결된 터미널 — 이러한 권한이 적용되는 링크를 만드는 방법
- Team Map — 모든 연결선에 권한 배지가 표시됩니다
- 오케스트레이션 개요