OpenAI는 OpenClaw 같은 상주형 에이전트를 어떻게 안전하게 운영하는가
TMThttps://developers.openai.com/blog/securing-persistent-agents-like-openclaw-at-openai
거의 1년 전 OpenClaw가 나왔을 때, 세상은 상주형 에이전트(persistent agent)가 무엇을 할 수 있는지 처음 보게 됐습니다. 정해진 목표가 있고 사람이 방향을 잡아 주는 일반 Codex 세션과 달리, 상주형 에이전트는 넓은 범위를 맡아 24시간 내내 돌아가며 사용자의 입력 없이도 먼저 나서서 행동할 수 있습니다.
상주형 에이전트는 엄청난 능력을 갖췄지만, 지금까지 실제 환경에 배포된 사례는 많지 않습니다. 기존 소프트웨어와 비교하면 배포할 때 새로운 과제가 많기 때문입니다. 기존 소프트웨어에서는 설정과 코드가 결정적으로 동작한다고 믿을 수 있었고, 위협은 (대부분) 외부 공격자에게서 온다고 볼 수 있었습니다. 상주형 에이전트는 목표를 이루려고 자기 설정을 바꾸고 임의의 코드를 작성할 수 있습니다. 에이전트가 의도에서 벗어난 행동을 하면, 공격은 내부에서 시작됩니다.
현재 OpenAI는 회사 전체에 상주형 에이전트를 배포해 두었고, 그중 OpenClaw 에이전트만 수백 개에 이릅니다. 이 글에서는 OpenAI가 OpenClaw를 배포하려고 도입한 통제 장치 몇 가지를 소개합니다.
신뢰하는 실행과 신뢰하지 않는 실행을 분리합니다
상주형 에이전트를 안전하게 운영하려면, 신뢰할 수 있는 결정적 로직을 신뢰할 수 없는 LLM 실행과 격리해야 했습니다. 신뢰하는 로직에는 네트워크, 신원, 샌드박스 같은 핵심 구성 요소가 들어갑니다. 이런 로직은 전통적인 정적 코드여서, 소프트웨어 버그가 없다면 설정한 대로 동작해야 합니다. 반면 에이전트와 에이전트가 실행되는 환경, 에이전트가 작성하는 코드는 신뢰하지 않는 대상으로 봅니다. 이 환경에서는 에이전트가 목표를 이루려고 코드를 즉석에서 만들어 낼 수 있고, 그 동작은 어떤 것도 확실히 보장되지 않습니다.
OpenClaw에서 이를 지원하려고, 저희는 결국 오픈 소스 프로젝트에 원격 하네스 실행을 구현했습니다. 덕분에 OpenClaw Gateway를 에이전트 하네스와 다른 컨테이너(저희의 경우에는 아예 다른 클러스터)에서 돌릴 수 있게 됐습니다.
이렇게 나눠 두자, 에이전트를 설정하는 구성 요소인 게이트웨이는 신뢰할 수 있는 결정적 코드로 다루고, 에이전트 워크로드는 신뢰할 수 없는 코드로 보고 샌드박스에 가두는 데 집중할 수 있었습니다.
확실한 보안 경계를 강제합니다
에이전트 워크로드의 보안 경계는 샌드박스로 강제합니다. 샌드박스는 에이전트가 할 수 있는 행동을 제한합니다.
저희는 OpenClaw를 배포하면서 다음과 같은 샌드박스 통제를 적용했습니다.
- 네트워크: 에이전트가 접근할 수 있는 엔드포인트를 통제합니다. 저희는 조직이 관리하는 허용 목록을 쓰고, 제한된 엔드포인트는 명시적으로 차단했습니다.
- 작업 공간: 에이전트가 접근할 수 있는 파일을 통제합니다. 저희는 에이전트의 작업 디렉터리에만 쓰기를 허용했습니다.
- 프로세스: 에이전트가 접근할 수 있는 프로세스를 통제합니다. 저희는 Codex 리눅스 샌드박스의 프로세스 격리에 맡겼습니다.
- 시크릿: 에이전트가 접근할 수 있는 시크릿을 통제합니다. 저희는 자격 증명 브로커로 시크릿을 관리해서 에이전트가 시크릿을 볼 수 없게 했습니다.
OpenClaw 배포에는 Codex 하네스에 내장된 샌드박스를 썼습니다. 아래는 저희가 쓴 설정 일부로, requirements.toml(Codex 설정에서 고를 수 있는 옵션을 제한합니다)과 config.toml(실제 Codex 설정입니다)에 나눠 담았습니다. 추가 보안 통제도 몇 가지 켰다는 점도 덧붙입니다. danger-full-access 모드를 쓸 수 없게 막았고, 캐시된 웹 검색을 쓰도록 해서 웹 검색 쿼리가 OpenAI 자체 인덱스를 거치게 했습니다.
requirements.toml
# Exclude unrestricted "danger-full-access" sandbox mode.
allowed_sandbox_modes = ["read-only", "workspace-write"]
# Permit cached hosted search, but not live hosted search.
allowed_web_search_modes = ["cached"]
# Require the managed network proxy.
experimental_network.enabled = true
# Prevent user-level configuration from expanding the domain allowlist.
experimental_network.managed_allowed_domains_only = true
# Allow only these destinations; replace with the workload's required hosts.
experimental_network.allowed_domains = [
"github.com",
"api.github.com",
"codeload.github.com",
]
# Explicitly block these destinations, including cloud metadata endpoints.
experimental_network.denied_domains = [
"pastebin.com",
"*.pastebin.com",
"webhook.site",
"metadata.google.internal",
"169.254.169.254",
]config.toml
# Select the permission profile defined below.
default_permissions = "openclaw"
# Use cached hosted search.
web_search = "cached"
[permissions.openclaw.filesystem]
# Allow reads needed by the minimal runtime environment.
":minimal" = "read"
# Allow reading and modifying the agent's workspace.
"/home/dev-user/openclaw-workspaces" = "write"
# Allow reading managed assets without modifying them.
"/home/dev-user/read-only" = "read"
# Prevent access to SSH credentials.
"/home/dev-user/.ssh" = "deny"
[permissions.openclaw.network]
# Permit network access through the administrator-required proxy.
enabled = true
# Do not inherit an upstream proxy.
allow_upstream_proxy = false
# Keep the proxy's local/private-address guard enabled.
allow_local_binding = false
# Disable the SOCKS5 listener.
enable_socks5 = false
# Disable SOCKS5 UDP support.
enable_socks5_udp = false
# Do not permit proxy listeners on non-loopback addresses.
dangerously_allow_non_loopback_proxy = false
# Do not permit unrestricted Unix-socket access.
dangerously_allow_all_unix_sockets = false
[shell_environment_policy]
# Preserve default filtering of sensitive environment variables.
ignore_default_excludes = false
# Remove GitHub credentials from agent command environments.
# This does not hide credentials stored in accessible files.
exclude = [
"GH_TOKEN",
"GITHUB_TOKEN",
"OPENCLAW_GITHUB_BASIC_AUTH",
"OPENCLAW_GITHUB_READONLY_BASIC_AUTH",
]
[apps._default]
# Disable apps unless individually enabled.
enabled = false
# Disable destructive app operations by default.
destructive_enabled = false
# Disable open-world app operations by default.
open_world_enabled = false모델 기반 안전장치를 더합니다
지금까지 이야기한 통제는 모두 정적입니다. 에이전트가 의도에서 벗어난 행동을 하지 못하게 막는 일을 전통적인 결정적 코드에 맡긴다는 뜻에서 그렇습니다. 모델이 똑똑해질수록, 컴퓨팅 자원에 비례해 함께 강해지는 방어 수단, 즉 다른 모델도 반드시 갖춰야 합니다.
자동 검토(Auto-review)를 쓰면 두 번째 에이전트가 주 에이전트의 행동을 지켜보고 승인할 수 있습니다. 매번 사람의 검토를 요구하면 검토 피로가 쌓이고, 결국 사람은 권한 요청이 뜰 때마다 생각 없이 수락하는 데 길들게 됩니다. LLM 기반 검토자를 필터로 두면, 사람의 주의력은 가치가 큰 승인에만 아껴 쓸 수 있습니다. 이 기능은 OpenClaw와 Codex 모두 기본으로 지원합니다.
저희는 OpenClaw 배포에서 에이전트의 모든 행동에 자동 검토를 강제합니다.
에이전트 신원을 사용자 신원과 분리합니다
에이전트가 어떤 행동을 하면, 그 행동을 감사할 수 있어야 하고, 에이전트에게 자원 접근 권한을 줄 수 있어야 하고, 그 행동을 에이전트가 시작했는지 사용자가 시작했는지 구분할 수 있어야 합니다. 에이전트 신원이 이를 가능하게 해 줍니다. 에이전트에게 자원에 대한 자체 접근 권한을 주는 WAG 같은 새로운 명세도 있고, OAuth 위임을 통해 에이전트가 사용자를 대신해 행동하게 해 주는 XAA 같은 명세도 있습니다. 에이전트 신원은 봇에게 별도 API 접근 권한을 주는 서비스 계정과 다르다는 점에 유의하세요. 둘은 함께 써야 합니다. 예를 들어 에이전트는 자기 에이전트 신원으로 행동하고, 서드파티 서비스에는 그 신원에 연결된 서비스 계정으로 접근해야 합니다.
저희 OpenClaw 배포에서는 에이전트마다 ChatGPT 서비스 계정에 연결된 고유한 신원이 있습니다. 그래서 에이전트마다 사용자와 분리된 자체 추론 자격 증명을 갖고, 팀은 에이전트에 맞춤 플러그인을 연결할 수 있습니다. 또한 에이전트의 행동을 감사하고, 필요하면 추론을 끊을 수도 있습니다.
모든 것을 관측합니다
관측 가능성을 빈틈없이 갖추면, 운영자는 에이전트가 어떻게 설정됐는지부터 어떤 행동을 했는지까지 에이전트의 전체 수명 주기를 파악할 수 있습니다. 상주형 에이전트에서는 의도에서 벗어난 행동을 추적하고 탐지하려면 이런 관측 범위가 꼭 필요합니다.
저희는 OpenClaw 배포에서 모든 것을 로그로 남깁니다. 컨트롤 플레인의 설정 변경 하나하나와 에이전트의 모든 턴이 기록됩니다. 에이전트 턴에는 민감한 정보가 들어 있을 수 있으므로, 이 로그는 엄격하게 잠가 두고 보안팀의 소수 인원만 볼 수 있게 했습니다.
맺으며
상주형 에이전트 배포는 아직 도입 곡선의 초입에 있습니다. 확립된 모범 사례가 없다 보니, 오늘날 많은 기업이 에이전트를 도입하기 어려워합니다.
OpenAI 내부에서 OpenClaw 파일럿을 시작하자, 회사 전반의 기술 팀과 비기술 팀 모두에서 생산성과 도입률이 크게 뛰었습니다. 지금은 500개가 넘는 에이전트가 백그라운드에서 먼저 나서서 의미 있는 일을 하고 있습니다. 제품 피드백을 받아 PR을 자동으로 여는 일부터 새 기능에 대한 데이터 실험을 끊임없이 돌리는 일까지 다양합니다.
OpenAI 데브데이에서 저희는 오픈 소스이자 특정 벤더에 묶이지 않는 에이전트 컨트롤 플레인인 OpenClaw Enterprise(OCE)를 발표했습니다. OCE에서 표준 Codex 프리셋을 쓰면, 이 글에서 다룬 안전장치 상당수가 기본으로 들어간 에이전트를 띄울 수 있습니다. 프로젝트는 아직 파일럿 단계이고, 연말까지 1.0을 출시할 계획입니다.
저희는 산업 현장에서 AI가 가져올 가장 큰 성과 상당수가 상주형 에이전트에서 나올 것이라고 믿습니다. 저희가 배운 것을 공유하고 OCE를 공개적으로 만들어 가면서, 누구나 상주형 에이전트를 더 안전하게 배포할 수 있기를 바랍니다.