이 페이지는 영어 문서의 번역입니다. 명령, 식별자, 예제는 그대로입니다. 런타임 7.24.4 · SDK 2.6.7. 영어 원문

클라우드 운영 모드

상태: 활성 범위: 현재 상태 최종 검토: 2026-09-04 담당: ax-code 런타임

클라우드 운영 모드는 인프라를 관리하기 위해 미리 갖춘 태세입니다. 대상은 클라우드 공급자(AWS, GCP, Cloudflare, OVHcloud, DigitalOcean, RunPod)와 네트워크 장비(VyOS, Juniper Junos)입니다. 이런 곳에서는 실수가 운영 중인 시스템에 영향을 주고, git 롤백으로 상태를 되돌릴 수 없습니다. 내장 cloudops 에이전트로 제공됩니다. 시스템 프롬프트와 권한 태세이며, 규칙을 직접 쓰지 않고 한 번의 선택으로 켭니다.

이 모드가 주는 것

읽기를 먼저 하는 에이전트. cloudops 에이전트는 모든 작업을 목록 조사와 모의 실행으로 시작합니다. 계획과 diff, 롤백 절차가 있기 전에는 변경을 금지하는 프롬프트를 갖습니다.
실행 전에 묻는 셸. bash는 ask으로 설정되므로, 모든 셸 명령이 확인을 받습니다. 클라우드와 네트워크의 변경 동사(aws/gcloud/az/doctl의 삭제 계열, kubectl delete/apply --prune, 계획 파일이 없는 terraform apply, commit-confirm이 없는 ssh 원격 커밋, 컨트롤 플레인 API에 대한 curl 변경)는 bash_destructive로 분류되며, 우회할 수 없는 별도의 대화형 게이트를 갖습니다.
일급 운영 도구. ops_plan, ops_diff, ops_verify, ops_journal는 미리 허용됩니다. ops_approve와 ops_apply는 아래의 대화형 경로에 남습니다.

작업 흐름: 계획 → diff → 승인 → 적용 → 검증 → 저널

ops_plan — OperationPlan을 엽니다. 대상(공급자, 계정, 리전 또는 장비), 의도, 정확한 적용 명령과 명령 맥락, 효과와 되돌릴 수 있음(reversible | hard | irreversible), 영향 범위(low | med | high)가 있는 단계입니다. 정규 계획 해시를 만듭니다.
ops_diff — 기계가 확인할 수 있는 산출물(terraform plan -out, show | compare, CLI 모의 실행 출력)을 만들어 검토하고 첨부합니다. diff가 없으면 승인도 없습니다.
ops_approve — 사람이 해시에 고정된 계획을 승인합니다. 이 게이트는 대화형으로만 통과합니다. 와일드카드 규칙도 자율 모드도 미리 승인할 수 없으며, 오래 남는 “항상 허용” 허가도 제공되지 않습니다.
ops_apply — 승인 토큰으로, 승인된 계획의 변경을 실행합니다. 허가된 유일한 변경 경로입니다. 무엇이든 실행되기 전에 토큰이 사용됩니다.
ops_verify — 계획의 선언적 읽기 전용 단언을 실행하고, 통과와 실패의 증거를 기록합니다.
ops_journal — 추가만 가능한, 프로젝트 범위의 운영 저널을 프로젝트, 계획, 상태로 조회합니다.

모드를 켜기

TUI의 에이전트 선택기에서 Cloud Ops를 고르거나, 범위가 있는 작업에는 cloudops를 @로 멘션합니다. 프로젝트의 기본값으로 만들려면 ax-code.json에 다음을 추가합니다.

{
  "default_agent": "cloudops",
  "isolation": {
    "mode": "workspace-write",
    "network": true
  }
}

workspace-write는 파일 변경을 워크스페이스 안으로 가둡니다. network: true는 webfetch, websearch, 공급자 CLI에 도달할 수 있게 둡니다. 샌드박스 모드에서는 그 밖의 네트워크가 꺼집니다. 샌드박스 모드를 보십시오. 둘 다 에이전트와 독립된 세션 격리 설정이므로, 에이전트 프리셋 안이 아니라 여기에서 구성합니다.

