하네스 안쪽: 턴 범위 권한이 에이전트 런타임의 기본 요소가 되고 있다

7월 중순에 등록된 OpenAI Codex 저장소 이슈 하나가 있다. 대부분의 출시 글보다 에이전트 런타임이 어디로 가는지 더 많은 것을 알려준다. 제보자는 Codex에서 한 턴이 실행 중일 때 권한 모드를 바꾸면 실행 중인 턴이 그 변경을 무시한다는 것을 발견했다. 시작할 때 가지고 있던 권한을 그대로 유지하고, 새 설정은 다음 턴에만 적용된다. 턴 도중 접근 권한을 높여도 에이전트는 계속 차단된다. 턴 도중 낮추면 더 곤란하다. UI는 제한됐다고 표시하지만 에이전트는 몇 분 더 원래 권한을 유지한다.

이 동작은 흔히 생각하는 의미의 버그가 아니다. 에이전트 런타임 전반에서 조용히 표준이 되어가는 설계 결정의 눈에 보이는 가장자리다. 권한은 턴 범위로 묶이고, 턴이 시작될 때 스냅샷으로 고정되며, 사용자나 기계나 세션이 아니라 해당 작업 단위의 속성으로 다뤄진다. 이 글에서는 이 기본 요소가 무엇인지, 어떤 위협 모델에 답하는지, 그리고 현재 가장 좋은 참조 구현인 Codex가 실제로 어떻게 연결하는지 살펴본다.

핵심 요점 - 턴 범위 권한이란 턴이 시작될 때 런타임이 승인 정책, 샌드박스 정책, 권한 프로필을 스냅샷으로 고정하고 그 턴의 모든 도구 호출이 그 스냅샷을 기준으로 실행되는 모델이다. - 위협 모델의 주인공은 악의적인 사용자가 아니다. 적대적 지시(프롬프트 인젝션)를 따르거나 작업에서 벗어나는 유능한 에이전트가 사용자의 자격 증명으로 사용자의 기계에서 실행되는 상황이다. - Codex는 경계를 세 개의 독립된 조절 장치로 구현한다. 승인 정책(물어볼 것인가), 샌드박스 모드(명령이 무엇을 건드릴 수 있는가), 권한 프로필(세밀한 파일시스템 및 네트워크 규칙)이며 모델이 아니라 OS가 집행한다. - 집행은 모델 아래에 있다. macOS에서는 Seatbelt, Linux에서는 bubblewrap과 seccomp, Windows에서는 전용 샌드박스를 사용한다. 정책을 집행할 수 없는 경우 Codex는 명령 실행을 거부한다. - 아직 해결되지 않은 최전선은 턴 도중의 변경이다. 현재 스냅샷은 턴이 살아 있는 동안 불변이며, 안전하지만 가끔은 사람을 미치게 한다.

무슨 일이 있었나

7월 말부터 8월 초까지 Codex의 권한 표면은 거친 설정 두 개에서 정책 엔진에 가까운 형태로 두꺼워졌고 문서도 뒤따라 정리됐다. 이전 모델은 config.toml 안의 두 조절 장치였다. sandbox_mode (read-only, workspace-write, danger-full-access)와 approval_policy (untrusted, on-request, never)다. 새 모델에는 현재 베타인 permission profiles가 추가됐다. 이름을 붙이고 조합할 수 있는 정책으로, 파일시스템 규칙(경로별 read, write, deny, 충돌 시 deny 우선)과 네트워크 규칙(로컬 프록시로 집행하는 도메인 허용 목록)을 함께 구성한다. 런타임에는 :read-only, :workspace, :danger-full-access라는 세 개의 기본 프로필이 포함되며, 처음부터 새로 만들기보다 이를 확장하는 방식이다.

설정 표면과 함께 상호작용 모델도 턴 중심으로 바뀌었다. /permissions로 실행 중인 세션 안에서 모드를 바꿀 수 있다. 세분화된 승인 정책을 사용하면 일부 프롬프트 범주, 예를 들어 샌드박스 권한 상승과 MCP elicitation은 대화형으로 유지하면서 다른 범주는 자동 거부할 수 있다. 여기에는 작업 도중 에이전트가 스스로 더 많은 접근을 요청하는 별도 request_permissions 범주도 있다. 또한 OpenAI의 승인 및 보안 문서에 따르면 승인을 자동 검토 에이전트로 전달해 사람이 보기 전에 데이터 유출, 자격 증명 탐색, 파괴적 작업을 선별하게 할 수도 있다.

