저는 이전에 에이전틱 AI (Agentic AI)가 클릭옵스 (ClickOps)를 다시 도입하고 있다고 주장했으며, 여전히 그 의견을 유지하고 있습니다. 하지만 그 글에서 제가 더 이상 믿지 않게 된 두 번째 주장이 하나 있었습니다. 바로 에이전트가 설계 시점에 어떤 행동을 취할지 예측할 수 없기 때문에, 최소 권한 설계 (least-privilege design)가 인간보다 에이전트에게 더 어렵다는 주장이었습니다.

그 말은 어느 정도 사실입니다. 하지만 그것은 에이전트에 관한 사실이 아닙니다. 그것은 우리가 권한을 부여하는 방식에 관한 사실이며, 이미 우리가 권한을 부여했던 인간들에게도 해당되는 사실이었습니다.

에이전틱 DevOps에 대해 제가 듣는 대부분의 보안 우려 사항들은 진지하게 받아들일 가치가 있습니다. 하지만 그중 새로운 것은 거의 없습니다. 세 가지가 가장 많이 언급되는데, 에이전트가 자신의 작업을 초과하여 자격 증명 (credentials)을 파괴적으로 사용할 것이라는 점, 에이전트가 수행하는 작업을 승인하도록 강제하는 인간이 없다는 점, 그리고 액세스 범위를 축소하면 에이전트가 진정으로 더 많은 권한을 필요로 하는 사례가 깨진다는 점입니다. 이 각각의 사례는 기존의 ID 및 액세스 관리 (IAM) 실패 사례들이며, 이제 에이전트들이 이를 눈에 보일 만큼 빠른 속도로 실행하고 있을 뿐입니다.

부여된 권한과 실행된 권한 사이의 간극

최소 권한 (Least privilege)은 최근에 나온 조언이 아닙니다. Saltzer와 Schroeder는 1975년 The Protection of Information in Computer Systems에서 다음과 같이 기록했습니다: "모든 프로그램과 시스템의 모든 사용자는 작업을 완료하는 데 필요한 최소한의 권한 세트를 사용하여 작동해야 합니다." 50년 동안이나 당연한 사실이었습니다.

Microsoft의 권한 텔레메트리 (telemetry)는 상황이 어떻게 흘러갔는지를 보여줍니다. Microsoft의 2024년 멀티클라우드 리스크 상태 보고서에 따르면, 2023년에 인간 및 워크로드 ID 권한 중 단 2%만이 사용되었으며, 클라우드 ID의 50% 이상이 모든 권한과 모든 리소스에 접근할 수 있었습니다.

이 두 숫자를 함께 읽어보십시오. 조직들은 거의 전체에 가까운 액세스 권한을 부여한 다음, 그중 약 50분의 1만을 사용하고 있습니다.

사용되지 않는 98%는 결코 안전하지 않았습니다. 그것은 단지 실행되지 않았을 뿐입니다. 권한을 보유한 주체가 사람이었을 때는 그 차이가 그리 중요하지 않았습니다. 왜냐하면 사람은 인간의 속도로 움직이고, 파괴적인 명령 앞에서는 주저하며, 대부분 주어진 런북 (Runbook) 안에서 머물기 때문입니다. 권한은 광범위하게 부여되었으나 좁게 사용되었고, 그 차이는 습관에 의해 가려져 있었습니다.

에이전트 (Agent)에게는 습관이 없습니다. 에이전트에게 AdministratorAccess와 작업(Task)을 부여하면, 에이전트의 행동 범위 (Action space)는 런북이 아니라 부여된 권한 그 자체가 됩니다.

이것이 메커니즘의 전부입니다. 에이전트가 누군가의 권한을 확장한 것이 아닙니다. 에이전트는 부여된 권한과 실제로 사용되는 권한 사이의 간극을 메웠을 뿐입니다. "에이전트가 내가 요청한 것보다 더 많은 일을 할 수도 있다"는 모든 우려는 기존의 우려를 재진술하는 것에 불과합니다. 즉, 이 주체는 언제든 내가 요청한 것보다 더 많은 일을 할 수 있었다는 것입니다.