프로젝트마다 agent.cloudops.permission 아래에서 태세를 더 조이거나 넓힐 수 있습니다. 예를 들어 특정 도구를 거부합니다. 저장소에 커밋된 구성은 거부 규칙만 추가할 수 있습니다. ask를 allow로 느슨하게 바꾸는 일은 신뢰하는 사용자 구성이나 관리 구성에서만 와야 하며, 저장소에서는 오면 안 됩니다. 에이전트를 완전히 제거하려면 "agent": { "cloudops": { "disable": true } }를 설정합니다.

따라 하는 예

VyOS 라우터의 방화벽을 바꿉니다.

다음과 같이 요청합니다. “에지 방화벽에서 10.0.0.0/8의 tcp/8443을 허용합니다”.
에이전트가 vyos-firewall 스킬을 불러오고, SSH로 현재 구성을 캡처합니다. show configuration commands는 날짜가 붙은 파일에 저장됩니다. 그리고 ops_plan로 계획을 엽니다. 단계는 하나이고, 효과는 add firewall rule, 되돌릴 수 있음은 reversible(규칙을 지우면 상태가 돌아옵니다), 영향 범위는 med입니다.
구성 모드에서 변경을 준비한 뒤 ops_diff로 장비 diff를 첨부합니다.
ops_approve가 계획 해시와 정확히 준비된 변경을 보여 줍니다. 승인하면 10분짜리 토큰이 발급됩니다.
ops_apply가 토큰을 사용하고 commit-confirm 순서를 실행합니다. 자동 롤백 타이머는 검증이 끝날 때까지 장전된 채로 남습니다.
ops_verify가 도달할 수 있는지, 그리고 규칙이 의도한 트래픽과 맞는지를 확인합니다. 승인과 결과가 모두 저널에 남으므로, 나중의 ops_journal 조회가 변경 전체를 다시 구성합니다.

5단계에서 적용이 실패하면 토큰은 사라집니다. 다시 시도하기 전에 4단계가 한 번 더 실행되어야 합니다.

승인 토큰의 의미

한 번만 사용 — ops_apply이 시작될 때 원자적으로 사용됩니다. 이미 쓰였거나 알 수 없거나 만료된 토큰은 아무것도 실행하지 않은 채 실패합니다.
TTL에 묶임 — 기본값은 10분이고 최대는 60분입니다. 만료는 사용할 때 그때그때 검사합니다. 뒤에서 도는 청소 프로세스는 없습니다.
계획에 묶임 — 토큰은 계획의 정규 sha256 해시에 대해 발급됩니다. 해시에는 정확한 적용 명령, 선택적인 스냅샷 명령, 작업 디렉터리가 들어 있습니다. 인자가 어긋나거나 다른 계획에 제시된 토큰은 사용되기 전에 거부됩니다. 그래서 재생, 계획 사이의 혼동, 명령 바꿔치기를 막습니다.
한 번만 드러남 — 원시 토큰은 ops_approve 결과에 정확히 한 번 나타나며 저장되지 않습니다. 저장되는 것은 sha256뿐입니다.
돌려주지 않음 — 실패하거나 시간이 초과된 적용은 토큰을 돌려주지 않습니다. 다시 시도하려면 ops_approve를 통해 다시 승인해야 합니다.

보안 모델

