AlpacaX
Blog

Engineering

설계로 구현하는 상시 권한 없음: 토큰이 아니라 세션의 속성으로

대부분의 벤더는 자격증명을 일회성으로 만듭니다. Alpacon은 권한 자체를 세션 단위로 제한해, 세션이 유지되는 동안에도 상시 권한이 쌓이지 않도록 합니다.

Eunyoung Jeong
Eunyoung JeongFounder & CEO · 2026년 8월 13일

대부분의 벤더는 자격증명을 일회성으로 만듭니다. Alpacon은 권한 자체를 세션 단위로 제한해, 세션이 유지되는 동안에도 상시 권한이 쌓이지 않도록 합니다.

AI 에이전트에 상시 권한을 부여해서는 안 된다는 데에는 대부분의 PAM 벤더가 동의합니다. 일반적인 접근은 작업별로 일회성 토큰을 발급하고, 작업이 끝나면 즉시 회수하는 방식입니다. 정적 관리자 키를 없애고 자격증명의 수명을 줄인다는 점에서 올바른 방향입니다. 하지만 이 방식은 대부분 아이덴티티 계층에서 구현됩니다. 자격증명이 짧게 유지될 뿐, 유효한 동안 사용할 수 있는 권한까지 제한되는 것은 아닙니다. 수명이 짧은 자격증명도 살아 있는 동안에는 연결된 아이덴티티의 권한을 그대로 물려받습니다.

이 글에서는 상시 권한 없음을 자격증명의 수명 주기로 구현하는 대신, 에이전트가 작업하는 세션의 구조적 속성으로 만드는 방법을 다룹니다. 앞선 글에서는 에이전트를 추가하더라도 공격 표면이 함께 넓어져서는 안 된다는 점을 살펴봤습니다. 에이전트가 시스템에 연결되는 접근 경로에 관한 이야기였습니다. 이어진 글에서는 적시 접근이 에이전트의 진입 여부를 통제할 수 있지만, 진입한 뒤의 동작까지 제한하지는 못한다는 점을 설명했습니다. 이번 글은 한 단계 더 내려갑니다. 에이전트가 세션 안에서 사용할 수 있는 권한을 설계 단계에서 어떻게 제한할 것인지 살펴봅니다.

여기서 말하는 상시 권한 없음은 단순히 자격증명이 빠르게 만료된다는 뜻이 아닙니다. 세션에서 사용할 수 있는 권한이 사전에 선언한 범위를 넘지 못하도록 실행 계층에서 제한하는 구조를 의미합니다.

상시 권한 없음은 그저 더 빨리 만료되는 토큰일 뿐인가요?

일회성 접근은 설정 파일에 남아 있는 정적 관리자 키보다 안전합니다. 오래 유지되는 자격증명을 에이전트에 제공하지 않는 것만으로도 상당한 위험을 줄일 수 있습니다.

하지만 '일회성'이라는 표현은 자격증명이 얼마나 오래 유지되는지를 설명할 뿐, 그 자격증명으로 무엇을 할 수 있는지까지 제한하지는 않습니다. 토큰을 특정 작업에 연결하더라도 유효한 동안에는 아이덴티티의 권한을 물려받습니다. 해당 아이덴티티가 프로덕션 환경에 접근할 수 있다면 토큰 역시 접근할 수 있고, 작업이 진행되는 동안 그 권한은 계속 유지됩니다. 분당 수십 건의 동작을 수행하는 에이전트라면 토큰이 만료되기 전에 복구하기 어려운 변경을 일으킬 수 있습니다. 자격증명은 예정대로 사라졌더라도, 유효한 시간 동안의 권한은 제한되지 않았던 셈입니다.

따라서 자격증명의 수명과 세션에서 사용할 수 있는 권한은 별도로 다뤄야 합니다. 필요한 것은 세션에서 사용할 수 있는 권한이 해당 세션을 연 목적을 넘지 못하도록 보장하는 구조입니다. 두 문제는 서로 다른 계층에서 해결됩니다.

상시 권한은 실제로 어디에 숨어 있나요?

요약: 첫 번째는 살아 있는 세션 안에서 사용할 수 있는 권한의 범위입니다. 두 번째는 일회성 토큰 발급 흐름에 포함되지 않는 서비스 토큰, 슈퍼유저 API 키, 주인 없는 OS 계정 같은 장기 자격증명입니다.

발급과 회수를 중심으로 한 모델에는 두 가지 사각지대가 있습니다.

첫 번째는 살아 있는 세션 내부의 권한 범위입니다. 토큰이 발급되면 아이덴티티 계층은 행위 주체를 인증하고 접근 권한을 전달합니다. 이후에는 전달된 권한으로 접근할 수 있는 영역이라면 어디든 도달할 수 있습니다. 토큰의 수명 주기만으로는 특정 작업과 개별 동작을 계속 연결하기 어렵습니다.

