Agentic AI 운영에서 권한 설계가 중요한 이유

AI Agent에게 운영 권한을 줄 때 먼저 나눠야 할 경계

오늘의 관점
Agentic AI의 위험은 "AI가 틀릴 수 있다"에서 끝나지 않는다. 실제 운영 환경에서는 틀린 판단보다 더 위험한 것이, 그 판단이 곧바로 변경 권한과 연결되는 구조다.

요약

Agentic AI는 단순 챗봇과 다르게 도구를 호출하고, 시스템을 조회하고, 경우에 따라 실제 변경 작업까지 수행할 수 있다. 그래서 운영 환경에 AI Agent를 붙일 때는 모델 성능보다 먼저 권한 경계, 승인 흐름, 감사 로그를 설계해야 한다.

이 글에서는 인프라와 DevOps 담당자가 Agentic AI를 운영 자동화에 적용하기 전에 확인해야 할 권한 설계 원칙을 정리한다. AWS와 Azure 관점에서는 Agent가 어떤 도구를 호출할 수 있는지, 어떤 작업에서 사람 승인을 받아야 하는지, 실행 기록에 무엇을 남겨야 하는지를 중심으로 살펴본다.

이런 분께 도움이 됩니다

이 글은 AI Agent를 장애 대응, Runbook 자동화, 티켓 정리, 클라우드 운영 보조 도구로 검토하는 인프라 엔지니어, DevOps 담당자, 플랫폼 엔지니어를 위한 글이다.

특히 LLM 자체보다 운영 권한, IAM, 승인 워크플로우, 감사 가능성이 더 걱정되는 실무자에게 도움이 된다.

왜 지금 권한 설계가 중요한가

기존 자동화는 대체로 사람이 명시적으로 실행하는 스크립트나 파이프라인이었다. Terraform pipeline, Jenkins job, GitHub Actions workflow, AWS Systems Manager Automation runbook처럼 실행 경로가 비교적 고정된 방식이 많았다.

반면 Agentic AI는 사용자의 요청, 대화 맥락, 관측 데이터, 도구 설명을 바탕으로 어떤 도구를 호출할지 스스로 선택할 수 있다. 같은 "장애 확인해줘"라는 요청이라도 Agent는 로그 조회만 할 수도 있고, Pod 재시작이나 배포 롤백을 제안할 수도 있다.

이 차이가 권한 설계를 어렵게 만든다. 만약 모든 도구가 하나의 넓은 권한으로 묶여 있다면 운영자는 Agent가 어떤 경계 안에서 움직이는지 설명하기 어렵다.

최근 Agentic AI 보안 논의에서 비인간 ID, 단기 권한, Zero Standing Privilege, 승인 기반 실행이 자주 언급되는 이유도 여기에 있다. AI Agent는 사람 계정의 부가 기능이 아니라, 운영 시스템 안에서 별도 생명주기와 감사 대상이 필요한 실행 주체가 되고 있다.

1. Agentic AI 권한은 왜 기존 자동화보다 까다로운가

1.1 기존 자동화는 실행 경로가 예측 가능하다

기존 자동화는 위험할 수는 있어도 무엇을 실행하는지 비교적 명확하다. 예를 들어 restart-api-pods라는 Job은 특정 네임스페이스의 Deployment를 재시작한다. 해당 Job에 어떤 권한이 필요한지, 어떤 리소스가 영향을 받는지도 사전에 정의할 수 있다.

Agentic AI는 다르다. Agent는 먼저 상황을 해석하고, 필요한 도구를 고르고, 도구 호출 결과를 다시 해석한 뒤 다음 행동을 결정한다. 이 흐름에서는 "어떤 도구가 연결되어 있는가"와 "그 도구가 어떤 권한으로 실행되는가"가 곧 운영 리스크가 된다.

예를 들어 장애 대응 Agent에 다음 도구가 모두 연결되어 있다고 가정해보자.

• 로그와 메트릭 조회
• 최근 배포 이력 확인
• Kubernetes Pod 상태 확인
• 배포 롤백 실행
• 티켓 생성
• Slack 상황 공유
• IAM 정책 조회 또는 변경

이 중 로그 조회와 티켓 생성은 비교적 낮은 위험 작업이다. 하지만 배포 롤백, Pod 재시작, IAM 정책 변경은 운영 영향이 크다. Agent가 이 도구들을 같은 권한 경계 안에서 사용할 수 있다면, 자동화 편의성이 곧 장애 확산 리스크가 될 수 있다.

