AI agent는 planning과 실행을 분리하고, 자격 증명 범위를 제한하고, 결과가 큰 작업에 승인을 요구하고, 쓰기를 안전하게 조정하고, 모든 영향을 추적하고, 복구를 테스트할 때 MCP를 통해 cloud 인프라를 관리할 수 있습니다. 도구 검색만으로는 이런 제어가 하나도 생기지 않습니다.
가장 안전한 첫 기능은 읽기 전용 inventory입니다. 일회용 환경에서 plan 및 policy 경로가 제대로 동작한 뒤에만 변경 기능을 추가하세요.
plan과 apply를 분리하세요
plan에는 정확한 tenant, environment, 리소스, 의존성, 권한 변경, 비용, 되돌릴 수 없는 영향을 명시해야 합니다. 이 plan을 적용하려면 별도의 도구나 plan digest에 묶인 approval token을 요구해야 합니다.
모델이 payload를 만든 뒤 일반 도구 하나에 dryRun: false를 넘겨 실행하게 하지 마세요. apply 기능을 분리하면 client와 policy 계층에서 전환이 분명하게 드러납니다.
Infrastructure-as-code 도구는 이미 이 검토 방식을 사용합니다. MCP에서도 planning과 실행을 한 번의 model turn으로 압축하지 말고 이 경계를 유지해야 합니다.
모든 계층에서 신원 범위를 제한하세요
MCP server는 client와 그 client가 대신하는 사용자를 인증합니다. policy는 표시하거나 호출할 수 있는 인프라 도구를 제한합니다. provider 자격 증명은 대상 account, project, environment, 작업으로 범위가 제한됩니다. 이어서 provider가 최종 리소스 권한을 확인합니다.
Cloudflare의 MCP 권한 부여 아키텍처는 identity와 authorization을 agent session state에서 분리합니다. MCP 인증 가이드는 token audience와 passthrough에 관한 최신 protocol 요구 사항을 적용합니다.
개발 도구를 organization-owner token으로 실행하지 마세요. provider가 필요한 범위를 표현할 수 없다면 앞에 범위가 좁은 control plane을 두세요.
모든 쓰기 작업을 operation으로 취급하세요
승인된 변경에 operation ID와 idempotency key를 하나씩 지정하세요. plan digest, caller, 대상 리소스, 시도 기록, provider request ID, 상태, 결과를 저장합니다. 재시도는 같은 operation을 참조해야 합니다.
timeout이 발생하면 호출을 반복하기 전에 provider 상태와 operation 상태를 확인하세요. provider가 작업을 완료했지만 client가 응답을 받지 못했을 때 결과를 알 수 없는 상황이 자주 발생합니다.
agent 복구 가이드는 인프라 외부의 checkpoint와 결과 조정을 다룹니다.
결과가 발생하기 전에 승인을 요구하세요
승인 화면에는 다음 정보가 있어야 합니다.
- 정확한 environment 및 account
- 생성, 변경, 제거되는 각 리소스
- 새로운 권한 및 network 노출
- 예상 비용 및 billing 영향
- data loss 또는 downtime 위험
- 작업을 되돌릴 수 있는지 여부
- 승인 만료 시점
OAuth 동의가 이후의 production 삭제까지 승인하는 것은 아닙니다. OAuth 동의는 특정 범주의 접근을 허용합니다. 영향이 큰 작업에는 여전히 현재 시점의 policy 결정이 필요합니다.
되돌릴 수 있는 작업을 우선하세요
provider가 지원한다면 soft deletion, snapshot, staged traffic, 이전 설정 유지를 사용하세요. Railway의 2026년 4월 incident report는 agent가 광범위한 token을 찾아 즉시 삭제하는 기존 경로를 호출한 사례를 설명합니다. Railway는 volume을 복구하고 API 삭제를 48시간 soft-delete 방식으로 바꿨습니다.
이 사례에서 자격 증명 범위와 삭제 semantics 모두 영향 범위를 제한하지 못했습니다. audit log만 있었다면 나중에 삭제 경위를 설명할 수 있을 뿐입니다.
인프라 출력 범위를 제한하세요
provider payload 전체 대신 안정적인 공개 결과를 반환하세요.
{
"operationId": "op_1842",
"state": "pending",
"resources": ["database:db_73"],
"statusUrl": "/operations/op_1842",
"retryAfterSeconds": 15
}
다음의 권한 있는 단계에 꼭 필요하지 않다면 provider 자격 증명, account 전체에서 쓰는 identifier, 내부 network detail, debug header를 제거하세요.
제어 경로를 추적하고 알림을 설정하세요
user, agent, session, plan digest, approval, tool call, operation ID, target, provider request, policy decision, 상태 전환, 최종 영향을 기록하세요. 다음 상황에는 알림을 보내세요.
- 개발 신원에서 production 대상을 호출
- 새로운 광범위 권한
- 반복되는 삭제 또는 생성 시도
- 승인 우회 또는 만료
- 비용이 높은 리소스 분류
- 알 수 없는 상태에 멈춘 operation
production agent checklist는 이 필드를 release gate로 바꿔 줍니다.
통제된 실패를 테스트하세요
일회용 project에서 provider가 요청을 받았을 가능성이 있는 시점에 apply 호출을 중단하세요. workflow를 재개한 뒤 첫 operation을 조정하는지 확인합니다. 이어서 실행 도중 agent 자격 증명을 취소하고 이후 작업이 멈추는지 확인하세요.
development용으로 생성한 plan을 production에 적용할 수 없는지, 계획된 리소스를 하나라도 수정하면 승인이 무효화되는지도 테스트하세요.
plan 전용 도구부터 시작하세요
apply를 사용할 수 없게 둔 상태에서 inventory와 planning을 제공하세요. agent가 실제 작업의 plan을 만들게 하고 operator에게 여전히 필요한 정보가 무엇인지 검토합니다. approval, retry, trace, recovery 테스트를 통과한 뒤에만 범위가 좁은 apply 도구 하나를 추가하세요.
아래 프롬프트는 이 project에서 영향이 가장 큰 도구를 대상으로 plan 전용 검토를 실행합니다.