웨비나속 Q&A

저희가 실무에서 권장하는 가이드라인은 클라우드별로 따로 관리하지 않고 하나의 공통 기준을 전체에 동일하게 적용하는 것입니다. 앞서 말씀드린 5가지 원칙 가시성 확보, 최소 권한, 라이프사이클 통제, 리스크 기반 대응, 오너십·감사를 AWS, Azure, 온프레미스든 동일한 잣대로 적용하고, 각 클라우드의 네이티브 로그를 따로 보는 게 아니라 하나의 플랫폼에서 통합 수집해 교차 상관분석하는 것이 핵심입니다. 이렇게 해야 "AWS에서는 정상, Azure에서는 이상"처럼 각 클라우드 로그만 봐서는 놓치는 크로스도메인 공격 경로(예: AWS Credential로 Azure 리소스까지 접근)를 하나의 시야에서 잡아낼 수 있습니다. 외부 표준으로는 NIST AI RMF, OWASP 가이드라인 정도를 참고 프레임워크로 함께 정렬시키시길 권해드립니다.

김예남 2026-09-09 15:02

핵심은 "이 신원이 평소 어떤 패턴으로 움직였는가"와의 편차입니다. 구체적으로는 첫째, 접근 시점·주기의 편차로, 대부분의 Machine Identity는 정해진 스케줄이나 트리거로만 동작하는데 그 밖의 시간대나 비정상적으로 잦은 호출이 생기면 의심 신호입니다. 둘째, 접근 출처(IP·네트워크·리전)의 변화로, 평소 특정 서버·클라우드 리전에서만 쓰이던 Credential이 낯선 위치에서 사용되면 도용 가능성이 높습니다. 셋째, 접근 대상의 변화로, 그동안 한 번도 건드리지 않았던 시스템이나 데이터로 갑자기 이동(측면이동)하는 경우입니다. 넷째, 데이터 처리량·행위 유형의 변화로, 평소 소량 조회만 하던 계정이 갑자기 대량 다운로드나 삭제 같은 파괴적 작업을 시도하는 경우입니다. 이 네 가지 시점, 위치, 대상, 행위량의 조합이 정상 자동화와 탈취 후 악용을 구분하는 핵심 기준입니다.

김예남 2026-09-09 15:01

핵심은 두 가지입니다. 첫째, 어떤 외부 API·LLM·MCP 서버로 연결할 수 있는지를 화이트리스트 정책으로 미리 제한해두고, 그 경계를 벗어난 외부 통신 시도는 정책 위반으로 실시간 차단합니다. 둘째, Agent가 토큰이나 API Key를 직접 눈으로 보거나 저장하지 않도록 Credential Injection 방식을 쓰는데, 이러면 프롬프트 인젝션으로 Agent를 속여도 토큰 자체를 빼낼 대상이 없습니다. 여기에 모든 외부 호출을 세션 단위로 기록해서 평소보다 데이터 전송량이 급증하거나 처음 보는 외부 목적지로 나가는 경우를 이상행위로 탐지하고, 이상 징후 시 즉시 연결을 끊는 방식으로 유출·탈취 위험을 통제합니다.

김예남 2026-09-09 15:00

국내 규제 대응은 크게 세 가지로 압축됩니다. 첫째 AI Agent·계정·Key를 전수 파악하고 담당자를 지정하는 것, 둘째 고영향 AI에 대한 사람의 관리·감독 체계와 위험관리 문서를 5년 보관하는 것(AI기본법 요건), 셋째 접근 로그를 담당자까지 추적 가능하게 남기는 것(ISMS-P)입니다. 로드맵은 "가시성 확보 → 기본 위생(Vaulting·로그 표준화) → 권한 최소화(JIT 전환) → 규제 문서화 → 상시 모니터링" 순으로 단계적으로 밟아가시면 됩니다.

김예남 2026-09-09 14:59

네, 답변 감사합니다.

양성필 2026-09-09 15:01