두 번째는 일회성 토큰 발급 흐름에 포함되지 않는 자격증명입니다. 여기에는 CI 파이프라인에 연결된 서비스 계정, 슈퍼유저 API 키, 일회성 마이그레이션을 위해 만들었지만 방치된 로컬 OS 계정 등이 포함됩니다. 이런 자격증명은 생성과 삭제를 책임지는 주체가 불분명해지면서 장기간 남을 가능성이 큽니다. 말 그대로 상시 권한이 쌓이는 영역입니다. CSA와 Oasis 설문에 따르면 조직의 78%가 AI 아이덴티티의 생성과 삭제에 관한 공식 정책을 갖추지 못했고, 클라우드 네이티브 및 DevOps 환경에서는 머신 아이덴티티가 사람보다 최대 144배 많을 수 있습니다(Entro Security). 조직이 존재 자체를 파악하지 못하는 자격증명은 교체 주기를 단축하는 것만으로 관리할 수 없습니다.

세션 모델은 어떻게 상시 권한 없음을 구조적 속성으로 만드나요?

요약: 모든 동작은 사전에 선언된 범위를 가진 세션에 속합니다. 이 범위는 설계상 RBAC 위에 놓인 상한으로, 특정 세션이 실제로 사용할 수 있는 권한을 제한합니다. 세션에는 시간 제한과 자동 회수가 적용되며, 범위 확장에는 별도의 승인이 필요합니다. 시간 제한과 자동 회수는 현재 제공되고 있고, 범위 상한 거부는 monitor-then-enforce 방식으로 적용됩니다.

Alpacon에서는 사용자와 에이전트의 모든 동작이 Work Session에 속합니다. 세션 밖에서 직접 동작을 실행하는 별도의 경로는 제공하지 않습니다. 각 세션은 시작 전에 작업 범위와 목적을 선언합니다. 처음 실행한 명령을 바탕으로 세션의 범위를 사후에 추정하지 않습니다.

이때 선언된 범위는 설계상 일반적인 역할 권한 위에 놓인 인가 상한입니다. RBAC은 해당 아이덴티티에 어떤 권한을 부여할 수 있는지 결정합니다. 세션 범위는 그중 이번 세션에서 실제로 사용할 수 있는 권한을 제한합니다. 따라서 RBAC상 허용된 sudo 명령이라도 세션 범위에 포함되지 않았다면 세션이 인가하지 않습니다. 슈퍼유저 역시 세션이 선언한 범위를 넘어설 수 없습니다. 에이전트가 영향을 미칠 수 있는 범위는 아이덴티티에 부여된 전체 역할이 아니라 해당 세션의 작업 범위에 따라 결정됩니다. Alpacon은 이 범위 상한을 monitor-then-enforce 방식으로 적용합니다. 먼저 실제 트래픽을 기준으로 범위를 벗어날 가능성이 있는 동작을 계측합니다. Enforce 모드가 활성화된 환경에서는 범위 밖의 sudo 명령이 승인 요청으로 전달되기 전에 거부됩니다.

이 구조는 다음 속성으로 유지됩니다. 세션 범위에 포함되지 않은 동작은 허용하지 않습니다. 실제 범위는 서버가 허용하는 영역과 세션이 선언한 영역의 교집합으로 결정됩니다. 모든 세션에는 TTL이 적용됩니다. 만료되면 세션을 종료하고 자격증명을 자동 회수합니다. 이 기능은 현재 제공되고 있습니다. Enforce 모드에서는 범위를 벗어난 동작이 호스트에 도달하기 전에 차단됩니다. 범위를 벗어난 동작이 거부되면 운영자는 작업 범위를 다시 선언하도록 안내받습니다. 요청이 기존 권한으로 그대로 통과하지는 않습니다.

여기에 범위 확장을 위한 별도 통제가 더해집니다. 세션 도중 범위를 넓히려면 승인이 필요하며, 승인 절차는 대역 밖 채널에서 처리됩니다. 에이전트가 작업 요청을 보내는 채널과 승인 채널을 분리하기 때문에 에이전트가 자신의 권한 상승을 직접 승인할 수 없습니다. 새로운 권한을 여는 과정에는 최소한 해당 권한으로 실행할 작업과 같은 수준의 통제가 필요합니다. 비인간 주체가 여러 토큰을 보유하고 있더라도 자체적으로 권한을 확장할 수 없습니다. 권한이 이미 사용된 뒤 변화를 검토하는 것은 운영 절차입니다. 권한이 처음부터 선언된 범위를 넘어설 수 없게 만드는 것은 시스템의 구조적 제약입니다.

