웨비나속 Q&A

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

사람이 수십~수백 개 Agent의 계정과 권한을 하나하나 승인·검토·회수하는 방식은 숫자가 늘어나는 순간 바로 한계에 부딪힙니다. 그래서 접근 자체를 바꿔야 하는데, 핵심은 "사람이 매번 판단"하는 구조에서 "정책이 자동으로 판단하고 사람은 예외만 본다"는 구조로 넘어가는 것입니다. 즉 Agent 등록·권한 부여·회수를 정책 기반으로 자동화하고, IT팀은 모든 Agent를 동일한 강도로 들여다보는 대신 리스크가 높은 소수(민감 데이터 접근, 넓은 권한 범위)에만 집중하며, 나머지는 자동 모니터링과 이상행위 탐지에 맡기는 방식입니다. 결국 Agent 수가 늘어날수록 사람의 개입은 줄이고 자동화된 거버넌스 비중을 늘리는 것이 유일하게 현실적인 방향입니다.

김예남 2026-09-09 14:30

BeyondTrust의 PAM 철학 자체가 원래 "단일 접속 로그"가 아니라 "Paths to Privilege", 즉 하나의 권한이 여러 시스템을 거쳐 어디까지 도달할 수 있는지 경로 전체를 그래프로 추적하는 것이었고, 이걸 AI 시대에는 사람→Agent→MCP Server→API→또 다른 Agent로 이어지는 실행 체인 전체에 그대로 확장 적용하는 것이 저희가 지향하는 방향입니다. 즉 최종 API 호출 한 줄만 남기는 게 아니라, 그 호출이 어떤 위임 경로를 거쳐 왔는지 매 홉(hop)을 하나의 세션으로 기록하고 이를 원래 사람 사용자까지 하나의 체인으로 연결해서, 사고 발생 시 최종 행위가 아니라 전체 경로를 역추적할 수 있게 하는 것이 목표입니다. 다만 이런 Multi-Agent 전체 체인을 표준화된 형태로 완전히 엮어내는 것은 업계 전반적으로도 아직 진화 중인 영역이라, 지금은 이 방향성을 기존 Identity Security Insights의 권한 경로 매핑과 세션 감사 기능 위에서 단계적으로 확장해가고 있는 단계입니다.

김예남 2026-09-09 14:29

👍🏻

신유진 2026-09-09 14:42

가장 큰 현실적 장벽은 세 가지입니다. 첫째, 상대 시스템(레거시·SaaS·API)이 아직 Workload Identity 인증 자체를 지원하지 않아 완전한 Secretless가 불가능한 경우가 많습니다. 둘째, 기존 코드가 이미 고정 Key를 읽는 방식으로 짜여 있어 단기 토큰 발급·갱신 로직으로 다시 개발해야 하는 리팩터링 비용이 생각보다 큽니다. 셋째, 신원 페더레이션 신뢰관계를 클라우드·온프레미스에 걸쳐 일관되게 구축하는 조직적 작업 자체가 시간이 걸립니다. 그래서 현실에서는 완전 전환보다 신규 시스템은 Secretless로, 레거시는 Vault 기반 JIT으로 병행하는 단계적 접근이 일반적입니다.

김예남 2026-09-09 14:28

👍🏻

신유진 2026-09-09 14:42

BeyondTrust가 실제로 가장 많이 목격하는 문제는 크게 세 가지입니다. 첫째는 통제되지 않은 Shadow AI로, 도입 초기에는 생산성 때문에 현업과 개발자가 각자 알아서 Agent를 만들어 쓰다가, 나중에는 보안팀도 모르는 Agent가 회사 안에 얼마나 있는지조차 파악이 안 되는 상황입니다. 둘째는 AI가 이를 실행한 사용자의 권한을 그대로 물려받는다는 점으로, 운영체제 입장에서는 사람이 내린 명령인지 AI가 낸 명령인지 구분하지 않기 때문에, 원래 있던 과도한 권한(Standing Privilege) 문제가 AI의 속도와 만나 훨씬 빠르고 크게 터집니다. 셋째는 정적이고 수명이 긴 API Key·Credential이 자동화 워크플로우와 코드에 그대로 박혀 방치되는 것으로, 처음엔 빠른 구현을 위해 눈감고 넘어갔던 것이 나중에는 소유자도 불분명한 채 공격자에게 가장 매력적인 진입점이 됩니다. 결국 공통적으로는 "누가 이 AI를 승인했고 무슨 권한을 갖고 있는지"에 대한 가시성과 책임 소재가 없다는 점이 가장 뒤늦게, 그리고 가장 크게 문제가 됩니다.