1.2 Agent는 사용자와 시스템 사이의 권한 중개자가 된다

운영 Agent가 실무에 들어오는 순간 핵심 질문은 다음 세 가지로 정리된다.

• 이 Agent는 무엇을 볼 수 있는가?
• 이 Agent는 무엇을 제안할 수 있는가?
• 이 Agent는 무엇을 직접 실행할 수 있는가?

이 세 가지를 나누지 않으면 "AI가 편하다"는 이유로 운영 변경 권한이 지나치게 넓어질 수 있다. 특히 운영자는 Agent가 내린 결론만 보는 것이 아니라, Agent가 어떤 권한으로 어떤 시스템에 접근했는지까지 설명할 수 있어야 한다.

2. 운영 Agent 권한 설계의 5가지 원칙

2.1 Agent를 별도 ID로 취급한다

Agent를 사람 계정 뒤에 숨기면 감사가 어려워진다. 운영자가 Slack에서 요청했고, Agent가 Kubernetes API를 호출했으며, 실제 변경은 특정 Role로 실행되었다면 이 세 층이 로그에서 구분되어야 한다.

권장되는 기록 단위는 다음과 같다.

구분	기록해야 할 내용
요청자	어떤 사용자가 어떤 요청을 했는가
Agent	어떤 Agent 버전과 정책으로 실행되었는가
도구	어떤 tool, API, runbook이 호출되었는가
권한	어떤 Role, Service Principal, Managed Identity가 사용되었는가
결과	실행 결과, 실패 원인, 검증 지표는 무엇인가

Agent를 별도 ID로 관리하면 문제가 생겼을 때 "누가 실행했는가"에서 멈추지 않고 "어떤 Agent가 어떤 정책으로 판단했는가"까지 추적할 수 있다.

2.2 읽기 권한과 변경 권한을 분리한다

Agentic AI 도입 초기에 가장 현실적인 영역은 변경 자동화가 아니라 조회 자동화다.

운영자는 장애 초기에 로그, 메트릭, 이벤트, 배포 이력, 관련 티켓을 빠르게 모으는 데 많은 시간을 쓴다. 이 작업은 Agent가 잘 도울 수 있다. 반면 재시작, 롤백, 스케일 조정, 보안 그룹 수정은 영향 범위가 크기 때문에 별도 승인이 필요하다.

권한은 최소한 다음처럼 나누는 것이 좋다.

InvestigationAgentRole
  - 로그 조회
  - 메트릭 조회
  - 이벤트 조회
  - 배포 이력 조회
  - 티켓 및 Runbook 조회

DiagnosticAutomationRole
  - 읽기 중심 진단 runbook 실행
  - 임시 진단 명령 실행
  - 운영 리소스 변경 금지

ApprovedChangeRole
  - 롤백, 재시작, 스케일 조정 같은 변경 작업
  - 승인 워크플로우 이후에만 사용
  - 환경, 서비스, 시간, 요청자 조건으로 제한

이렇게 나누면 Agent가 "무엇을 할 수 있는지"가 기술적으로 제한된다. 프롬프트에 "주의해서 실행해"라고 쓰는 것보다 IAM, RBAC, 네트워크, 승인 정책으로 막는 편이 훨씬 안정적이다.

2.3 고위험 도구에는 사람 승인을 둔다

모든 tool call에 승인을 요구하면 Agent가 느려지고 운영자가 다시 병목이 된다. 반대로 모든 tool call을 자동 승인하면 자동화 리스크가 커진다. 따라서 도구를 위험도별로 나눠야 한다.

위험도	예시	권장 처리
낮음	로그 조회, 메트릭 조회, Runbook 검색	자동 실행 가능
중간	진단 스크립트 실행, 티켓 생성, Slack 요약 게시	조건부 자동 실행 또는 사후 검토
높음	배포 롤백, Pod 재시작, 인스턴스 중지, 권한 변경	사전 승인 필요
매우 높음	IAM 관리자 권한 부여, 네트워크 차단 해제, 데이터 삭제	기본 차단, 예외 절차 필요

AWS Bedrock Agents는 action group의 특정 action에 사용자 확인을 요구하는 구성을 제공한다. OpenAI Agents SDK도 tool call을 중단하고 승인 또는 거절 후 같은 실행 상태에서 재개하는 human-in-the-loop 패턴을 제공한다. Azure Foundry Agent Service에서도 MCP tool 같은 외부 도구 연결 시 승인 설정과 인증 방식을 함께 고려할 수 있다.