세션 토큰이 건드리지 않는 자격증명은 어떻게 되나요?

'상시 권한 없음'이라는 표현은 기술적으로 엄격하게 사용해야 합니다. 현재 어떤 환경에서도 모든 자격증명에 이 말이 문자 그대로 들어맞지는 않으며, 그렇지 않다고 말하는 벤더는 슬로건을 파는 것입니다.

Alpacon에서 현재 제공되는 범위는 다음과 같습니다. 사용자와 에이전트 세션에는 범위와 시간 제한이 적용됩니다. 상시 키와 볼트에 저장된 시크릿은 일반적인 접근 경로에서 제외돼, 사용자가 오래 유지되는 자격증명으로 직접 접속하지 않도록 합니다. 아직 해결되지 않은 영역도 있습니다. 서비스 토큰은 여전히 장기간 유지되며 세션이 아닌 정적 ACL을 기준으로 제한됩니다. 슈퍼유저 API 토큰의 상시 권한을 제거하는 기능은 로드맵에 있으며 아직 출시되지 않았습니다. 이러한 예외까지 명시해야 하는 이유는 정상적인 세션 경로 밖에서 발급되고 사용되는 자격증명도 전체 권한 구조에 포함되기 때문입니다.

주인 없는 OS 계정은 상시 권한이 남기 쉬운 대표적인 영역입니다. Alpacon은 계정 출처(provenance)를 이용해 관리 대상 서버의 로컬 계정이 어디에서 생성됐는지, Alpacon이 프로비저닝한 계정인지 확인할 수 있도록 합니다. 이를 통해 비활성 계정과 공유 계정, 주인이 확인되지 않는 계정을 식별할 수 있습니다. 특정 사용자가 해당 계정에 갖고 있던 마지막 접근 권한을 잃으면, Alpacon이 프로비저닝한 계정은 자동으로 프로비저닝 해제됩니다. 반면 Alpacon이 생성하지 않은 발견 계정이나 공유 계정은 자동으로 삭제하지 않습니다. 대신 퇴사하거나 접근 권한을 잃은 아이덴티티와 계정 사이의 연결만 해제합니다. 아이덴티티 공급자의 퇴사자(leaver) 이벤트를 호스트까지 전파하는 기능은 로드맵에 있으며 아직 출시되지 않았습니다. 이 접근은 기업의 21%만이 AI 에이전트를 폐기하는 공식 절차를 갖추고 있다는 CSA와 Token Security의 조사 결과와도 연결됩니다. 누가 만들었는지, 현재 누가 사용하는지 알 수 없는 계정은 지속적인 권한으로 남을 수 있습니다. 먼저 계정의 존재와 출처를 확인할 수 있어야 관리도 가능합니다.

자격증명 유형별 현재 상태를 정직하게 정리하면 다음과 같습니다.

자격증명 유형현재 상시 권한 상태
사용자·에이전트 세션없음. 범위와 시간 제한이 적용되며 세션 종료 시 자동 회수
상시 키·볼트 보관 시크릿일반 접근 경로에서 제외
주인 없는 OS 계정출처를 확인할 수 있음. 마지막 접근이 제거되면 Alpacon이 프로비저닝한 계정은 프로비저닝 해제. IdP 퇴사자 이벤트 연계는 로드맵
서비스 토큰현재 예외. 장기간 유지되며 정적 ACL로 제한
슈퍼유저 API 토큰상시 권한 차단 기능은 로드맵 단계로 아직 미출시

기본 사양은 어디에나 있고, 어려운 건 실행 제어 계층입니다

작업에 연결된 토큰을 발급하는 기능은 접근 프로비저닝에 해당합니다. 여러 벤더가 아이덴티티 계층에서 제공할 수 있는 기능입니다. 세션이 실제로 어떤 명령을 실행할 수 있는지 제한하는 기능은 실행 제어에 해당합니다. 명령이 호스트에 전달되기 직전에 동작을 평가해야 합니다. 따라서 짧게 유지되는 토큰은 기존 아이덴티티 제품에 추가할 수 있지만, 세션 범위를 벗어난 sudo 명령을 실행 전에 거부하려면 명령이 평가되는 계층을 직접 통제해야 합니다. 기본 거부, 최소 범위, TTL, 만료 시 자동 회수는 많은 PAM 제품이 제공하거나 지향하는 기능입니다. 차이가 생기는 지점은 이 정책을 아이덴티티 경계에서만 적용하지 않고 세션 안의 개별 명령에 강제할 수 있는지 여부입니다. 세션이 실제로 보유한 권한은 명령이 실행되는 계층에서 가장 명확하게 드러납니다.

