코딩 에이전트(Coding agents)는 어색한 보안적 순간을 만들어냅니다. 개발자는 자신이 입력한 작업은 이해할 수 있지만, 더 중요한 질문에 대해서는 명확한 답을 얻지 못할 수 있습니다: '지금 이 머신에서 무엇이 빠져나가려 하는가?'

그 답변에는 프롬프트(prompt) 이상의 것이 포함될 수 있습니다. 파일 내용, 경로, 리포지토리(repository) 메타데이터, 환경 세부 정보, 식별자 또는 별도의 업로드 흐름이 포함될 수 있습니다. 네트워크 검사(Network inspection)를 통해 충분한 작업 후에 이러한 세부 정보를 확인할 수 있겠지만, 이는 누군가 민감한 작업을 제출할 때마다 발생하는 결정에 있어 잘못된 수준의 마찰(friction)입니다.

유용한 제품적 질문은 개발자가 특정 벤더(vendor)를 신뢰해야 하는지 아니면 불신해야 하는지가 아닙니다. 코딩 에이전트가 송신 후의 패킷 캡처(packet capture)에 의존하는 대신, 송신 전에 외부 송신 결정을 검사 가능한 상태로 만들 수 있는지 여부입니다.

영수증은 개인정보 보호정책이 아니라 이 요청을 설명해야 합니다

일반적인 개인정보 보호 고지(privacy notice)는 다음 요청에 어떤 리포지토리, 파일, 경로 및 메타데이터가 포함되는지 답할 수 없습니다. 하지만 외부 송신 영수증(outbound receipt)은 가능합니다.

전송 직전에 CLI는 일시 중지하고 구조화된 인벤토리(inventory)를 렌더링해야 합니다:

• 프롬프트(prompt) 및 대화 문맥(conversation context);
• 파일 조각 및 전체 파일;
• 리포지토리 또는 아카이브(archive) 업로드;
• 파일 경로 및 리포지토리 메타데이터;
• 환경 세부 정보 및 식별자;
• 목적지 엔드포인트(endpoint) 및 클라이언트 버전.

이 목록은 클라이언트가 실제로 구성한 내용을 나타내야 합니다. 정적인 문서 테이블이나 에이전트가 통상적으로 무엇을 보내는지에 대한 추측으로부터 생성되어서는 안 됩니다.

리포지토리에서의 첫 번째 영수증은 가장 많은 주의를 기울여야 합니다. 이후의 영수증은 차이점(delta)을 강조할 수 있습니다: 새로 포함된 디렉토리, 더 큰 아카이브, 다른 업로드 엔드포인트, 또는 이전 클라이언트 버전에는 없었던 필드 등입니다. 개발자는 가공되지 않은 JSON을 읽지 않고도 변경 사항을 이해할 수 있어야 합니다.

승인만으로는 부족합니다; 편집이 유용한 상호작용입니다

**Allow (허용)**와 **Cancel (취소)**만 있는 모달창은 검토 과정을 단순한 형식적인 절차(ceremony)로 전락시킵니다. 각 항목을 그 자리에서 수정할 수 있을 때 영수증(receipt)은 더욱 유용해집니다.

예를 들어, 개발자는 다음과 같은 작업을 수행할 수 있습니다:

1. 이 요청에서 파일이나 경로를 제거합니다.
2. 비밀값(secret-looking value)처럼 보이는 값을 로컬 플레이스홀더(placeholder)로 교체합니다.
3. 선택된 작업 파일(working files)은 유지하면서 Git 히스토리는 제외합니다.
4. 남은 페이로드(payload)를 한 번에 승인합니다.
5. 검토를 위해 최종 영수증을 로컬에 저장합니다.

이는 의도적으로 일반적인 데이터 손실 방지(DLP, Data-loss-prevention) 시스템보다 범위를 좁게 설정한 것입니다. 한 명의 개발자가 .env.example, 내부 경로, 또는 전체 Git 히스토리가 요청에 포함되어 있다는 사실을 알아차리는 데 조직 전체를 아우르는 분류 엔진(classification engine)까지 필요하지는 않기 때문입니다.

도구는 또한 자신의 한계를 명확히 보여주어야 합니다. 두 번째 업로드 경로에 여전히 원본 값이 포함되어 있다면, 표시된 필드를 가리는 것(redacting)은 무의미합니다. 따라서 영수증은 최종 페이로드가 조립된 후에 생성되어야 하며, 제출에 포함된 모든 외부 송신 요청(outbound request)을 포괄해야 합니다.

로컬 기록은 클라이언트 드리프트(client drift)를 포착할 수 있습니다

승인 후, 도구는 영수증, 타임스탬프, 목적지, 그리고 CLI 버전을 포함하는 작은 로컬 기록을 저장할 수 있습니다. 이 기록은 기본적으로 민감한 소스 자료를 중복해서 저장하지 않도록 해야 합니다. 해시(hashes), 필드 이름, 바이트 수(byte counts), 그리고 명시적인 가림 표시(redaction markers)만으로도 비교하기에 충분할 수 있습니다.