사람에게는 역할 단위로 넓게 권한을 주고 개인의 판단에 맡기지만, AI Agent는 그 반대로 접근해야 합니다. 핵심은 "역할이 아니라 지금 수행할 작업 단위로만" 권한을 쪼개서 그때그때 짧게 내려주는 것입니다. 즉 Agent가 앞으로 할 수도 있는 모든 일을 미리 다 열어주는 게 아니라, 지금 이 한 번의 호출에 필요한 딱 그 범위(어떤 시스템, 어떤 데이터, 읽기/쓰기 여부)만 부여하고 끝나면 즉시 회수합니다. 여기에 "최소 권한"뿐 아니라 "최소 자율성"도 함께 적용해야 하는데, 예를 들어 삭제·대량 변경처럼 되돌리기 어려운 행동은 아무리 권한이 있어도 Agent가 스스로 최종 실행까지 하지 못하게 하고 특정 지점에서는 정책적 승인·확인을 거치도록 경계를 두는 것입니다. 결국 사람처럼 판단력을 신뢰해서 넓게 주는 게 아니라, 판단력이 없다는 전제로 매 순간 범위를 좁혀서 자동으로 통제하는 것이 AI Agent에 대한 최소 권한 적용의 핵심입니다.

김예남 2026-09-09 14:57

핵심은 "한 번에 완전히 바꾸지 않고 겹치는 구간을 두는 것"입니다. 먼저 이 Credential을 어떤 Agent·서비스가 쓰고 있는지 의존관계를 먼저 파악한 뒤, 새 Key를 발급해도 기존 Key를 즉시 폐기하지 않고 일정 기간 동시에 유효하게 두어 애플리케이션이 새 값을 반영할 시간을 벌어줍니다. 그리고 REST API 기반으로 갱신을 자동화해서 사람이 수동으로 어디에 값을 넣어야 하는지 찾아다니지 않아도, 애플리케이션이 실행 시점마다 최신 값을 API로 직접 가져오게 만듭니다. 또한 전체를 한 번에 바꾸지 않고 소수 시스템부터 단계적으로 갱신·검증한 뒤 확대 적용하고, 실패 시 자동 롤백되도록 해서 갱신 자체가 장애 포인트가 되지 않게 설계하는 것이 실무적인 방법입니다.

김예남 2026-09-09 14:56

그 지점이 저희가 Authentication만으로는 안 된다고 강조하는 이유입니다. 정상 권한을 가진 요청이라도, 실제 요청 자체가 위험한 행동이라면 그 행동 자체를 정책으로 막아야 합니다. 그래서 저희 AI Agent Security/EPM은 "누가 요청했는가"와 별개로 "지금 시도되는 행동이 무엇인가"를 실시간으로 판단하는 계층을 따로 둡니다. 예를 들어 정상 인증된 Agent라도 대량 삭제(DB Erasure), 대규모 데이터 조회, 민감 파일 대량 접근 같은 특정 행위 패턴이 발생하면 임계치·정책 기반으로 즉시 차단하고, 세션을 강제 종료할 수 있습니다. 즉 "권한이 있어서 통과된 요청"이라도 "행동 자체가 정책 위반"이면 별도로 걸러내는 구조이기 때문에, 프롬프트 인젝션이나 잘못된 추론으로 인한 정상 권한 오용도 탐지·차단 대상이 됩니다.

김예남 2026-09-09 14:55

프로세스는 크게 네 단계입니다. 먼저 각 서비스 계정·머신 Identity가 "부여받은 권한"과 "실제로 사용한 권한"을 지속적으로 비교해서 얼마나 차이가 나는지 파악합니다. 둘째, 이 차이(안 쓰는 과도한 권한)를 접근 가능한 리소스의 민감도 기준으로 위험도 점수화해서 우선순위를 매깁니다. 셋째, 우선순위가 높은 항목부터 자동으로 "이 권한은 축소 대상"이라는 권고안을 만들어, 승인 워크플로우를 거쳐 실제 엔타이틀먼트를 축소·회수합니다. 넷째, 회수 후에는 그 계정을 상시 권한이 아니라 필요할 때만 발급되는 JIT 방식으로 전환해서, 같은 과잉 권한이 다시 쌓이지 않도록 구조 자체를 바꿉니다. 이 사이클(사용량 대비 권한 비교 → 위험 점수화 → 자동 회수 권고 → JIT 전환)을 일회성이 아니라 상시 반복하는 것이 핵심입니다.

김예남 2026-09-09 14:52