이 모든 것이 한 번의 발표에서 나온 것은 아니다. 운영체제가 현실과 부딪히며 마지못해 사용자 계정을 갖추게 됐듯, 런타임이 현실과 부딪히며 권한 계층을 키우고 있는 과정이다.

OpenAI Codex는 거친 두 설정(샌드박스 모드, 승인 정책)에서 경로별 파일시스템 규칙과 프록시 기반 네트워크 도메인 규칙을 결합한 이름 있는 권한 프로필로 발전했다. 실행 중 세션 전환, 세분화된 승인 범주, 선택형 자동 검토 에이전트도 포함된다. 공식 권한 문서와 승인 문서에 따른 내용이다.

“턴 범위”가 실제로 뜻하는 것

내가 찾은 가장 깔끔한 정의는 이렇다. 에이전트가 할 수 있는 일의 집합은 단일 턴의 수명에 묶이고, 턴 시작 시점에 캡처되며, 원칙적으로 턴이 끝나면 해제할 수 있다. 사용자가 에이전트가 일하는 동안 한 시간 자리를 비울 수도 있으니 사용자에 묶이는 것이 아니다. 위험도가 아주 다른 여러 턴이 같은 기계에서 돌 수 있으니 기계에 묶이는 것도 아니다. 오전에는 코드를 검토하고 점심 뒤에는 의존성을 설치할 수 있으니 세션에 묶이는 것도 아니다.

이 글을 시작하게 한 Codex 이슈는 스냅샷이 실제로 존재한다는 증거다. 제보자의 표현대로 실행 중인 턴은 “턴 시작 시 생성된 권한 또는 샌드박스 스냅샷을 유지”한다. 그들이 제안한 수정안은 새 승인 정책, 샌드박스 정책, 권한 프로필을 활성 턴으로 전파하는 장치를 넣거나, 그게 어렵다면 사용자가 다시 프롬프트를 입력하지 않아도 새 권한으로 턴을 재시작할 수 있도록 내부적으로 일시 중지 후 재개하는 것이다. 수용 기준을 읽어보면 턴 범위 권한을 1급 런타임 개념으로 정의한 사양처럼 보인다. 턴 도중 권한을 낮추면 이후의 위반 작업을 막아야 하고, 높이면 에이전트의 차단을 풀어야 하며, 재개되거나 위임되거나 압축된 턴은 업데이트된 컨텍스트를 유지해야 한다.

그런데 왜 굳이 스냅샷을 만드는가? 대안이 더 나쁘기 때문이다. 권한이 변경 가능한 전역 상태라면 에이전트가 읽는 콘텐츠를 포함해 그 상태에 영향을 미칠 수 있는 모든 것이 다음에 에이전트가 할 수 있는 일을 바꾸는 지렛대를 갖게 된다. 턴마다 불변 스냅샷을 사용하면 명확한 의도가 있는 순간에 사람이나 정책이 권한 결정을 한 번 내리고, 에이전트는 실행 도중 말로 그 경계를 넘을 수 없다. 턴이 가장 작은 신뢰 단위가 되는 셈이다. 실제 에이전트 작업이 쪼개지는 방식과도 맞는다. “이 diff를 검토해”와 “main에 push해”는 같은 세션에 있더라도 절대로 같은 권한 컨텍스트를 공유해서는 안 된다.

Codex는 권한을 턴 시작 스냅샷에 묶는다. 2026년 7월 이슈는 턴 도중 접근 모드를 바꿔도 실행 중인 턴에 영향을 주지 않는다고 기록하고, 업데이트된 승인 정책, 샌드박스 정책, 권한 프로필을 활성 턴으로 전파하며 재개 및 위임된 턴도 새 컨텍스트를 유지하도록 하는 방안을 제안한다.

이 모델이 답하는 위협

여기는 정확하게 말할 필요가 있다. “에이전트 보안”이라는 표현은 막연한 걱정을 너무 많이 덮고 있기 때문이다. 턴 범위 권한 뒤의 위협 모델에는 이름 붙일 수 있는 세 주체가 있고, 그중 후드티를 입은 해커는 없다.