중요한 점은 기능 이름이 아니라 설계 방향이다. Agent가 위험한 도구를 호출하려 할 때 실행을 멈추고, 근거와 예상 영향을 사람에게 보여준 뒤, 승인 결과를 감사 로그에 남겨야 한다.

2.4 장기 권한보다 단기 권한을 선호한다

Agent가 장시간 살아 있는 넓은 권한을 들고 있으면 사고 범위가 커진다. 특히 운영 Agent는 여러 사용자의 요청을 처리하거나, 여러 서비스에 접근하거나, 여러 도구를 조합할 수 있다.

가능하면 다음 원칙을 적용한다.

• 장기 access key를 Agent 런타임에 저장하지 않는다.
• cloud native identity를 우선 사용한다.
• 작업 단위로 짧은 세션 권한을 발급한다.
• 프로덕션 변경 권한은 승인 이후 제한된 시간 동안만 허용한다.
• Agent 버전, 실행 환경, 요청자, 대상 리소스를 조건으로 권한을 제한한다.

AWS라면 IAM Role, STS 기반 임시 자격 증명, IAM condition, CloudTrail 기록을 함께 봐야 한다. Azure라면 Managed Identity, Microsoft Entra ID, RBAC, Azure Activity Log, resource scope 설계를 함께 봐야 한다.

2.5 감사 로그는 결과가 아니라 판단 과정까지 남겨야 한다

기존 운영 로그는 주로 API 호출 결과를 남긴다. 하지만 Agentic AI 운영에서는 결과만으로 부족하다.

예를 들어 Agent가 롤백을 제안했다면 다음 정보가 필요하다.

• 어떤 알람 또는 요청에서 시작되었는가
• 어떤 로그와 메트릭을 근거로 삼았는가
• 어떤 Runbook을 참조했는가
• 어떤 tool call 후보가 있었는가
• 어떤 정책 때문에 승인 요청이 발생했는가
• 누가 승인 또는 거절했는가
• 실행 후 어떤 지표로 정상화를 확인했는가

OpenAI Agents SDK의 tracing 문서는 agent 실행, model generation, function tool call, guardrail, handoff 같은 단위를 추적 대상으로 설명한다. 이런 형태의 trace는 개발 중 디버깅뿐 아니라 운영 감사와 재발 방지에도 중요하다.

3. AWS 관점: Bedrock Agent와 IAM 경계를 함께 봐야 한다

AWS에서 Agentic AI를 운영 자동화에 붙일 때는 Amazon Bedrock Agents 같은 Agent 런타임만 보면 부족하다. 실제 리스크는 Agent가 호출하는 Lambda, API, Systems Manager Automation, CloudWatch, Kubernetes API, 사내 API의 권한에서 발생한다.

실무적으로는 다음 구조가 필요하다.

사용자 요청
  -> Bedrock Agent 또는 자체 Agent Runtime
  -> Action Group 또는 Tool 선택
  -> 정책 평가
  -> 읽기 작업은 제한 Role로 실행
  -> 변경 작업은 사용자 확인 후 별도 Role로 실행
  -> CloudTrail, 애플리케이션 로그, Agent trace에 기록

Bedrock Agents의 사용자 확인 기능은 prompt injection이나 의도하지 않은 action 호출을 줄이기 위해 특정 action 실행 전 명시적 확인을 받는 흐름을 제공한다. 이 기능만으로 모든 권한 문제가 해결되지는 않지만, 운영 변경 작업을 승인 경계 뒤로 분리하는 설계에는 중요한 힌트가 된다.

AWS 환경에서 먼저 점검할 항목은 다음과 같다.

• Agent runtime이 어떤 IAM Role로 실행되는가
• Action Group이 호출하는 Lambda 또는 API의 권한이 분리되어 있는가
• CloudWatch Logs, CloudTrail, Systems Manager 기록이 Agent 실행 기록과 연결되는가
• 프로덕션 변경 action에 사용자 확인 또는 별도 승인 절차가 있는가
• 실패했을 때 Agent가 재시도할 수 있는 범위가 제한되어 있는가

4. Azure 관점: Foundry Agent 도구와 Entra ID 경계를 함께 봐야 한다