가장 큰 한계는 기존 IAM이 "사람 계정처럼 입사·이동·퇴사 주기로 천천히 생성·삭제되는 신원"을 전제로 설계됐다는 점입니다. AI Agent나 API 토큰은 몇 초 단위로 생성·소멸하는데, IAM의 계정 등록·승인·정기 접근 검토 프로세스는 이 속도를 따라갈 수 없어서, 다음 검토 시점이 오기 전에 이미 그 신원은 사라지고 없는 경우가 많습니다. 또한 IAM은 대부분 중앙 디렉토리(AD, Entra 등)에 등록된 신원을 전제로 하는데, 클라우드 서비스나 개발 도구가 런타임에 직접 발급하는 API Key·토큰은 애초에 이 디렉토리 밖에서 생성되기 때문에 IAM 시야에 아예 잡히지 않는 사각지대가 생깁니다. 결국 "언제 생겼다가 언제 없어졌는지, 누구 소유였는지"를 실시간으로 못 따라가는 것이 기존 IAM 단독 운영의 가장 큰 한계이고, 그래서 실시간 발견·소유권 매핑·자동 회수까지 하는 별도 계층이 필요한 이유입니다.

김예남 2026-09-09 14:50

사람의 이상행위 탐지는 로그인 시간대·위치·행동 패턴처럼 "평소와 다른가"를 기준으로 삼는데, AI Agent는 24시간 기계 속도로 반복 동작하고 애초에 비정형적이라 "평소 패턴"이라는 기준 자체를 잡기 어렵습니다. 그래서 Machine Identity는 행동 패턴 기반이 아니라 "부여된 권한 범위 이탈 여부" 기준으로 탐지를 설계합니다. 즉 이 Agent가 원래 허용된 시스템·데이터 범위를 벗어났는지, 평소보다 호출 빈도·속도가 비정상적으로 급증했는지, 처음 접근하는 리소스로 옮겨갔는지 부여받은 Credential의 용도·유효시간 밖에서 사용됐는지를 기준으로 삼습니다. 결국 "그동안 어떻게 행동했는가"가 아니라 "정책상 허용된 범위를 지금 벗어났는가"를 실시간으로 대조하는 것이 Machine Identity 특화 탐지의 핵심 설계 기준입니다.

김예남 2026-09-09 14:48

BeyondTrust은 이미 사람·서비스 계정·머신 Identity 전체의 권한 경로를 하나의 그래프로 추적해온 True Privilege™ Graph를 갖고 있고, 여기에 모든 Credential 사용을 세션 단위로 기록·감사하는 체계를 결합해왔다는 점이 다른 벤더 대비 강점입니다. Multi-Agent 환경도 이 연장선에서 접근합니다. 즉 Agent A가 Agent B를 호출하는 것을 새로운 별개의 권한으로 보지 않고, 기존 그래프에 하나의 위임 홉(hop)으로 편입시켜서 "이 실행이 결국 어떤 사람 오너의 권한에서 출발했는지"를 끝까지 역추적할 수 있게 확장하는 것이 저희의 방향이자 이미 갖고 있는 기반입니다. 저희는 신원 그래프와 세션 감사를 처음부터 하나의 플랫폼(Pathfinder)으로 설계해왔기 때문에, Multi-Agent 위임 체인도 별도 신규 도구 없이 기존 아키텍처를 확장하는 형태로 대응할 수 있다는 것이 핵심 차별점입니다.

김예남 2026-09-09 14:46

1. 핵심 차이는 "판단력과 상호작용 여부"입니다. 사람 계정은 MFA·컨텍스트 판단이 가능하고 사용 패턴이 간헐적이며 한 사람에 한두 개 정도의 신원으로 관리 범위가 명확합니다. 반면 머신 Identity(API Key, 서비스 계정, 인증서, AI Agent)는 MFA 같은 상호작용형 인증을 못 받고, 24시간 기계 속도로 대량 반복 호출되며, 수량 자체가 사람보다 수십~수백 배 많고 소유자가 불분명해지기 쉽다는 점이 근본적으로 다릅니다. 그래서 사람 계정처럼 "본인 확인" 중심이 아니라 "이 신원이 지금 이 행동을 할 자격이 있는가"를 매번 기계적으로 검증하는 방식이 필요합니다. 2. 보안 엔지니어 관점에서 강조할 차별점은 세 가지입니다. 첫째, 대부분의 경쟁 솔루션은 Secret을 잘 숨기는 데(Vaulting) 집중하지만, BeyondTrust는 공격자보다 먼저 "어디에 노출된 API Key가 있고 그게 뚫리면 어디까지 번지는지(Blast Radius)"를 그래프로 먼저 찾아내는 선제적 탐지가 강점입니다. 둘째, Key를 안전하게 보관하는 것뿐 아니라 그 Key를 호출하는 클라이언트/Agent 실행 자체도 최소권한으로 통제(EPM)하기 때문에 API 앞단과 뒷단을 모두 잡는 유일한 구조입니다. 셋째, 사람·서비스 계정·AI Agent를 별도 도구가 아니라 하나의 플랫폼(Pathfinder)에서 통합 관리해, 도구가 파편화되면서 생기는 사각지대 자체를 없앤다는 점을 제안 포인트로 가져가시면 좋습니다.