프롬프트 인젝션이 대표적인 위협이다. 에이전트는 하루 종일 신뢰할 수 없는 콘텐츠를 읽는다. 저장소, 웹페이지, 이슈 티켓, 도구 출력 모두 에이전트를 겨냥한 명령을 포함할 수 있다. OpenAI의 자체 문서는 결과를 꽤 직설적으로 설명한다. 기본 웹 검색 모드는 적대적인 실시간 콘텐츠에 대한 노출을 줄이기 위해 live가 아니라 cached이고, 네트워크 접근을 켜면 인젝션을 당한 에이전트가 신뢰할 수 없는 지시를 가져와 따를 수 있다고 경고한다. 턴 범위이며 기본 네트워크 차단인 샌드박스는 성공한 인젝션이 해당 턴에서 도달할 수 있는 범위를 제한한다.

표류와 과도한 행동은 조용한 위협이다. 정당한 일을 하는 유능한 에이전트도 돌아다닌다. 뭔가를 설치하고, 의존성을 가져오고, “도와주겠다”며 디렉터리를 정리할 수 있다. 샌드박스는 에이전트가 악의적일 필요 없이 이런 상황에 답한다. 그래서 경계는 모델의 좋은 판단이 아니라 OS가 집행한다. macOS의 Seatbelt, Linux의 bubblewrap과 seccomp, Windows의 네이티브 샌드박스다. 플랫폼이 요청한 정책을 집행할 수 없으면 Codex는 샌드박스 없이 실행하는 대신 명령 자체를 거부한다. 낙관적으로 실패하지 말고 닫힌 상태로 실패하라는 원칙이다.

자격 증명 노출은 피해를 증폭한다. 문서의 devcontainer 안내는 이를 분명히 말한다. 컨테이너 안에서 Codex에 전체 접근 권한을 주면 악성 프로젝트가 Codex 자격 증명을 포함해 컨테이너 안의 무엇이든 빼낼 수 있다. 그래서 새 기본 요소들이 비밀 정보에 매우 구체적이다. 쓰기 가능한 워크스페이스에서도 자격 증명 파일을 제외하는 "**/*.env" = "deny" 글롭, 쓰기 가능한 루트 안에서도 읽기 전용으로 보호하는 .git, .codex, .agents, 그리고 DNS 리바인딩 방어를 위해 기본적으로 로컬 및 사설 목적지를 차단하는 네트워크 프록시가 있다. 이는 에이전트형 AI 아키텍처의 더 넓은 질문과 같은 모양이다. 모델은 제안하고 하니스가 결정하며, 비밀은 하니스가 들고 있어야 한다.

Codex의 문서화된 위협 모델은 프롬프트 인젝션(기본 네트워크 차단, 적대적 실시간 콘텐츠 노출을 줄이기 위한 cached 웹 검색), 에이전트 표류(집행할 수 없는 명령을 거부하는 OS 강제 샌드박스), 자격 증명 노출(.env 파일 deny 글롭, .git 및 .codex 경로 읽기 전용, 로컬 네트워크 차단)을 중심으로 한다. OpenAI 보안 문서에 따른 내용이다.

구현이 실제로 맞물리는 방식

자신의 런타임을 설계할 때 훔쳐올 만한 구현 세부사항이 세 가지 있다.