즉흥적인 변경의 게이트는 여전히 bash_destructive입니다. 운영 작업 흐름은 계획된 변경을 다룹니다. 한 번의 파괴적 명령은 여전히 파괴 분류기와 그 대화형 게이트에 걸리며, 어떤 권한 규칙도 그것을 자동으로 승인할 수 없습니다.
ops_approve는 대화형으로만 가능합니다. isolation_escalation, bash_destructive와 같이, 와일드카드 허용 규칙 아래에서도 헤드리스 자율 모드에서도 항상 묻습니다.
저널은 에이전트가 보기에는 추가만 가능하며 프로젝트 범위입니다. 세션보다 오래 남고, 세션을 지워도 함께 지워지지 않습니다.
스킬 팩에는 공급자 절차서가 들어 있습니다. cloud-ops-aws, cloud-ops-gcp, cloud-ops-cloudflare, cloud-ops-digitalocean, cloud-ops-runpod, vyos-firewall, junos-firewall가 읽기 우선 점검 목록, 변경 전의 계획 단계, 롤백 패턴을 담습니다. 에이전트는 어떤 표면을 다루기 전에 맞는 팩을 불러옵니다. OVHcloud와 그 밖의 공급자는 즉흥적인 CLI 연쇄가 아니라, 구성한 MCP 서버와 그 문서로 다룹니다.
자격 증명은 기록에 닿지 않습니다. 저장되는 bash 입력 안의 인라인 자격 증명 할당은 이벤트 로그에 도달하기 전에 가려집니다.

엄격 모드

기본적으로 파괴로 분류된 bash 명령(bash_destructive 계열, 즉 클라우드와 네트워크의 변경 동사, rm -rf, git push --force, 그리고 분류 목록의 나머지)은 우회할 수 없는 대화형 질문을 받습니다. 사용자는 그 한 번의 명령을 승인할 수 있고, 그러면 실행됩니다. 엄격 모드는 그 선택지를 없앱니다.

엄격 모드가 켜지면 파괴로 분류된 bash 명령은 묻기 전에 곧바로 거부됩니다. 거부 메시지는 분류된 명령과 그 이유를 나열하고, 허가된 작업 흐름으로 모델을 보냅니다. ops_plan → ops_diff → ops_approve(일회용 승인 토큰을 발급합니다) → ops_apply입니다. 즉흥적인 파괴적 셸 변경은 더 이상 전혀 불가능합니다. 모든 변경은 저널이 뒷받침하는 경로로 계획되고, diff되고, 승인되고, 적용되어야 합니다.

신뢰하는 구성에서 켭니다. 사용자 구성 디렉터리의 ax-code.json, 관리 구성, 또는 사용자가 명시적으로 신뢰한 프로젝트 구성입니다.

{
  "ops": {
    "strict": true
  }
}

참고:

질문과의 관계. 엄격 모드는 bash_destructive 질문을 단단한 거부로 바꿉니다. 플래그가 꺼져 있으면(기본값) 위의 설명과 정확히 같습니다. 대화형 게이트가 남습니다.
범위. 이 플래그는 에이전트별 설정이 아니라 전역 구성입니다. 서브에이전트를 포함하여 세션의 모든 bash 호출에 적용됩니다. cloudops 에이전트는 스스로 이를 켤 수 없습니다. 에이전트가 지니는 것은 권한과 프롬프트이며, 구성이 아닙니다.
신뢰의 범위. 신뢰되지 않고 저장소에 커밋된 프로젝트 구성은 엄격 모드를 켤 수 없습니다. 기계마다 AX_CODE_TRUST_PROJECT_CONFIG=1로 선택하거나, 신뢰하는 사용자 구성 또는 관리 구성에 설정합니다.
ops_apply는 영향을 받지 않습니다. 허가된 변경 경로는 도구 안에, 계획에 묶인 자체 토큰 게이트를 갖고 있으며 이 플래그를 보지 않습니다.

기준이 되는 원천

packages/ax-code/src/agent/agent.ts — cloudops 에이전트 정의와 권한 병합
packages/ax-code/src/agent/prompt/cloudops.txt — 에이전트 시스템 프롬프트
packages/ax-code/src/tool/ops_*.ts — 여섯 개의 운영 도구와 그 설명
packages/ax-code/src/permission/index.ts — INTERACTIVE_ONLY(ops_approve, bash_destructive, isolation_escalation)
샌드박스 모드 — 격리 모드, 네트워크 제어, 우선순위