이를 통해 실질적인 검토 영역이 생성됩니다. 보안 책임자(security lead)는 두 버전을 비교하여 왜 리포지토리 히스토리가 나타났는지, 왜 페이로드 크기가 급격히 변했는지, 또는 왜 새로운 엔드포인트(endpoint)가 도입되었는지 질문할 수 있습니다. 이 아티팩트(artifact)가 원격 서비스가 무엇을 보관했는지를 증명하는 것은 아니며, 결코 그렇게 주장해서도 안 됩니다. 이는 사용자가 승인한 클라이언트 측 전송 결정(client-side transmission decision)을 기록하는 것입니다.

그러면 팀 정책은 단순하고 감사 가능(auditable)한 상태로 유지될 수 있습니다:

• 리포지토리(repository) 또는 아카이브(archive) 업로드 전에 항상 일시 중지할 것;
• 알려진 비밀 패턴(secret patterns)이 마스킹(redacted)되지 않은 경우 차단할 것;
• 새로운 외부 송신 필드(outbound fields)가 나타나면 두 번째 승인을 요구할 것;
• 정의된 기간 동안 메타데이터 전용 영수증(metadata-only receipts)을 보관할 것;
• 인터셉터(interceptor)가 변경된 프로토콜을 파싱(parse)할 수 없을 때 'fail closed'(차단 상태로 실패)할 것.

마지막 규칙이 중요합니다. 클라이언트 업데이트로 인해 인증서 처리, 요청 구조 또는 저장 프로토콜이 변경될 경우, 아무런 알림 없이 통과(pass-through) 방식으로 전환되는 것은 제품의 목적을 저해합니다. 사용자는 영수증이 불완전하며 전송이 진행되지 않았다는 명시적인 메시지를 받아야 합니다.

가장 신뢰할 수 있는 최소한의 구현

첫 번째 버전은 테스트된 하나의 Grok Build 릴리스와 두 가지 경로, 즉 모델 요청(model requests) 및 리포지토리 저장소 업로드(repository storage uploads)만을 지원하면 됩니다. 이는 로컬 프록시(proxy) 또는 래퍼(wrapper)로 실행되어 해당 요청들을 고정된 스키마(schema)로 파싱하고, 터미널에 영수증을 제시할 수 있습니다.

수용 기준(acceptance criteria)은 구체적입니다:

• 영수증이 렌더링되고 승인되기 전에는 아무것도 외부로 나가지 않을 것;
• 프롬프트(prompts), 파일 내용, 경로, 식별자 및 리포지토리 업로드가 별개의 항목으로 나타날 것;
• 항목을 제거하거나 교체하면 최종 외부 송신 페이로드(outbound payload)가 변경될 것;
• 저장된 로컬 기록에 CLI 버전과 승인된 필드가 식별될 것;
• 알 수 없는 요청 형태(request shape)가 나타나면 검사를 우회하는 대신 전송을 중단할 것.

재현 가능한 데모는 가짜 키(fake keys)가 포함된 일회용 리포지토리를 사용하고, 승인된 영수증을 캡처된 외부 송신 세션(outbound session)과 비교해야 합니다. 그렇게 하면 사용자에게 또 다른 불투명한 보안 계층을 신뢰하라고 요구하지 않고도 핵심 약속을 테스트할 수 있습니다.

이에 반대하는 가장 강력한 논거

프로토콜이 너무 빠르게 변경될 수 있습니다. 제3자 인터셉션 계층(interception layer)은 영구적인 호환성 프로젝트가 될 수 있으며, 인증서 피닝(certificate pinning) 또는 암호화된 업로드 형식은 신뢰할 수 있는 파싱을 불가능하게 만들 수 있습니다. 또한, 에이전트가 다른 프로세스를 실행하거나 도구가 관찰하지 못하는 경로를 통해 전송하는 경우, 래퍼(wrapper)는 잘못된 안전감을 조성할 수도 있습니다.

사용성 비용(usability cost) 또한 존재합니다. 만약 모든 요청마다 방대한 체크리스트가 생성된다면, 개발자들은 이를 기계적으로 승인하게 될 것입니다. 따라서 유용한 기본값(defaults)은 작고 반복적인 페이로드(payloads)는 조용히 처리하면서, 의미 있는 변경 사항에는 주의를 집중시키도록 만들어야 합니다. 제품은 자신의 인벤토리(inventory)가 완전하다는 것과, 영수증(receipt)을 편집하는 것이 실제로 전송되는 바이트(bytes)를 편집한다는 것을 증명해야 합니다.

이러한 제약 사항들 때문에, 이 도구는 모든 코딩 에이전트(coding agent)를 위한 보편적인 약속이라기보다는, 좁게 테스트되고 버전이 고정된(version-bound) 도구로서 시작되어야 합니다.

소스 목록, 관찰된 버전 경계(observed-version boundary), 완전한 제품 개요(product brief), 그리고 구현 시 주의 사항(implementation caveats)은 RayTally의 Grok 외부 송신 영수증 페이지에서 확인할 수 있습니다.

코딩 에이전트가 리포지토리(repository)를 업로드하도록 허용하기 전에 여러분이 확인해야 할 것은 무엇인가요: 파일 목록, 페이로드 차이(payload diff), 엔드포인트 인벤토리(endpoint inventory), 로컬 감사 기록(local audit record), 아니면 다른 무엇인가요?