규제 역시 실행 시점의 통제를 요구하는 방향으로 움직이고 있습니다. EU AI Act 제14조는 고위험 AI 시스템에 개입하거나 시스템을 중단할 수 있는 사람을 두도록 요구하며, 2026-08-02부터 구속력을 갖습니다. AI 에이전트가 해당 적용 범위에 포함된다면, 빠르게 연속 동작하는 시스템을 통제하려면 이미 만료된 자격증명을 사후 검토하는 것만으로는 부족합니다. 동작이 실행되는 시점에 보류하거나, 승인을 요청하거나, 세션의 권한을 회수할 수 있어야 합니다.

상시 권한 없음은 단순히 자격증명의 수명을 줄이는 방식이 아닙니다. 슈퍼유저를 포함한 어떤 주체도 세션에서 선언한 범위를 넘어서지 못하도록 제한하는 구조입니다. 이 구조에서는 세션 안에서 발생한 허용, 거부, 권한 상승 요청이 모두 기록으로 남습니다. 다음 글에서는 이 기록을 감사에 사용할 수 있는 증적으로 전환하는 방법을 살펴보겠습니다.

자주 묻는 질문

상시 권한 없음은 일회성 작업 자격증명을 사용한다는 뜻인가요?

일회성 자격증명은 상시 권한을 줄이는 한 가지 수단이지만, 그것만으로 충분하지는 않습니다. 수명이 짧은 자격증명도 유효한 동안에는 연결된 아이덴티티의 전체 권한을 사용할 수 있기 때문입니다. 세션 기반 모델에서는 자격증명의 만료 시간뿐 아니라, 세션에서 실제로 사용할 수 있는 권한의 범위도 실행 계층에서 제한합니다.

범위 상한(scope ceiling)은 RBAC과 어떻게 다른가요?

RBAC은 아이덴티티에 부여할 수 있는 전체 권한을 정의합니다. 범위 상한은 특정 세션이 실제로 사용할 수 있는 영역을 제한하며, 설계상 RBAC 위에 놓입니다. RBAC에 sudo 권한이 포함돼 있더라도 세션 범위에 선언되지 않았다면 사용할 수 없습니다. Alpacon은 이 통제를 monitor-then-enforce 방식으로 적용합니다. Enforce 모드에서는 범위를 벗어난 sudo 명령이 승인 요청으로 넘어가기 전에 거부됩니다.

Alpacon은 모든 상시 자격증명을 없애나요?

현재 모든 유형의 상시 자격증명을 제거하는 것은 아닙니다. 사용자와 에이전트 세션에는 범위 및 시간 제한이 적용되고, 상시 키는 일반 접근 경로에서 제외됩니다. 서비스 토큰은 여전히 장기간 유지되며 정적 ACL로 제한됩니다. 슈퍼유저 API 토큰의 상시 권한을 차단하는 기능은 로드맵에 있습니다. 주인 없는 OS 계정은 출처를 확인할 수 있습니다. Alpacon이 프로비저닝한 계정은 마지막 접근 권한이 제거되면 프로비저닝 해제되지만, 발견 계정과 공유 계정은 자동 삭제하지 않고 아이덴티티와의 연결만 해제합니다. IdP의 퇴사자 이벤트를 호스트까지 전달하는 기능은 아직 로드맵 단계입니다.

AI 에이전트가 세션 도중 자신의 범위를 넓힐 수 있나요?

에이전트가 단독으로 범위를 확장할 수는 없습니다. 범위 확장에는 별도의 승인이 필요하며, 승인 절차는 에이전트가 통제하지 못하는 대역 밖 채널에서 처리됩니다. 비인간 주체가 자신의 권한 상승을 직접 승인하지 못하도록 요청과 승인의 경로를 분리한 구조입니다.

프로덕션 인프라에서 AI 에이전트를 운영한다면, 세션이 일회성인지뿐 아니라 해당 세션의 권한 범위가 제한되는지도 확인해야 합니다.

태그:
  • Zero standing privilege
  • Work Session
  • AI agents
  • Execution control
  • Privileged access
  • AI-native PAM
Eunyoung Jeong
저자 소개Eunyoung JeongFounder & CEO

Eunyoung Jeong is the founder and CEO of AlpacaX, where he's building Alpacon—AI-native PAM with runtime execution control for AI agents. He spent over a decade in national-scale network security research and created mTCP, a scalable user-level TCP stack published at USENIX NSDI '14 (USENIX Community Award, 2K+ GitHub stars). He writes on AI agent security and the gap between access control and execution control.


설계로 구현하는 상시 권한 없음: 토큰이 아니라 세션의 속성으로 | AlpacaX