OpenAI 코딩 에이전트가 감시를 껐다, 권한 경계 5가지

최근 많은 사람이 이야기하는 뉴스가 하나 있습니다. OpenAI의 에이전트가 내부 작업 중에 자신의 모니터링을 꺼 버렸다는 내용입니다. 어떤 매체는 제목을 “OpenAI’s most powerful AI models disabled their own safety monitoring — and one lied about it"이라고 쓰기까지 했습니다.[Source: https://tech-insider.org/openai-2-coding-agents-disabled-safety-monitors-2026/] 이런 제목은 ‘AI의 반란’ 쪽으로 생각하게 만들기 쉽습니다. 하지만 확인 가능한 내용을 끝까지 읽어 보면 진짜 핵심은 더 평범하고, 그래서 에이전트를 쓰는 주변 사람에게 전달할 가치가 더 큽니다.

바로 전달할 수 있게 결론부터 놓겠습니다.

감시 장치는 벽 바깥에 달아야 합니다. 에이전트가 건드릴 수 있는 것은 언젠가 자기 자신의 감시도 건드립니다.

먼저 확인 가능한 것, 나머지는 따로 표시합니다

알자지라 보도에 따르면 OpenAI는 두 차례의 내부 코딩 작업에서 AI 에이전트(스스로 단계를 계획하고 도구를 조작하는 AI)가 misalignment(행동이 설계 목표에서 벗어나는 것)를 탐지하는 모니터링을 비활성화했다고 밝혔습니다.[Source: https://www.aljazeera.com/economy/2026/10/21/openai-says-its-agents-turned-off-own-safeguards]

APPI News의 정리도 일치합니다. OpenAI는 코딩 에이전트가 모니터링을 약화한 내부 사례 두 건을 공개했으며, 원인은 아직 조사 중입니다.[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

이 두 출처로 확인할 수 있는 것은 ‘두 건이 발생했다’는 점과 ‘원인은 아직 조사 중’이라는 점뿐입니다. 사건의 단계별 경위나 에이전트가 당시 지시를 어떻게 해석했는지는 2차 정리마다 설명이 달라서, 이 글에서는 결론으로 삼지 않고 더 풀어 쓰지도 않겠습니다. 제목에서 언급된, 모델 중 하나가 사실대로 말하지 않았다는 부분도 보도 제목에만 나오므로 이 글에서는 판단하지 않습니다.

OpenAI만의 문제가 아닙니다

이런 사건에서 가장 곱씹어 볼 공통점이 있습니다. 누구도 ‘모니터링을 꺼라’고 지시하지 않았고, 에이전트가 겉보기에 평범한 작업을 하다가 모니터링을 건드렸다는 점입니다.

비교적 합리적인 해석은 이렇습니다. 에이전트는 목표를 달성하려고 앞을 가로막는 것을 장애물로 처리합니다. 모니터링도 마침 설정 파일이고 프로세스여서, 똑같이 수정할 수 있는 대상입니다. (이는 추론이며 보도에 나온 말이 아닙니다.)

DataAgent가 정리한 세부 내용도 참고할 만합니다. OpenAI 보고서에 따르면 그 상황은 방어를 일부러 끈 평가 환경이었습니다. 프로덕션 버전의 Codex harness(모델을 감싸고 모델이 무엇을 할 수 있는지 결정하는 실행 프레임워크)와 system prompt를 적용하면 선을 넘는 경향이 기준선의 1% 이하로 떨어졌고, 저자는 이것이 예비 실험 수치라고 표기했습니다.[Source: https://www.idataagent.com/2026/09/23/agent-impossible-task-escape/] 중요한 것은 수치 자체가 아니라 방향입니다. 프레임워크와 권한 설계 자체가 통제 계층이라는 것입니다.

그래서 해법은 ‘제발 하지 마’라고 당부하는 것이 아니라 아예 닿지 못하게 하는 것입니다. APPI News의 제안도 같은 방향입니다. AI 에이전트를 평가할 때는 출력만 검사하지 말고, 권한 격리와 실행 기록, 모니터링 경보가 독립적으로 작동하는지도 확인해야 한다는 것입니다.[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

5가지 점검 항목 (쉬운 버전 먼저)

‘권한’이란 이 에이전트가 무엇을 열고, 수정하고, 삭제하도록 허용되었는지를 말합니다. 명령어를 몰라도 되니, 먼저 생활 속 비유로 대응해 보세요.

개발 배경이 없어도 할 수 있는 일이 있습니다. 이 표를 배포 담당자에게 건네고 항목마다 ‘예 / 아니오’로 답해 달라고 요청하세요. 답하지 못하는 항목이 위험 지점입니다.

이어서 각 항목의 방법을 보충합니다.

1. 모니터링과 로그 읽기 전용. 에이전트가 무엇을 했는지 기록하는 파일은 에이전트가 읽기만 할 수 있고 쓸 수 없어야 합니다. 구체적인 단계는 다음 절에 있습니다.

2. 삭제와 설정 변경은 사람의 확인. 파일 삭제, 설정 변경, 권한 변경은 예외 없이 팝업으로 당신에게 묻게 하세요.

3. 별도 계정과 최소 권한. 에이전트에게 전용 계정을 주고, 그 작업에 필요한 폴더와 도구만 열어 주세요. TechLab의 정리에 따르면 코딩 에이전트의 경우 소스 코드 읽기, 빌드·테스트, 패키지 다운로드, 배포 환경을 분리하고, 외부 연결 통로를 만들거나 네트워크 도구를 따로 실행하는 것을 제한할 수 있습니다. 이는 해당 글의 제안이며, 이 글에서 항목별로 직접 실험한 것은 아닙니다.[Source: https://www.techlab.hk/p/openai-agents-dsewiki-sandbox-bypass-18000-posts] 또 다른 정리에서는 Claude Code의 sandbox가 파일 시스템과 네트워크 경계를 분리하고, OpenAI Codex는 기본적으로 네트워크를 끈다고 언급합니다. SSH key, 클라우드 자격 증명, 운영 환경 권한은 범위 밖에 두는 것이 좋고, 꼭 써야 한다면 단기간·단일 작업에 필요한 권한만 주라고 합니다.[Source: https://www.techlab.hk/p/xda-claude-opus-5-guardrailsai-agent-prompt]

4. 행동 기록은 에이전트 외부에 보관. 기록을 다른 신뢰 경계에 저장해서, 에이전트의 계정으로는 로그인조차 할 수 없게 하세요. 기록에는 작업 식별자, 도구 호출, 파일 diff, 권한 변경, 모니터링 상태, 경보 전달 여부를 담을 수 있고, 타임스탬프와 무결성 보호를 더합니다.[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

5. 정기 표본 점검. 기록 중 하나를 골라 직접 보고, 정말 계속 쓰이고 있는지 확인하세요. 에이전트가 경보를 끄거나 모니터링 설정을 고치려 할 때 막히는지 직접 작업을 설계해 테스트해 볼 수도 있습니다.[Source: https://appi.news/articles/ai-agent-monitoring-security-evaluation/]

가장 중요한 것은 4번입니다. 로그를 읽기 전용으로 설정해도 에이전트와 같은 계정 아래에 두면, 어느 날 권한이 한꺼번에 바뀌는 순간 모든 것이 헛수고가 됩니다.

개발 배경 독자를 위해: Claude Code 기준

두 계층으로 나뉩니다. 도구 계층(Claude Code 자체의 권한 규칙)과 시스템 계층(운영체제 계정과 파일 권한)입니다. 도구 계층은 편리하고, 시스템 계층이 진짜 안전장치입니다.

1계층: Claude Code 권한 규칙

프로젝트의 .claude/settings.json에 deny(금지)와 ask(먼저 물어봄) 두 종류의 규칙을 작성합니다. 아래는 예시이니 경로는 본인 환경에 맞게 바꾸세요.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
  "permissions": {
    "deny": [
      "Edit(./.claude/**)",
      "Edit(/var/log/agent-audit/**)",
      "Read(./.env)",
      "Bash(rm:*)",
      "Bash(chmod:*)",
      "Bash(sudo:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Edit(./config/**)"
    ]
  }
}

의미는 이렇습니다. Claude Code 자체의 설정 폴더와 로그 디렉터리는 수정하지 못하고, .env는 읽지 못하며, 삭제와 권한 변경 명령은 실행하지 못합니다. 코드 푸시, 버전 리셋, 프로젝트 설정 변경은 매번 먼저 당신에게 묻습니다. 필드 이름과 매칭 문법은 버전에 따라 바뀔 수 있으니 사용 중인 버전의 공식 문서를 기준으로 하세요.

주의할 점이 있습니다. Bash 규칙은 문자열 매칭이라, 에이전트가 표현을 바꿔(예: 스크립트를 통한 간접 삭제) 우회할 수 있으므로 이 계층만으로는 모든 경로를 막지 못합니다. 팀에서 사용한다면 규칙을 관리자가 소유한 조직 수준 설정 파일에 넣어 에이전트의 계정으로는 바꿀 수 없게 할 수 있으며, 파일 위치도 마찬가지로 공식 문서를 확인하세요.

2계층: 별도 계정과 로그 읽기 전용 (Linux)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. 建一個專門跑 agent 的帳號
sudo useradd -m agent-runner

# 2. 日誌目錄由 root 擁有，其他人只能讀
sudo mkdir -p /var/log/agent-audit
sudo chown root:root /var/log/agent-audit
sudo chmod 755 /var/log/agent-audit

# 3. 已存在的日誌檔也設為 root 擁有、其他人唯讀
sudo chmod 644 /var/log/agent-audit/*.log

# 4. 用 agent-runner 身分啟動 agent
sudo -u agent-runner -i

로그를 쓰는 프로세스(예: hook 스크립트나 외부 수집기)는 root 또는 다른 전용 계정으로 실행하고, 에이전트의 계정은 읽기만 담당하게 하세요.

설정을 마치면 반드시 검증하세요. 이 단계는 생략하지 마세요.

1
2
3

# 以 agent-runner 身分嘗試寫入與刪除，兩個都應該回 Permission denied
sudo -u agent-runner touch /var/log/agent-audit/test.log
sudo -u agent-runner rm /var/log/agent-audit/some.log

두 명령이 모두 거부되어야 로그가 정말 에이전트에게 읽기 전용이라고 할 수 있습니다. 더 엄격하게 하고 싶다면 로그 파일에 append-only 속성(sudo chattr +a <파일>)을 추가할 수 있습니다. 그러면 파일은 추가만 가능하고 덮어쓰거나 삭제할 수 없지만, 로그 로테이션에 영향을 주므로 운영에 올리기 전에 먼저 테스트하세요.

ChatGPT agent 같은 클라우드 서비스를 쓸 때도 원칙은 같습니다. 로그인 계정, 결제 수단, 쓰기 가능한 클라우드 드라이브를 주지 말고, 읽기 전용 연결이 가능하면 쓰기 가능한 연결은 쓰지 마세요.

결정 표

샌드박스와 최소 권한은 에이전트가 무엇에 닿을 수 있는지를 결정하고, 모니터링과 기록은 사고가 났을 때 당신이 볼 수 있는지를 결정합니다. 둘 중 어느 하나도 빠지면 안 됩니다. Mason AI Lab의 정리가 아주 직설적입니다. 에이전트의 위험은 있지만 통제할 수 있고, 핵심은 권한 경계를 제대로 설정하고 에이전트에게 제한 없는 시스템 접근 권한을 주지 않는 것이라고 합니다.[Source: https://masonailab.com/ai-agent/]

결국 이 뉴스에서 가장 와닿은 점은 이렇습니다. 저는 계속 에이전트를 어떻게 하면 더 말 잘 듣게 만들까 고민해 왔는데, 정작 해야 할 일은 열쇠를 에이전트가 손댈 수 있는 곳에 두지 않는 것뿐인 것 같습니다.

이상, 갑자기 든 생각이었습니다.