애초에 이것은 인간 주체 (Human-identity)의 문제도 아니었습니다. 동일한 보고서에 따르면 워크로드 주체 (Workload identities)가 모든 클라우드 주체의 83%를 차지하며, 평균적인 조직은 워크로드 주체 7개당 3개의 인간 슈퍼 주체 (Human super identities)를 보유하고 있습니다. 제한 없는 액세스 권한을 가진 비인간 주체 (Non-human principals)는 누군가 언어 모델 (Language model)을 클라우드 API에 연결하기 전부터 이미 다수였습니다.

이 간극이 지속된 이유는 최소 권한 (Least privilege) 원칙이 액세스를 부여하는 이가 마찰이라는 형태로 미리 지불해야 하는 세금과 같고, 그 대가는 발생하지 않은 사고이기 때문입니다. 분기 실적이 출시된 기능 (Shipped features)으로 측정되는 누구에게나 이는 나쁜 거래입니다. 그래서 아무도 그 권한을 모두 사용하지 않을 것이라는 가정하에 액세스는 광범위하게 부여되었습니다. 그 비용을 강제하는 것은 아무것도 없었습니다.

"인간 참여 (Human in the loop)"는 인증 요구사항입니다

에이전틱 파이프라인 (Agentic pipelines)에 대해 제가 듣는 가장 흔한 요구사항은 이것입니다: 에이전트가 파괴적인 작업을 수행하기 전에 사람이 승인해야 한다는 것입니다.

그것은 **단계별 인증 (Step-up authentication)**입니다. 이는 이미 수년 전부터 정의되었고 구현되어 온 방식입니다.

NIST SP 800-63B는 모든 인증된 세션이 명확한 재인증 타임아웃 (reauthentication timeout)을 가져야 한다고 요구하며, AAL2 단계에서는 24시간을 넘지 않을 것과 1시간의 비활성 타임아웃 (inactivity timeout)을 권장합니다. 이 표준은 이미 세션의 인증 효력이 저하되며, 현장에 있는 인간에 의해 갱신되어야 함을 전제로 하고 있습니다.

클라우드 IAM은 이러한 강제 실행을 위한 기본 요소 (enforcement primitive)를 제공합니다. AWS는 aws:MultiFactorAuthPresent와 aws:MultiFactorAuthAge를 전역 조건 키 (global condition keys)로 노출하며, AWS 자체 문서에서도 다음과 같은 예시를 보여줍니다: 모든 EC2 작업을 허용하되, MFA가 없는 경우 StopInstances 및 TerminateInstances를 거부 (deny)하는 방식입니다. 에이전트가 맡게 될 역할 (role)의 정책에 이와 같은 구문을 추가하면, 인간이 지난 5분 이내에 MFA를 완료하지 않는 한 파괴적인 호출 (destructive calls)은 실패하게 됩니다:

