지시는 채널로, 데이터는 기기에
Instruction Over the Channel, Data on the Device — Local-first AI 배포
When supporting sensitive customers, the strongest control is not "upload securely" — it is designing boundaries so the raw material never leaves the customer's device in the first place. Only instructions and status flow over the remote channel; data and tools stay local, behind least-privilege access and human approval gates. This journal maps a Local-first Deployment Boundary across data, instruction, tool, evidence, decision, and audit planes, and shows why an allowlist alone is not enough against prompt injection and data exfiltration.
핵심 주장: 민감한 고객을 지원할 때 가장 강한 통제는 "안전하게 업로드"가 아니라, 애초에 원문이 고객 기기를 떠나지 않도록 시스템 경계를 설계하는 것이다.
현장 문제
변호사 사건 자료처럼 원문 자체가 위험 자산인 경우, 클라우드로 올리는 순간 통제권을 일부 잃는다. 그래서 설계의 출발점을 바꾼다. "어떻게 안전하게 올릴까"가 아니라 "올리지 않고 어떻게 도울까".
시스템 경계와 의사결정
- 원문은 로컬에서 처리하고 PII를 마스킹한다. 검토 패킷(마스킹본)만 모델로 간다.
- Telegram/cokacdir 같은 원격 채널에는 명령과 상태만 흐른다. 원문 데이터는 흐르지 않는다.
- 서버 Codex CLI, Tailscale SSH, Telegram trigger, Codex Cloud는 각각 권한 경계가 다르다. 공개 SSH가 아니라 전용 키 + Tailscale로 접근면을 좁힌다.
allowlist만으로 부족한 이유
도구 allowlist는 시작점일 뿐이다. 실제 위협은 더 교묘하다.
- Prompt injection — 읽은 문서/웹페이지가 모델에게 몰래 지시를 심는다.
- URL 데이터 유출 — 모델이 민감정보를 외부 URL에 실어 보내도록 유도.
- Redirect 위험 — 신뢰 도메인처럼 보이는 우회.
그래서 allowlist에 더해 human-in-the-loop, 승인 게이트, 이벤트 로그, pause, rollback을 둔다. 그리고 인증 실패를 숨기지 않는다.
인증 실패를 숨기지 않는 운영
최근 GITHUB_TOKEN이 401(만료)로 죽은 사례에서 원칙 하나를 다시 확인했다. SSH로는 push가 되더라도, API 인증·Git remote·Pages 배포는 별도로 판정해야 한다. "공개 조회 성공"을 "push 권한 정상"으로 오해하지 않는다. 상태코드(200/401/403)만 기록하고 토큰 원문은 어떤 로그·문서·메시지에도 남기지 않는다.
실패 가능성과 안전장치
- 마스킹 누락 → 마스킹은 코드로 강제하고, 검토 패킷을 사람이 승인 게이트에서 확인.
- 주입된 악성 지시 → 도구는 최소권한, 외부로 나가는 액션은 승인 필요.
- 비밀 유출 → 감사 로그는 비밀 제거 후 이벤트만 남긴다.
측정 지표
- 원문이 기기를 떠난 횟수 = 0 (구조적으로 보장)
- 외부로 나가는 액션 중 승인 게이트를 통과한 비율
- 인증/도구 실패가 은폐 없이 로그에 남은 비율
재사용 패턴 — Local-first Deployment Boundary
- Data plane — 고객 기기 (원문은 여기 머문다)
- Instruction plane — 승인된 원격 채널 (명령·상태만)
- Tool plane — 최소권한 도구
- Evidence plane — 검증 가능한 공식 데이터(MCP 등)
- Decision plane — 도메인 전문가
- Audit plane — 비밀이 제거된 이벤트 로그
내 경험과의 연결
휴대폰 한 대로 다중 에이전트(지시·실행·검수)를 원격 조율하면서도, 실행과 데이터는 서버·기기 안에 두는 구조를 실제로 운영했다. 원격에서 지시만 흐르고 민감 데이터는 움직이지 않는다 — 이 경계가 신뢰의 근거였다.
영어 면접 질문 3개
Q1. A client cannot let case files leave their laptop. How do you still help remotely?
답변 포인트: local 처리 + PII 마스킹, 채널엔 명령·상태만. Data plane은 기기.
Q2. Why is an allowlist not enough for a tool-using agent?
답변 포인트: prompt injection·URL exfiltration·redirect. 승인 게이트·로그·rollback 추가.
Q3. Your token auth failed but SSH worked. What do you report?
답변 포인트: API·remote·Pages 별도 판정. 상태코드만, 토큰 원문 미기록, 실패 은폐 금지.
출처
- OWASP — Top 10 for LLM Applications (prompt injection, data exfiltration)
- Anthropic — Building effective agents (도구·권한 경계)
- OpenAI — Foundations of trustworthy third-party evaluations
다음에 실제로 만들 것
6개 plane을 체크리스트로 만든 Local-first Boundary 감사 시트 — 배포 전 "원문이 기기를 떠나는 경로가 있는가"를 한 장으로 점검.
관련 글: 코드보다 먼저 문제를 배포하라 · 토큰이 어디서 새는지 보라