웨비나속 Q&A

사람이 수십~수백 개 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