{
  "Sid": "RequireRecentMFAForDestructiveActions",
  "Effect": "Deny",
...

여기서 IfExists 접미사가 핵심적인 역할을 수행합니다. 장기 자격 증명 (long-term credentials)을 통해 요청이 도착할 때 aws:MultiFactorAuthAge는 완전히 존재하지 않으며, NumericGreaterThanIfExists는 존재하지 않는 키를 일치하는 것으로 처리합니다. 따라서 이 구문은 MFA가 오래되었을 때와 MFA가 아예 없을 때 모두 거부(deny)를 수행하며, 이는 사용자가 원하는 동작입니다. 단순히 NumericGreaterThan 버전을 사용할 경우 조용히 허용(fail open)되어 버리는 이유이기도 합니다. AWS는 자체 예시 정책에서 BoolIfExists에 대해서도 동일한 함정을 문서화하고 있는데, 이는 이러한 보안 게이트를 작성할 때 얼마나 쉽게 반대로 구현할 수 있는지를 잘 보여주는 지표입니다.

특정 정책 자체가 핵심은 아닙니다. 핵심은 "어떠한 에이전트도 인간이 지난 5분 이내에 인증하지 않는 한 프로덕션 데이터를 삭제할 수 없다"라는 규칙이 이미 프로덕션에서 실행 중인 액세스 제어 언어로 표현 가능하다는 점입니다. 그것은 하나의 조건 키 (condition key)일 뿐입니다. 여기서 누락된 기술은 없습니다. 단지 아무도 작성하지 않은 정책이 있을 뿐입니다.

세션 승인은 작업 승인이 아니다

이 지점이 바로 우려가 실질적인 근거를 갖는 부분이며, 저 스스로도 앞서 했던 안심시키기에 반론을 제기하고 싶은 대목입니다.

세션 시작 시의 MFA (다요소 인증)는 인간을 인증합니다. 하지만 특정 동작을 승인(authorize)하지는 않습니다. 일단 에이전트가 MFA 하에 발행된 세션 자격 증명(session credential)을 보유하게 되면, 에이전트는 귀하의 동의를 대신하는 베어러 토큰(bearer token)을 갖게 됩니다. 위에서 언급한 조건하에서는 5분 동안, 또는 AAL2 상한선 하에서는 최대 24시간 동안 유효합니다. 해당 시간 범위 내에서 에이전트가 수행하는 모든 작업은 귀하의 인증을 수반합니다. 이는 루프(loop) 안에 인간이 있는 것이 아니라, 루프의 시작점에만 인간이 있는 것입니다.

이 문제 역시 해결책이 있습니다. 다만 우리 산업군이 아닌 다른 곳에서 찾았습니다. 유럽의 결제 규제에서도 동일한 문제에 직면했습니다. 고객이 은행에 인증을 하면 거래가 실행되는데, 두 번째 단계(거래)를 첫 번째 단계(인증)와 결합할 무언가가 필요했습니다. Commission Delegated Regulation (EU) 2018/389 제5조는 이를 **동적 연결 (dynamic linking)**로 해결합니다. 인증 코드는 금액과 수취인에 대해 구체적이어야 하며, 둘 중 하나라도 변경되면 해당 코드는 무효가 됩니다. 이 산업에서는 이 원칙을

맞습니다. 그리고 이것은 세 가지 문제 중 가장 오래전에 해결된 문제입니다. sudo는 1980년경 Bob Coggeshall과 Cliff Spencer가 4.1BSD가 실행되는 VAX-11/750에서 작성했으며, 그 설계 (design)가 바로 전체적인 해답입니다. 당신은 root 권한을 보유하는 것이 아니라, root 권한을 가질 자격(eligible)을 갖는 것입니다. 단 하나의 명령어를 위해 권한을 상승(elevate)시킵니다. 이 권한 상승은 시간 제한(time-boxed)이 있으며, 해당 창(window)이 만료되면 다시 인증해야 합니다. 현재의 sudoers는 해당 창을 timestamp_timeout으로 노출합니다.

우리는 그 모델을 가져와 클라우드 인프라로 옮겼지만, 정작 그 모델은 뒤에 남겨두었습니다. 그에 상응하는 것들이 존재하기는 합니다. Microsoft Entra Privileged Identity Management는 자격이 있는 역할 할당(eligible role assignments)과 활성화된 역할 할당(active ones)을 구분합니다. AWS는 직접 배포할 수 있는 IAM Identity Center를 위한 일시적 권한 상승 솔루션 (temporary elevated access solution for IAM Identity Center)을 공개했습니다. Vault는 TTL이 포함된 동적 자격 증명 (dynamic credentials with a TTL)을 발급하고 만료 시 이를 취소합니다. 하지만 이 중 무엇을 배포하더라도 여전히 예외적인 상황에 불과합니다.

"에이전트가 가끔 더 넓은 권한이 필요할 수도 있다"라는 주장은 자격(eligibility)에 대한 근거이지, 상시 부여(standing grant)에 대한 근거가 아닙니다. 권한 상승을 요청하고, 단 하나의 작업 동안만 유지하며, 자동으로 권한을 상실하는 에이전트는 그 작업으로 인해 발생하는 폭발 반경(blast radius)이 해당 작업 내로 제한됩니다. 이것은 에이전트 제어(agent control)가 아닙니다. 어차피 영구적으로 부여하려 했던 액세스에 sudo를 적용한 것뿐입니다.

실제로 새로운 것은 무엇인가

이러한 우려 사항 중 두 가지는 미완성된 IAM 작업으로 귀결되지 않습니다.

첫 번째는 프롬프트 인젝션 (Prompt Injection)이며, 왜 다요소 인증 (MFA)과 최소 권한 (Least Privilege) 원칙이 이 문제에 영향을 미치지 못하는지 정확히 짚고 넘어갈 가치가 있습니다. 인젝션 공격 시 에이전트는 올바르게 인증 (Authenticated)되고 올바르게 권한 부여 (Authorized)된 상태입니다. 에이전트는 제3자가 유도한 동작을 수행하기 위해 자신의 정당한 권한을 사용합니다. 액세스 제어 (Access Control)는 이 주체 (Principal)가 이 동작을 수행할 수 있는지 묻고, 올바르게 '예'라고 답하지만, 공격은 어쨌든 성공합니다.

이러한 실패에는 우리가 이에 맞서 사용할 대부분의 도구보다 더 오래된 이름이 있습니다. Norm Hardy는 1988년에 혼동된 대리인 (Confused Deputy) 현상을 설명했습니다. 이는 권한이 없는 호출자를 대신하여 권한을 오용하도록 속아 넘어간 권한 있는 프로그램(Privileged Program)을 의미합니다. 새로운 점은 공격 표면 (Surface)입니다. 컴파일러는 파일 이름에 대해 혼동을 일으킬 수 있습니다. 로그, 티켓, 풀 리퀘스트 (Pull Request) 설명을 읽는 에이전트는 자신의 컨텍스트 윈도우 (Context Window)에 도달하는 무엇에 대해서든 혼동을 일으킬 수 있습니다.

알려진 완화 방법은 신원 (Identity)과 함께 이동하는 권한이 아니라, 요청 (Request)과 함께 이동하는 권한을 사용하는 것입니다. 즉, 에이전트가 보유하며 무엇이든 가리킬 수 있는 역할 (Role)이 아니라, 매개변수가 이미 고정된 상태로 단 한 번의 호출만을 승인하는 일회용 토큰 (Single-use Token)을 사용하는 것입니다. 이것은 반대 방향에서 찾아온, 다시 등장한 동적 연결 (Dynamic Linking)입니다. 권한 기반 시스템 (Capability-based systems)은 수십 년 동안 이를 모델링해 왔지만, 실제 운영 중인 클라우드 IAM 중 이 방식으로 작동하는 것은 거의 없습니다.

두 번째는 귀속 (Attribution) 문제입니다. 에이전트가 변경 사항을 만들 때, 변경 관리 프레임워크 (Change Management Frameworks)는 한 명의 인간 행위자와 하나의 승인 의도를 요구합니다. 만약 인간이 에이전트에게 프롬프트를 입력했다면, 그 프롬프트가 승인일까요? 만약 에이전트가 지표 (Metric)를 스스로 읽고 행동했다면, 누가 승인한 것일까요? 저는 ClickOps 관련 글에서 이것이 어떻게 감사 추적 (Audit Trails)을 깨뜨리는지에 대해 썼으며, 지금도 그때보다 더 나은 답을 가지고 있지 않습니다.

아무도 예약하지 않은 감사

목록에 있는 다른 모든 항목들 — 과도하게 넓은 자격 증명 (over-broad credentials), 제한 없는 폭발 반경 (unbounded blast radius), 파괴적인 호출에 대한 승인 게이트 (approval gate) 부재, 영구적인 권한 상승 (permanent elevated access) — 은 5년 전 IAM 감사 (IAM audit)를 수행했다면 나왔을 결과들입니다. 당시에는 해당 권한들이 실제로 사용되지 않았기 때문에, 보고서로 제출되어 현재의 스프린트보다 낮은 순위로 분류되고 '수정 불가 (won't fix)'로 종결되었을 것입니다.

에이전틱 DevOps (Agentic DevOps)는 바로 그 감사를 운영 환경 (production)을 대상으로, 기계의 속도로, 지속적으로 실행하는 것입니다. 이는 보고서를 제출하고 끝내는 것이 아닙니다.

이러한 우려 사항들을 진지하게 받아들이십시오. 다만, 그 우려들이 어느 시대의 것인지에 대해서는 솔직해질 필요가 있습니다. 에이전트 거버넌스 (agent governance) 플랫폼을 찾는 대부분의 팀에게는 더 단순한 것이 필요합니다. 즉, 조건 키 (condition key), 활성 대신 자격이 부여되는 역할 할당 (eligible-instead-of-active role assignment), 그리고 범위를 좁히지 않은 채 부여된 권한 (permission grant) 같은 것들 말입니다.