김예남 2026-09-09 14:26

BeyondTrust 관점에서 핵심만 말씀드리면, 저희는 이미 사람 계정의 복잡한 권한 위임 경로를 하나의 그래프로 추적하고 모든 Credential 사용을 세션 단위로 감사 기록해온 회사이고, Multi-Agent 환경에서도 이 접근을 그대로 확장합니다. 즉 Agent A→B→API로 이어지는 각 호출을 개별 세션으로 기록하고, 그 세션들을 원래 사람 오너 한 명까지 하나의 체인으로 묶어서, 최종 행위뿐 아니라 그 뒤의 전체 위임 경로까지 역추적 가능하게 만드는 것이 저희의 방향입니다.

김예남 2026-09-09 14:25

Key Rotation을 경량화하려면 핵심은 "짧게 살고 자동으로 죽는 키"를 쓰는 것입니다. 지금처럼 반영구적인 API Key를 코드에 박아두고 사람이 주기적으로 바꾸는 방식 대신, 키 발급 시점에 유효기간(TTL)을 같이 지정해서 그 시간이 지나면 시스템이 자동으로 폐기·재발급하도록 만들면 됩니다. 이렇게 하면 별도의 Rotation 배치 스크립트나 스케줄러를 직접 개발·운영할 필요가 없어지고, 키가 새어나가도 유효기간이 짧아 피해 범위가 제한됩니다. Agent 간 최소 권한을 적은 개발 공수로 구현하려면, "누가 어떤 권한을 가지고 있는가"를 Agent 코드 안에 심어두는 방식(정적 권한)에서 벗어나, Agent들이 공통으로 거쳐가는 하나의 지점에서 "이 요청을 지금 승인할지"를 그때그때 판단하는 방식(동적 권한)으로 바꾸는 것이 핵심입니다. 판단 로직을 한 곳에 모아두면, Agent가 하나 늘어날 때마다 권한 코드를 새로 짤 필요 없이 그 지점의 정책만 조정하면 되기 때문에 개발 공수가 크게 줄어듭니다. 그리고 권한도 역할(Role) 단위로 뭉뚱그려 주는 것보다 "지금 이 작업 하나에만" 필요한 범위로 짧게 내려주는 방식이 안전합니다.

김예남 2026-09-09 14:22

Secure AI Agent 운영의 핵심은 AI Agent를 별도 예외로 두지 않고 사람 계정과 동일한 신원 거버넌스 체계 안에 편입시키는 것으로, 저희는 먼저 조직 내 모든 AI Agent와 그 Credential을 빠짐없이 발견해 가시성을 확보하고, 여기에 장기 API Key 대신 JIT 방식으로 필요한 순간에만 최소 권한을 발급한 뒤 사용 후 자동 회수·순환시키며, 엔드포인트에서는 승인된 Agent만 실행되도록 애플리케이션 통제와 실행 전 정책 검증을 적용하고, 모든 Credential과 행위를 특정 담당자에게 매핑해 감사 가능하게 만드는 라이프사이클 전 과정을 하나의 플랫폼에서 자동화하는 방식으로 운영하고 있습니다.

김예남 2026-09-09 14:19

AI Agent 시대에는 Machine Identity 를 설계할 때, 에이전트마다 고유 ID 를 부여하고 이를 트리거한 사용자 ID 와 명확히 연결해야 합니다. 권한은 직무가 아닌 구체적 작업 단위로 스코프하고, 시간 제한과 자동 회수를 강제해야 합니다. 모든 도구·API 호출은 정책 평가 결과(승인/거부, 위험 점수) 와 함께 감사 로그로 남겨야 합니다. Secret 은 에이전트가 아닌 게이트웨이나 제어 평면에서 중앙 관리하고, 단기 위임 토큰만 사용하도록 해야 합니다. 마지막으로, 호출 빈도·데이터 양·접근 경로 같은 비정상 패턴을 실시간으로 탐지해 자동 차단과 재평가가 이루어지도록 해야 합니다.