같은 구체성에서는 deny가 write보다 우선하고, write가 read보다 우선한다. 권한 프로필은 먼저 넓은 접근을 허용하고 예외를 깎아낼 수 있다. 워크스페이스는 쓰기 가능, **/*.env는 거부, .devcontainer는 읽기 전용으로 만드는 식이다. 더 구체적인 경로가 넓은 규칙을 덮어쓰며, 쓰기 가능한 상위 경로 안에서도 거부된 하위 경로는 계속 거부된다. 넓게 거부한 영역 안에서 좁은 하위 트리를 다시 열 수도 있다. 예를 들어 ~/Documents는 거부하고 ~/Documents/codex는 쓰기 가능하게 할 수 있다. 최소 권한을 쓰기 권한에서 기억에 의존해 빼내는 방식이 아니라 규칙으로 더해갈 수 있게 해주므로 올바른 우선순위 모델이다.

네트워크 접근과 네트워크 필터링은 별도 스위치다. network.enabled = true는 명령이 네트워크에 접근하도록 한다. 실제로 로컬 프록시를 통해 도메인 규칙을 집행하는 것은 features.network_proxy = true다. 하나만 켜면 거버넌스를 적용했다고 착각하면서 무제한 아웃바운드 접근을 허용할 수 있다. 도메인 규칙은 허용 목록 우선이며 deny가 이기고, localhost와 유사 대상도 명시적으로 허용하지 않으면 차단된다. 로컬 데몬에 접근할 수 있는 샌드박스 에이전트는 실질적으로 샌드박스 처리됐다고 보기 어렵기 때문이다.

기존 시스템과 새 시스템은 합성되지 않는다. 프로필과 레거시 sandbox_mode 설정은 상호 배타적이다. 로드된 설정 중 어디에서든 sandbox_mode가 지정되면 프로필은 무시된다. 엔터프라이즈 관리자는 관리형 allowed_permission_profiles 허용 목록으로 새 모델을 강제할 수 있고, 목록에서 빠진 기본 프로필까지 거부된다. 전체 설계에서 운영 교훈을 하나만 가져간다면 이것이다. “둘 다 적용된다”고 생각하는 권한 시스템 두 개는 실제로 거부하지 않은 것을 거부했다고 믿게 만드는 가장 좋은 방법이다. 하나를 선택하고 /permissions와 /status로 검증한 뒤 넓혀라.

CLI를 넘어 에이전트를 운영하는 팀에도 패턴은 일반화된다. 작업마다 권한 컨텍스트를 스냅샷으로 만들고, 자격 증명은 모델 컨텍스트가 아니라 도구 실행 계층에 두고, 모델 아래에서 집행하며, 작업이 끝나면 모두 만료시켜라. 벤더 런타임을 쓸지 자체 하니스를 쓸지는 구축 대 구매의 문제다. 직접 운영한다면 셀프 호스팅 에이전트의 트레이드오프에 조절 장치가 몇 개 더 붙는다.

Codex 권한 프로필은 구체성 우선 규칙과 함께 deny > write > read 우선순위를 사용하고, 네트워크 활성화와 프록시 기반 도메인 집행을 분리하며, 모호성을 피하기 위해 레거시 샌드박스 설정과 합성되는 것을 거부한다. 관리자는 관리형 허용 목록으로 프로필을 강제할 수 있다. 권한 문서에 따른 내용이다.

지금 무엇을 해야 하나

1. 오늘: 다음 Codex 세션에서 /permissions와 /status를 실행해 실제로 무엇이 적용돼 있는지 확인하라. 적용돼 있다고 생각하는 것이 아니라 실제 상태를 보라. 설정 계층 중 어디에서든 여전히 sandbox_mode를 지정한다면 자신도 모르게 권한 프로필을 사용하지 않는 상태다. 어느 시스템을 쓸지 결정하라.

2. 이번 주: :workspace를 확장하고 **/*.env를 거부하며 실제 호출하는 API 도메인만 허용하는 사용자 정의 프로필 하나를 만들고 network_proxy를 켜라. 신뢰하기 전에 샌드박스 명령인 codex debug로 시험하라. 제3자 코드를 검토한다면 해당 프로젝트 설정에서 :read-only 기반 프로필로 고정하라.

3. 이번 달: 에이전트 런타임을 만들거나 기존 런타임을 감싸고 있다면 턴을 권한 단위로 채택하라. 턴 시작 시 스냅샷을 만들고, 턴 종료 시 만료시키고, 비밀은 모델 컨텍스트 밖에 두고, 집행은 닫힌 상태로 실패하게 하라. 그리고 Codex 자체도 아직 완전히 답하지 못한 열린 질문에 대한 자신의 답을 문서로 적어라. 턴 도중 권한이 바뀌면 무엇이 일어나야 하는가? “다음 턴까지 아무것도 하지 않는다”는 안전하지만, 사용자는 UI에 표시된 내용이 실제 의미를 갖기를 기대할 것이다.

자주 묻는 질문

턴 범위 권한이란 무엇인가?