김예남 2026-09-09 14:44

오 인증보다 인가에 좀더 포커싱 되는 느낌이네요. 그래프 선제적 탐지도 좋 아 보이네요.. 답변 감사합니다!

손가영 2026-09-09 14:57

1. 장기 보유 리스크를 줄이는 핵심은 애초에 장기가 없게 만드는 것입니다. Key를 Vault에 넣고 필요한 순간에만 짧은 유효기간(TTL)으로 발급해 작업 종료 즉시 자동 폐기·회전시키면, 탈취되더라도 사용 가능한 시간 자체가 매우 짧아 피해가 제한됩니다. 2. Agent-to-Agent 권한 확장은 매 호출 단계마다 별도로 인가를 다시 판단하게 만들어야 통제됩니다. 처음 받은 권한을 다음 Agent에게 그대로 넘기는 게 아니라, 호출마다 "지금 이 요청이 필요한 최소 범위인지"를 게이트웨이(MCP Server 등)에서 재검증하고, 범위를 넘어서는 순간 자동 차단·기록되게 하는 구조가 필요합니다. 3. 기존 PAM과 가장 크게 달라져야 하는 부분은 "고정 신원, 사전 승인 중심"에서 "동적 신원, 실시간 판단 중심"으로의 전환입니다. 관리자 계정 PAM은 소수의 정해진 사람에게 세션 단위로 권한을 부여하는 모델이었다면, AI Agent 환경은 수백 개의 계속 변하는 비인간 신원에 대해 매 작업 단위로 최소 권한을 자동 판단·회수하는 모델이어야 합니다.

김예남 2026-09-09 14:42

네, 매우 흔합니다. BeyondTrust Phantom Labs 조사에 따르면 전체 환경의 70%에서 아무도 모르는 채 권한을 가진 휴면 서비스 계정이 발견됐고, Machine Identity 수가 사람 계정보다 최대 80배 이상 많다는 통계도 있습니다. 코드에 하드코딩되거나, 개발자가 임시로 만들고 잊어버리거나, 여러 팀이 각자 만들어 아무도 전체를 파악하지 못하는 경우가 대부분이라, "모른다"는 것 자체가 오히려 일반적인 상태에 가깝습니다.

김예남 2026-09-09 14:39

Active Directory·Entra·AWS·Okta·GitHub·SaaS(OpenAI, Salesforce, ServiceNow 등)에 연동되는 자동 커넥터로 전사 환경을 지속적으로 스캔해서 서비스 계정·API Key·인증서·AI Agent를 자동 발굴하는 것입니다. 발굴된 항목은 접근 범위·민감도 기준으로 자동 위험도 점수를 매겨 분류하고, 반드시 담당자를 매핑해 "누구 소유인지 모르는" 상태를 없애야 합니다. 이렇게 지속적·자동으로 탐색-분류-오너 지정까지 되어야 그다음 단계인 Vaulting·Rotation·JIT 전환이 의미가 있고, 일회성 점검이 아니라 상시 반복되는 프로세스로 운영하는 것이 핵심입니다.

김예남 2026-09-09 14:38

GPU 서버 같은 실제 장비에는 실행 통제를 위한 가벼운 Agent(EPM)를 설치해야 하고, 계정·Secret 관리(Password Safe 등)는 장비마다 설치할 필요 없이 Agentless로 네트워크 연동만으로 처리됩니다. 다만 AI Factory가 폐쇄망·별도 세그먼트로 격리돼 있다면, 그 안에 중계 장비 하나를 둬서 방화벽을 열지 않고도 외부 관리 플랫폼과 안전하게 연결하는 구성이 일반적입니다.

김예남 2026-09-09 14:37