김예남 2026-09-09 14:17

MCP 환경에서는 Machine Identity 를 에이전트가 아닌 MCP Server에 부여하고, Client 는 시간, 범위 제한된 위임 토큰만 사용하며, 인증, 인가, Secret 관리는 MCP Server 계층에서 일괄 통제하는 것이 가장 안전합니다. 이렇게 하면 에이전트가 장기 Secret 을 소유하지 않아 탈취 위험이 줄고, 게이트웨이에서 최소권한 정책을 일관되게 적용할 수 있으며, 백엔드는 통제된 진입로만 신뢰하면 되어 감사와 차단이 용이해집니다.

김예남 2026-09-09 14:16

1. AI Agent 에 최소권한을 부여하면서도 자율성을 보장하려면, 에이전트를 “넓은 직무”가 아닌 “하나의 구체적 작업”에 매핑하고, 그 작업에 필요한 도구·API·데이터 범위만 허용하는 권한 설계를 적용하는 것이 효과적입니다. 즉, 자원 중심이 아닌 기능 단위로 권한을 스코프하고, 실행 계획에 연동된 단기 토큰을 발급하며, 고위험 작업은 승인 게이트를 두고 나머지는 자동화하는 방식입니다. 2. 비정상적인 권한 사용을 실시간 탐지하려면, 에이전트 고유의 작업자 ID 와 이를 트리거한 사용자 ID, 호출된 도구·API, 인자·데이터 범위, 정책 평가 결과(거부/승인 및 위험 점수) 를 로그로 남기고, 호출 빈도·데이터 양·접근 경로가 기존 베이스라인과 다른지 모니터링해야 합니다. 3. 하이브리드 환경에서 Machine Identity 와 Privileged Access 를 통합 관리하려면, 클라우드·SaaS·온프레미스를 아우르는 단일 제어 평면에서 모든 머신 아이덴티티를 인벤토리화하고, 중앙 시크릿 저장소에서 단기 자격증명을 발급·회수하며, 정책 기반 JIT 접근과 감사 로그를 일관되게 적용하는 아키텍처를 구축해야 합니다. 4. Shadow AI Agent 는 승인되지 않은 에이전트·서비스 계정이므로, 클라우드·SaaS·엔드포인트에서 비정상 API 키·토큰·서비스 계정을 지속적으로 스캔하고, HR/ITSM 연동으로 소유자·수명 정보를 대조해 미등록 아이덴티티를 발견한 뒤, 중앙 정책으로 접근을 차단하거나 강제 등록·감사 대상으로 편입해 통제합니다. 5. AI Agent 가 핵심 업무를 자율 수행하는 단계에서는 기술적 보안 외에, “작업 단위 책임 소재 명확화”, “고위험 작업에 대한 인간 개입 의무화”, “권한·로그·감사의 전사 표준”, “모델·도구·데이터 변경 시 재평가”를 거버넌스 원칙으로 삼고, 이를 뒷받침하는 전사 AI 정책·심의 체계·감사 프로세스를 조직에 정립하는 것이 핵심입니다.

김예남 2026-09-09 14:13

머신 아이덴티티에서 인증서·키·토큰의 관리 공백은, 소유자가 없어 퇴사나 프로젝트 종료 후에도 계정이 살아남아 공격자가 탈취해 사용하고, 만료·교체 주기가 없거나 코드에 하드코딩된 경우 유출돼도 장기간 악용되며, 생성 당시 광범위한 권한을 주고 최소권한 검토를 하지 않아 한 개의 키 탈취로 여러 시스템이 연쇄 침해되는 경로로 침해로 이어집니다.

김예남 2026-09-09 14:10

BeyondTrust 는 AI Agent 를 Non-Human Identity 로 보고, Entitle·Password Safe·Identity Security Insights·Pathfinder MCP Gateway 를 결합해 JIT(Just-in-Time) 접근을 구현합니다. 즉, 에이전트가 작업 시작 시에만 승인 기반의 최소 권한을 단기 발급하고, 작업 종료 후 자동 만료·회수되도록 합니다.

김예남 2026-09-09 14:08

감사합니다.

안철준 2026-09-08 18:04