로컬 AI 코딩 도구는 데이터 노출을 줄일 수 있지만, _로컬(local)_이라는 단어가 보안 검토에서 실제로 중요하게 다루는 질문들에 대한 답을 주지는 못합니다.

유용한 질문들은 더 좁은 범위를 가집니다:

• 에이전트(agent)가 어떤 파일을 읽을 수 있는가?
• 어떤 명령(commands)을 실행할 수 있는가?
• 어떤 네트워크 목적지에 도달할 수 있는가?
• 어떤 자격 증명(credentials)을 사용할 수 있는가?
• 변경 사항이 배포되기 전에 어떤 증거가 검토자에게 전달되는가?

프로세스는 개발자의 노트북에서 실행되면서도 여전히 광범위한 권한을 가질 수 있습니다. 홈 디렉토리 전체를 스캔하거나, 셸(shell) 자격 증명을 상속받거나, 외부 서비스를 호출하거나, 의도된 리포지토리(repository) 외부의 파일을 수정할 수도 있습니다. 따라서 로컬 실행은 배포 특성(deployment property)일 뿐입니다. 이는 완전한 안전 모델이 아닙니다.

네 가지 명시적 경계로 시작하기

에이전트 세션을 열기 전에 네 가지 사항을 기록하십시오: 읽기 가능한 파일, 쓰기 가능한 파일, 허용된 명령, 그리고 허용된 외부 시스템입니다.

이는 기본적으로 들리지만, 검토의 성격을 '도구가 신뢰할 수 있는가'라는 모호한 질문에서 '특정 세션이 무엇을 할 수 있는가'라는 구체적인 질문으로 변화시킵니다. 리포지토리 체크아웃(checkout)과 제한 없는 셸(shell) 액세스가 결합된 상태는 의미 있는 경계가 아닙니다. 그것은 단지 광범위한 권한을 가진 로컬 실행일 뿐입니다.

비밀 정보(Secrets)는 별도의 규칙을 가져야 합니다. 프롬프트(prompts)와 트랜스크립트(transcripts)에서 이를 제외하십시오. 작업에 진정으로 자격 증명이 필요한 경우, 기존의 범위가 지정된 저장소(scoped store)나 환경 변수(environment variable)를 사용하고 읽기 권한과 쓰기 권한을 분리하십시오.

관찰(observation)을 로컬에 유지하고 범위를 제한하기

여러 코딩 에이전트를 모니터링한다고 해서 모든 트랜스크립트를 중앙 서비스로 복사할 필요는 없습니다. 로컬 컴패니언(local companion)은 이미 기기에 존재하는 동일한 세션 메타데이터를 읽어 조정에 필요한 상태(어떤 세션이 활성 상태인지, 대기 중인지, 차단되었는지, 또는 완료되었는지)만을 도출할 수 있습니다.

그 관찰 계층(observation layer)에도 여전히 제한이 필요합니다:

• 알려진 프로바이더(provider) 디렉토리만 읽기;
• 파일 및 기록 크기 제한;
• 부분적인 쓰기(partial writes) 허용;
• 비밀 정보를 포함하는 트랜스크립트 콘텐츠의 렌더링 방지;
• 원시 로그(raw logs)를 복제하는 대신 압축된 도출 상태(compact derived state) 유지.

이는 데이터 표면(data surface)과 신뢰해야 하는 지점의 수를 모두 줄여줍니다.

관찰(Observation)과 실행(Execution)의 분리

상태 표면(status surface)이 조용히 원격 제어 표면(remote-control surface)으로 변해서는 안 됩니다. 세션에 주의가 필요하다는 것을 확인하는 것이, 모니터가 해당 터미널에 타이핑하거나, 명령을 승인하거나, 풀 리퀘스트(pull request)를 병합하거나, 릴리스(release)를 배포할 수 있어야 함을 의미하지는 않습니다.

이러한 분리가 중요한 이유는 모니터링 프로세스가 장기적으로 유지되기 때문입니다. 모니터링 프로세스에 명령 권한을 부여하면 편리한 대시보드가 높은 가치를 지닌 제어 평면(control plane)으로 변질됩니다. 더 안전한 설계는 관찰을 읽기 전용(read-only)으로 유지하고, 모든 중대한 동작을 명시적이고 검토 가능한 워크플로(workflow)로 되돌리는 것입니다.

증거를 경계의 일부로 취급하기

로컬 우선(Local-first) 설계가 검토(review)의 필요성을 없애는 것은 아닙니다. 다만 검토자가 무엇을 전달받아야 하는지를 변화시킵니다.

유용한 인계(handoff)에는 다음 사항이 포함되어야 합니다:

1. 요청된 결과물;
2. 변경된 파일들;
3. 실행된 명령들;
4. 통과된 테스트 및 체크 사항;
5. 해결되지 않은 리스크 또는 건너뛴 체크 사항;
6. 인간으로부터 여전히 요구되는 정확한 결정 사항.

완료 메시지만으로는 증거가 될 수 없습니다. 검토자는 전체 채팅 기록을 읽지 않고도 해당 결정을 재현할 수 있을 만큼 충분한 정보를 필요로 합니다.

모든 것을 중앙 집중화하지 않고 인시던트(Incident) 기록하기

무언가 실패했을 때, 다음과 같은 압축된 인시던트 기록을 보존하십시오: 세션 식별자(session identity), 시간 범위, 영향을 받은 아티팩트(artifact), 명령 카테고리, 관찰된 실패, 그리고 복구 조치. 이는 전체 프롬프트(prompt)나 소스 코드를 내보내지 않고도 반복되는 워크플로 문제를 진단하기에 보통 충분합니다.

목표는 텔레메트리(telemetry)를 제로(zero)로 만드는 것이 아닙니다. 목표는 그 범위가 운영상의 질문과 일치하는 텔레메트리를 구축하는 것입니다.

로컬 우선 보안은 세 가지 경계가 일치할 때 가장 강력합니다: 데이터가 있어야 할 곳에 머물고, 권한이 좁게 유지되며, 검토 증거가 충분할 때입니다. 이 중 하나라도 누락되면 워크플로는 제어(controls) 대신 신뢰(trust)에 의존하게 됩니다.

전체 체크리스트는 로컬 우선(Local-First) AI 코딩 보안 워크플로(local-first AI coding security workflow)에서 확인할 수 있습니다.