에이전트 턴이 시작될 때 런타임이 승인 정책, 샌드박스 경계, 파일시스템 및 네트워크 규칙을 캡처하고 그 스냅샷을 해당 턴의 모든 도구 호출에 적용하는 권한 모델이다. 권한은 사용자, 기계, 세션이 아니라 작업 단위의 속성이다. 원칙적으로 턴이 끝나면 해제되므로 상승된 접근 권한이 기본적으로 지속되지 않는다.

에이전트를 제한된 OS 사용자로 실행하는 것과 무엇이 다른가?

OS 사용자는 기계 범위이며 정적이다. 에이전트가 실행하는 모든 작업이 같은 포괄적 경계를 물려받는다. 턴 범위 모델에서는 같은 세션 안에서도 “이 저장소 검토”는 읽기 전용으로, “의존성을 설치하고 테스트”는 워크스페이스 쓰기와 도메인 허용 목록을 가진 상태로 실행할 수 있고 계정을 바꿀 필요도 없다. 또 접근을 자연스럽게 만료시킬 지점이 생기는데 OS 사용자에는 그런 단위가 없다.

프롬프트 인젝션이 Codex의 권한을 바꿀 수 있나?

설계상 한 턴 안에서는 아니다. 실행 중인 턴은 턴 시작 시 만들어진 스냅샷을 기준으로 실행되고, 설정을 턴 도중 바꿔도 전파되지 않는다. 이 동작은 이슈 #32612에 문서화돼 있다. 남는 위험은 다음 턴과 프로필이 이미 허용한 표면이다. 그래서 네트워크 접근은 기본 차단이고 민감한 경로는 거부 또는 읽기 전용으로 둔다.

권한 프로필은 기반으로 삼기에 충분히 안정적인가?

명시적으로 베타이며 이전 sandbox_mode 설정과 합성되지 않는다. 완성된 API라기보다 앞으로 갈 방향으로 보는 편이 맞다. 오늘의 안정적인 기준선은 기존 모드다. 팀에 배포한다면 클라이언트 버전별로 하나의 모델을 선택하고 /status로 동작을 검증하며, 프로필 필드가 당분간 계속 바뀔 것으로 예상해야 한다.

결론

에이전트 권한은 Unix 권한이 성장한 것과 비슷한 길을 가고 있다. “root 아니면 아무것도 없음”에서 세밀하고, 최소 권한이며, 감사 가능한 경계로 이동한다. 다만 단위가 프로세스나 사용자가 아니라 턴이다. 지금 가장 분명하게 공부할 구현은 Codex다. 그리고 가장 거친 모서리인 불변 턴 중간 스냅샷이 오히려 가장 많은 것을 알려준다. 참조 런타임조차 권한이 의미를 잃지 않으면서 어디까지 동적으로 바뀔 수 있는지를 아직 협상하고 있다. 에이전트를 만들거나 운영한다면 지금 이 기본 요소의 형태를 익혀야 한다. 1년 안에 모든 진지한 런타임이 비슷한 것을 갖게 될 것이고, 스냅샷 의미론을 잘못 설계한 곳은 공개적으로 배우게 될 것이다.

자체 에이전트의 권한 계층을 설계하고 있고 다른 시각의 검토가 필요하다면, 나는 고객 팀과 이런 일을 한다. 연락해 달라.

출처

• OpenAI Developers, “Codex 권한”: https://developers.openai.com/codex/permissions (2026년 8월 29일 확인)

• OpenAI Developers, “에이전트 승인 및 보안”: https://developers.openai.com/codex/agent-approvals-security (2026년 8월 29일 확인)

• GitHub, openai/codex 이슈 #32612, “현재 실행 중인 턴에 접근 제어 변경 적용”: https://github.com/openai/codex/issues/32612 (2026년 7월 12일 등록, 2026년 8월 29일 확인)

• GitHub, openai/codex 이슈 #23626, “Codex CLI /permissions가 WSL2에서는 Read-only를 생략하지만 Windows PowerShell에서는 표시”: https://github.com/openai/codex/issues/23626 (2026년 5월 20일 등록, 2026년 8월 29일 확인)

• OpenAI Codex 저장소: https://github.com/openai/codex (2026년 8월 29일 확인)