대부분의 회사에서 신입 사원이 권한을 얻기까지는 며칠이 걸립니다. 노트북, 그다음 이메일, 그다음 필요한 단 하나의 리포지토리(repo), 그리고 모든 추가 권한은 누군가가 투덜거리는 티켓(ticket)을 통해 처리됩니다.

반면 AI 에이전트는 약 1분 만에 온보딩(onboarding)됩니다. 전체 셸(Full shell). 이미 환경 변수에 설정되어 있던 당신의 개인 API 키들. 제한 없는 네트워크. 아무도 신경 쓰지 않는 .ssh 폴더를 포함한 당신의 홈 디렉토리 전체에 대한 읽기 권한. 우리는 사람과 서비스 계정(service accounts)을 위해 최소 권한(least privilege) 원칙을 내재화하는 데 20년을 보냈지만, 정작 에이전트에게는 면접도 없이 첫날부터 계약직 직원에게 주는 것보다 더 많은 권한을 넘겨주었습니다.

저는 보안 분야에서 일하고 있으며, 이것이 현재 어디에서나 보이는 격차입니다. 제가 이 격차를 메우기 위해 생각하는 방식과, 이번 주에 바로 적용할 수 있는 6가지 규칙을 소개합니다.

에이전트가 기존 모델을 깨뜨리는 이유

전통적인 접근 제어(access control)는 계정 소유자가 계정의 동작을 결정한다고 가정합니다. 인턴이 실수를 할 수는 있지만, 지시 사항은 그들의 머리에서 나옵니다.

에이전트는 텍스트로부터 지시를 받습니다. 모든 텍스트 말입니다. 당신이 입력한 프롬프트(prompt)뿐만 아니라, 에이전트가 가져온 웹 페이지, 클론(cloned)한 리포지토리의 README, 읽어 들인 이슈(issue) 댓글, 로드한 도구의 설명까지 포함됩니다. 프롬프트 인젝션(Prompt injection)은 모든 입력 채널이 잠재적인 명령 채널이 될 수 있음을 의미합니다. 모델 벤더(vendors)들이 이에 저항하는 능력을 키워가고는 있지만, 저는 어떤 모델이라도 매번

작업에 필요한 명령만 부여하고 그 외에는 아무것도 허용하지 마세요. 저장소(repo) 작업을 위해서는 Bash(git *), CI 작업을 위해서는 Bash(npm run test)를 부여하십시오. 정당한 작업이 권한 부족으로 실패할 경우에만 목록을 한 줄씩 확장하세요. 이러한 마찰(friction)은 그 가치를 증명합니다. 이는 인턴에게 운영 환경(prod) 접근 권한을 주기 전에 다시 한번 생각하게 만들었던 것과 동일한 마찰이며, 같은 이유로 효과를 발휘합니다.

규칙 2: 에이전트에게 고유한 정체성을 부여하라

에이전트에게 개인용 토큰(personal token)을 절대 넘겨주지 마세요. 작업에 필요한 최소한의 범위(scopes)를 가진 전용 서비스 정체성(service identity)을 부여하고, 자격 증명(credentials)은 수명이 짧게 유지하세요.

두 가지 이유가 있습니다. 첫째, 폭발 반경(blast radius) 때문입니다. 주입된 유출 시도(exfiltration attempt)를 통해 키가 유출되었을 때, 당신의 디지털 삶 전체가 아닌 좁은 범위의 키 하나만 교체하면 됩니다. 둘째, 감사(audit) 때문입니다. 별도의 정체성을 사용하면 어떤 작업이 에이전트의 것이고 어떤 작업이 당신의 것인지 실제로 구분할 수 있으며, 이는 무언가 잘못되었을 때 매우 중요합니다.

규칙 3: 파일 시스템을 격리(jail)하라

에이전트에게 쓰기 권한이 있는 단 하나의 워크스페이스 디렉토리만 부여하세요. 참조 자료는 읽기 전용(read-only)으로 마운트하십시오. 도트파일(dotfiles), 브라우저 프로필, 비밀번호 저장소를 포함한 그 외의 모든 것은 아예 경로를 찾을 수 없도록(not resolve) 해야 합니다.

사람들이 자주 잊는 한 가지는 환경 변수(environment)입니다. 만약 에이전트의 셸(shell)이 상속받는 환경 변수에 비밀 정보(secrets)가 들어 있다면, 모든 env 덤프는 유출 준비가 된 상태이며, "디버깅을 위해 환경 변수를 출력하라"는 명령은 가장 오래된 주입 페이로드(injection payloads) 중 하나입니다. 비밀 정보는 에이전트가 열거(enumerate)할 수 있는 네임스페이스(namespace)가 아니라, 특정 프로세스에 비밀 정보를 전달하는 관리자(manager)나 브로커(broker)에 있어야 합니다.