Discovery 단계에서 코드 저장소, CI/CD 파이프라인, 설정파일, 환경변수, 클라우드 콘솔 등을 스캔해서 하드코딩된 API Key·Secret과 그걸 쓰는 서비스 계정·Agent를 자동으로 찾아내고, 각각의 노출 위험도와 접근 범위를 점수화해 우선순위를 매깁니다. 둘째, 발견된 Secret은 즉시 Password Safe에 온보딩(Vaulting)하면서 기존 값은 강제로 Rotation시켜 이미 코드에 남아있던 값을 무효화합니다. 즉 발견과 동시에 "노출된 키"를 죽이는 것이 핵심입니다. 셋째, 코드나 워크플로우 쪽은 하드코딩된 값을 참조하는 대신 실행 시점에 API·SDK로 Password Safe에서 Credential을 Check-out하도록 바꾸고, 이때 발급되는 Credential에는 TTL을 걸어 작업이 끝나면 자동 만료·회수되게 합니다. 이 단계에서 비로소 상시 존재하던 권한이 "필요한 순간에만 존재하는" 구조로 바뀝니다. 마지막으로 이 Discovery를 일회성이 아니라 지속적으로 반복해서, 새로 생기는 하드코딩이나 미관리 계정을 계속 잡아내고, 더 이상 쓰이지 않는 상시 계정은 단계적으로 폐기합니다. 이 사이클(발굴→무효화→JIT 전환→지속 재탐지)이 반복되면서 조직 전체가 Zero Standing Privilege 상태로 수렴하게 되는 것이 실제 자동화 프로세스입니다.

김예남 2026-09-09 14:35

1. AI 운영 성숙도의 핵심은 세 가지 체계가 서로 연결되어 있어야 한다는 점입니다. 모니터링은 단순 가동 여부가 아니라 "지금 어떤 Agent가 존재하고 무엇에 접근하고 있는가"를 실시간으로 보는 Agent 인벤토리·행위 모니터링이 기본이 되어야 하고, 로그 관리는 각 Agent의 행위를 원래 사람 오너까지 연결해 감사 가능한 형태로 중앙화·보존하는 체계(SIEM 연동 포함)가 필요합니다. 비용 관리는 클라우드 인프라 비용만 볼 게 아니라 API 호출·토큰 사용량을 Agent 및 담당 부서 단위로 추적해서, 권한이 과도하거나 비정상적으로 반복 호출하는 Agent가 곧 보안 리스크이자 비용 리스크라는 것을 함께 볼 수 있는 구조가 이상적입니다. 결국 이 세 가지가 따로 운영되면 사각지대가 생기고, 하나의 Identity 축을 중심으로 묶여야 실제로 의미가 있습니다. 2. AI Agent와 GitOps·플랫폼 엔지니어링이 만나면서 권한과 보안 정책 자체가 "사람이 나중에 검토하는 것"에서 "코드로 미리 선언하고 배포 파이프라인에 내장되는 것"으로 옮겨가는 방향으로 가고 있습니다. 즉 Agent가 어떤 권한으로 어떤 시스템에 접근할 수 있는지가 Git으로 관리되는 정책 파일 형태로 선언되고, 플랫폼팀이 만든 표준화된 골든패스를 따르면 자동으로 최소권한·JIT이 적용되는 식입니다. 이런 흐름에서 운영 조직이 우선 준비해야 할 역량은 개발팀·플랫폼팀·보안팀이 따로 움직이지 않고 함께 정책을 설계하는 협업 체계, 그리고 인프라뿐 아니라 신원·권한까지 하나의 관측 대상으로 보는 통합 가시성 역량입니다. 결국 보안팀 혼자 통제하는 모델에서, 플랫폼에 보안이 기본값으로 내장되는 모델로 조직 역량 자체를 옮겨가는 것이 핵심입니다.

김예남 2026-09-09 14:33

사람이 매번 승인하는 게 아니라 정책 엔진이 실시간으로 자동 판단하게 만드는 것입니다. AI 도구는 기본적으로 표준 권한으로만 동작하고, 필요한 명령·MCP 연결·DB 접근이 생기면 미리 정의된 정책에 따라 실행 직전에 자동으로 허용·차단되며, DB 접근 시에는 개발자가 Key를 직접 다루지 않고 그 순간에만 짧게 유효한 Credential이 자동 발급됩니다. 이 모든 판단과 실행은 자동으로 로그에 남기 때문에, 개발 흐름은 끊기지 않으면서도 사후에 전체를 추적·감사할 수 있습니다.

김예남 2026-09-09 14:31