Azure에서는 Microsoft Foundry Agent Service의 tool catalog, MCP tool, OpenAPI tool, Azure Functions, Logic Apps 같은 연결 지점이 운영 권한의 핵심이 된다. Agent가 외부 API나 사내 시스템에 접근한다면 인증 방식, credential 저장 위치, 승인 필요 여부, tool별 scope를 확인해야 한다.

Microsoft 문서는 Foundry Agent Service의 도구가 웹 검색, 코드 실행, 파일 검색, 함수 호출, MCP, OpenAPI 같은 방식으로 Agent 기능을 확장한다고 설명한다. 또한 MCP server 인증에는 key 기반 인증, Microsoft Entra 인증, OAuth 사용자 위임 같은 방식이 사용될 수 있다.

Azure 운영 환경에서는 다음 질문이 중요하다.

• Agent가 project managed identity로 실행되는가, 사용자 위임으로 실행되는가
• tool credential이 prompt나 로그에 노출될 가능성은 없는가
• 프로덕션 리소스 scope가 subscription 전체로 열려 있지는 않은가
• 승인 필요한 tool과 자동 실행 가능한 tool이 분리되어 있는가
• Activity Log, Application Insights, Agent trace가 서로 연결되는가

AWS와 Azure의 구체 서비스는 다르지만 결론은 같다. Agent에게 권한을 주는 순간, Agent는 운영 시스템의 새로운 identity가 된다.

5. 실무 체크리스트

• Agent를 사람 계정의 부가 기능이 아니라 별도 실행 주체로 등록한다.
• 읽기 전용 조사 권한과 변경 실행 권한을 분리한다.
• tool별 위험도를 정하고 승인 필요 여부를 명시한다.
• 프로덕션 변경은 승인 전에는 실행 권한 자체가 없도록 만든다.
• Agent 실행 로그에 요청자, Agent 버전, tool call, 권한, 승인자, 결과를 남긴다.
• 장기 credential을 Agent 런타임이나 prompt에 넣지 않는다.
• 처음에는 장애 조치 자동화보다 조사 자동화부터 적용한다.
• Agent가 접근할 수 있는 Runbook과 API 문서를 주기적으로 검토한다.

6. 흔한 실수

• Agent에게 관리자 권한을 먼저 주는 것: PoC에서는 편하지만 운영 전환 시 가장 먼저 문제가 된다. PoC 단계에서도 읽기, 진단, 변경 권한을 나눠두는 편이 좋다.
• 프롬프트로 권한 통제를 대신하는 것: "삭제하지 마", "운영 변경은 조심해" 같은 문장은 보조 장치일 뿐이다. 실제 통제는 IAM, RBAC, 승인 워크플로우, 네트워크 경계에서 해야 한다.
• 승인 화면에 근거를 넣지 않는 것: 승인자는 Agent의 결론만 보고 승인하면 안 된다. 어떤 지표, 로그, Runbook 때문에 해당 조치를 제안했는지 함께 봐야 한다.
• 감사 로그를 API 호출 결과로만 남기는 것: Agent 운영에서는 판단 과정, tool 후보, 승인 상태, 거절 사유까지 남겨야 나중에 설명할 수 있다.
• 모든 작업에 사람 승인을 요구하는 것: 조회 작업까지 매번 승인하면 운영자는 곧 우회 경로를 찾게 된다. 낮은 위험 작업은 자동화하고, 높은 위험 작업만 명확히 멈추는 구조가 더 현실적이다.

마무리

Agentic AI를 운영에 붙이는 일은 모델을 잘 고르는 문제만이 아니다. 실제로는 Agent가 어떤 권한으로 어떤 시스템을 건드릴 수 있는지, 어떤 순간에 멈춰야 하는지, 나중에 누가 설명할 수 있는지를 설계하는 문제다.

처음부터 완전 자동 복구를 목표로 잡기보다, 읽기 전용 조사 자동화와 승인 기반 변경 실행을 분리해서 시작하는 편이 현실적이다. 운영자가 믿을 수 있는 Agent는 똑똑한 Agent가 아니라, 경계가 분명하고 기록이 남는 Agent다.

참고자료

• Agentic Identity and Access Management - Coalition for Secure AI
• Get user confirmation before invoking action group function - Amazon Bedrock
• Agent tools overview for Foundry Agent Service - Microsoft Learn
• Human-in-the-loop - OpenAI Agents SDK
• Tracing - OpenAI Agents SDK