규칙 4: 네트워크 화이트리스트(allowlist)를 적용하라

비밀 정보를 읽을 수는 있지만 외부 세계에 접속할 수 없는 에이전트는 공격자에게 제공할 수 있는 것이 거의 없습니다. 대부분의 주입 페이로드(injection payloads)는 외부로 나갈 통로가 필요합니다. 그 통로를 차단하십시오.

Egress 허용 목록(allowlists)은 이 목록에서 가장 저렴하면서도 가치가 높은 통제 수단입니다. 에이전트가 진정으로 필요로 하는 도메인을 열거하고, 그 외의 모든 것은 기본적으로 거부(deny)하며, 거부된 내역을 로그(log)로 남기십시오. 거부 로그는 무료 탐지 피드(detection feed) 역할도 겸합니다. 왜냐하면 당신이 승인하지 않은 도메인에 갑자기 접속하려는 에이전트의 시도는 당신이 조기에 포착하고자 하는 바로 그 신호이기 때문입니다.

규칙 5: 되돌릴 수 없는 작업은 게이트(gate)를 설치하십시오

메시지 전송, 콘텐츠 게시, 데이터 삭제, 비용 지출, 액세스 권한 부여와 같이 되돌릴 수 없는 작업에 대해서는 인간의 확인(human confirmation)을 요구하십시오.

그리고 트레이드오프(tradeoff)에 대해 솔직해지십시오. 보안 분야는 알림 피로(alert fatigue)를 통해 이 교훈을 뼈아프게 배웠습니다. 모든 것에 게이트를 설치하면, 내용을 읽지도 않고 '승인'을 클릭하도록 스스로를 훈련하게 되며, 결국 그 게이트는 아무것도 보호하지 못하게 됩니다. 되돌릴 수 있는 작업은 자동화하고, 되돌릴 수 없는 작업은 확인 절차를 거치되, 각 프롬프트를 여전히 읽을 수 있을 만큼 두 번째 목록을 짧게 유지하십시오.

규칙 6: 감사(audit)하고, 그다음 다듬으십시오

도구 호출(tool calls)을 로그로 남기십시오. 2주 후에 로그를 읽고 에이전트가 한 번도 사용하지 않은 모든 권한을 회수하십시오.

권한 상승(Privilege creep)은 인간보다 에이전트에게 더 빠르게 발생합니다. 권한 부여는 클릭 한 번이면 충분하고, 이를 취소하라고 잔소리하는 존재가 없기 때문입니다. 월간 검토만으로도 충분합니다. 질문은 항상 서비스 계정(service account)에 대해 던지는 질문과 같습니다. "이 ID가 실제로 무엇을 했는가, 그리고 왜 그 이상의 일을 할 수 있는가?"

시작 정책 (A starter policy)

오늘 바로 복사해서 사용할 수 있는 정책이 필요하다면, 제가 사용하는 방식의 형태는 다음과 같습니다:

1. 권한(Permissions): 명시적 허용 목록(explicit allowlist), 와일드카드(wildcards) 사용 금지
2. ID(Identity): 전용 키(dedicated keys), 최소 범위(minimal scopes), 짧은 수명(short-lived)
3. 파일 시스템(Filesystem): 하나의 쓰기 가능한 워크스페이스(writable workspace), 그 외에는 읽기 전용(read-only)
...

사고방식 (The mindset)

에이전트를 맥락(context)은 전혀 없지만 무한한 자신감을 가진, 낯선 사람이 편지함에 쪽지를 몰래 넣을 수 있는 건물에서 일하는 유능한 신입 사원처럼 대하십시오. 당신은 그 사람에게 루트(root) 권한을 주지 않을 것입니다.

어느 시점에는 에이전트가 성공적으로 주입될 것이라고 가정하십시오. 충분히 긴 시간이 흐른다면 반드시 그렇게 될 것이기 때문입니다. 최소 권한 (least privilege) 원칙의 목표는 모든 사고를 방지하는 것이 아니었습니다. 인간에게도 결코 그것을 완벽히 해내지 못했습니다. 이 원칙이 한 일은 사고가 발생하더라도 생존 가능하게 만드는 것이었으며, 그것이 바로 여기서의 역할입니다. 즉, 최악의 날이 닥쳤을 때, 그것이 존재론적인 위협이 아니라 그저 성가신 수준에 머물게 하는 것입니다.