일반적인 벤더 질문지는 벤더가 누구인지, 데이터를 어떻게 저장하는지까지는 알려 줍니다. 하지만 승인된 AI 에이전트가 서버에서 무엇을 실행하는지는 설명하지 못합니다. 에이전트의 안전성을 판단하려면 실행 단계까지 확인해야 합니다.
보안팀의 승인이 나기 전까지 구매팀은 AI 에이전트 도구를 도입하지 않습니다. 보안팀은 도입을 요청한 SRE나 플랫폼 책임자에게 벤더 질문지를 전달합니다. 엔터프라이즈 거래를 진행하면서 이런 과정을 여러 번 봤습니다. 보안팀은 SOC 2 보고서를 세부 항목까지 검토하고, 구매팀은 제품 문서보다 두꺼운 심사 자료를 준비합니다. 이 정도면 충분히 철저한 절차라고 생각하기 쉽습니다.
문제는 대부분의 질문지가 문서를 저장하고 처리하는 일반 SaaS를 기준으로 만들어졌다는 점입니다. 인프라에서 스스로 명령을 실행하는 소프트웨어를 평가하기 위한 구조는 아닙니다. 기존 질문지는 데이터가 어디에 저장되는지, 어떤 하위 처리자를 이용하는지 잘 묻습니다. 하지만 에이전트가 시스템에 연결된 뒤 어떤 명령을 실행하는지, 무엇을 차단할 수 있는지, 문제가 생겼을 때 누구에게 책임을 연결할 수 있는지는 거의 다루지 않습니다. AI 에이전트 도구의 안전성을 판단하는 데 필요한 질문은 대부분 실행과 관련돼 있습니다. 2026년 현재도 많은 벤더 질문지에는 이 영역이 빠져 있습니다. 이 글에서는 질문지에 추가해야 할 런타임 항목을 정리합니다.
2026년, 표준 AI 벤더 리스크 평가는 무엇을 확인하나요?
AI 벤더 리스크 평가는 구매자가 서드파티 AI 도구를 승인하기 전에 진행하는 검토입니다. 2026년에는 여러 표준과 규제 프레임워크를 함께 고려해야 합니다. 많은 질문지가 NIST AI RMF와 Generative AI Profile, AI 관리 시스템을 위한 ISO/IEC 42001, EU AI Act의 위험 분류 세 가지를 주요 기준으로 삼습니다. 규제를 받는 조직은 산업별 요구사항을 추가로 적용합니다. DORA 제28조는 금융기관이 모든 ICT 서드파티 계약을 등록부로 관리하도록 요구합니다. AI 벤더 역시 ICT 공급자로 분류될 수 있습니다. SOC 2 기반의 벤더 관리 절차는 공급자의 보안 통제와 증적을 검토하는 기준선으로 활용됩니다. 새로운 프레임워크도 빠르게 추가되고 있습니다. 미국 재무부가 2026년 2월 발표한 Financial Services AI Risk Management Framework는 서드파티 위험 영역을 포함한 230개 통제 목표를 제시했습니다. 싱가포르 IMDA도 Model AI Governance Framework를 에이전트형 AI까지 확장했습니다.
EU 규제 일정에는 변경된 부분이 있습니다. 2026년 7월 발효된 Digital Omnibus 패키지는 Annex III에 해당하는 단독 고위험 시스템 의무의 시행 시점을 2026년 8월에서 2027년 12월로 연기했습니다. 그렇다고 2026년 8월 2일에 예정된 모든 의무가 연기된 것은 아닙니다. 대부분의 제50조 투명성 의무와 범용 AI(GPAI) 관련 집행은 기존 일정대로 적용됩니다.
이 프레임워크들은 모두 필요한 검토 기준을 제공합니다. 다만 실제 질문을 살펴보면 대부분 벤더가 누구인지, 데이터를 어떻게 처리하는지, 모델을 어떻게 관리하는지, 어떤 통제를 준수한다고 선언하는지에 집중돼 있습니다. 기존 데이터 처리자 평가를 AI 벤더로 확장한 형태에 가깝습니다. AI 에이전트에서 중요한 실행 영역은 질문지의 범위 밖에 남아 있습니다.
그 질문지는 왜 AI 에이전트의 실제 동작을 다루지 못하나요?
요약: 일반적인 질문지는 데이터를 저장하고 처리하는 소프트웨어를 기준으로 설계됐기 때문입니다. 인프라에서 직접 명령을 실행하는 소프트웨어에는 별도의 위험 축이 필요한데, 질문지에는 그 축이 없습니다.
AI 에이전트 도구의 위험은 저장 데이터의 위치만으로 판단하기 어렵습니다. 승인된 에이전트가 서버에서 어떤 명령을 실행하는지, 누구의 신원으로 실행하는지를 확인해야 합니다.
데이터 소재지 관련 조항만으로는 에이전트가 무엇을 실행했는가, 왜 해당 작업을 실행했는가, 누가 그 작업에 책임을 지는가에 답할 수 없습니다. 이 질문에 답하려면 일반적인 에이전트 시스템에서 부족한 세 가지 요소가 필요합니다. 예측 가능한 실행 경로, 상시 권한이 아닌 작업 단위의 제한된 권한, 그리고 공용 서비스 계정이 아니라 인증된 사람까지 연결되는 책임 추적입니다. 사후에 이런 내용을 확인할 수 없다면 SOC 2 인증이 있더라도 에이전트의 동작을 충분히 통제한다고 보기 어렵습니다.
기록하지 않은 동작은 감사할 수도 없습니다. Cloud Security Alliance 조사에 따르면 기업의 82%가 자사 환경에 파악하지 못한 AI 에이전트를 두고 있습니다. 가시성 문제는 에이전트가 명령을 실행하기 전부터 시작됩니다. 어떤 에이전트가 존재하는지도 알 수 없다면 그 권한과 동작을 평가할 수 없습니다. 벤더 질문지는 도입 단계에서 이 공백을 확인할 수 있어야 합니다.
질문지에는 어떤 런타임 질문이 들어가야 하나요?
AI 에이전트 벤더를 평가할 때는 기존 데이터 처리 검토에 다음 질문을 추가하는 편이 좋습니다. 질문 하나하나가 구매자가 이미 신경 쓰는 프레임워크로 이어집니다.
- 런타임에서 어떤 명령이나 동작을 차단할 수 있나요? 도구가 실행 시점에 어떤 작업을 막을 수 있는지, 위험한 명령을 기록하는 데 그치는지 아니면 실제 실행 전에 보류하거나 거부할 수 있는지 구분해야 합니다 (NIST AI RMF, EU AI Act 리스크 통제).
- 언제 사람의 승인이 필요하며, 어떻게 개입하나요? 고위험 작업이나 판단이 모호한 작업에 사람이 개입할 수 있는지 확인해야 합니다 (EU AI Act 제14조 인적 감독).
- 실행 중인 에이전트나 특정 작업에 개입할 수 있나요? 얼마나 빠르게 가능한가요? 세션 전체를 종료할 수 있는지, 특정 작업만 중단할 수 있는지, 그리고 개입에 걸리는 시간까지 확인해야 합니다. 제14조의 중지 의무와 관련해 일부 2026년 질문지는 프로덕션 에이전트를 5분 이내, 거래 권한을 가진 에이전트를 1분 이내에 종료할 수 있는지를 묻고 있습니다. 이 시간 기준은 공식 표준으로 확정된 수치가 아니라 구매자의 요구가 형성되는 과정에서 나타난 추세에 가깝습니다. 구체적인 기준과 별개로, 실행 중 얼마나 빠르게 개입할 수 있는지는 유효한 질문입니다.
- 에이전트가 무엇을 했고, 왜 했으며, 누구의 신원으로 실행했나요? 감사 기록은 공용 서비스 계정 이름에서 끝나서는 안 됩니다. 각 작업을 인증된 사람이나 명확한 책임 주체까지 연결할 수 있어야 합니다 (EU AI Act 제12조 기록 보관, SOC 2, ISO 42001).
- 에이전트의 권한은 상시 유지되나요, 아니면 작업 단위로 제한되고 자동 회수되나요? 상시 권한의 크기는 문제가 발생했을 때 영향을 받을 수 있는 범위와 직접 연결됩니다 (최소 권한, NIST AI RMF govern/manage).
- 도구 자체가 추가하는 인바운드 공격 표면은 무엇인가요? AI 에이전트 도구 역시 조직의 공격 표면에 포함됩니다.
이런 문제는 가정에 그치지 않습니다. Kiteworks의 2026 Data Security and Compliance Risk Forecast에 따르면, 조사 대상 팀의 60%는 오작동하는 에이전트를 런타임에 종료할 수 있다고 확신하지 못했습니다. 63%는 에이전트가 작동을 시작한 뒤 목적 제한을 강제하지 못한다고 답했습니다. 많은 조직이 자체 환경에서도 이 질문에 답하지 못한다면, 도입하려는 모든 AI 벤더에 같은 질문을 던져야 합니다.
2026년에 런타임 질문이 더 중요해진 이유는 무엇인가요?
요약: 벤더와 구매자 양쪽이 모두 AI 에이전트로 질문지를 작성하고 검토하면서, 문서에 적힌 답변만으로는 실제 통제 수준을 판단하기 어려워지고 있습니다. 게다가 2026년에 보고된 사건들은 데이터가 어디에 저장됐는지가 아니라 에이전트가 무엇을 실행했는지의 문제였습니다.
보안 질문지는 점점 자동화되고 있습니다. 벤더는 AI 에이전트를 사용해 질문지에 답하고, 구매자는 다시 AI 에이전트로 답변을 검토합니다. 양쪽이 모두 서류 작업을 자동화하면 문서에 적힌 답변만으로 실제 통제 수준을 판단하기 어려워집니다. 이 상황에서도 증거로 남는 것은 실제 런타임 동작입니다. 에이전트가 무엇을 실행했는가, 어떤 작업이 차단됐는가, 누가 승인했는가입니다.
2026년에 보고된 여러 사건도 같은 방향을 보여 줍니다. 널리 사용되는 MCP SDK의 명령 실행 취약점, AI 개발 어시스턴트에서 발생한 원격 코드 실행과 자격증명 탈취 공격, 에이전트가 조율한 것으로 알려진 첩보 활동은 모두 실행 단계에서 문제가 발생했습니다. 위험의 중심은 벤더가 데이터를 어떻게 저장했는지가 아니라, 연결된 에이전트가 실제로 무엇을 실행할 수 있었는지에 있었습니다. 이 문제는 AI 에이전트의 공격 표면을 다룬 글에서 자세히 설명했습니다. 실제 환경에서 발생한 초기 LLM 에이전트 침입 사례도 별도의 글에서 살펴볼 수 있습니다. 이 사건들은 기존 데이터 처리자 질문지만으로는 걸러내기 어려웠을 가능성이 큽니다.
실행 제어로 벤더를 실제로 어떻게 평가하나요?
런타임 질문은 실행 제어를 기반으로 한 AI 네이티브 PAM(권한 접근 관리)의 기능과 직접 연결됩니다. Alpacon이 각 질문에 어떻게 대응하는지, 현재 제공되는 기능과 로드맵을 구분해 정리했습니다.
- 런타임 차단. 모든 명령은 실시간으로 위험 평가를 받습니다. 파일 전송은 현재 ACL을 기준으로 통제하며, 전송 의도까지 판단하는 기능은 로드맵에 있습니다. Alpacon은 세션 전체를 중단하는 대신 특정 고위험 작업을 거부하거나 관리자 승인으로 전달할 수 있습니다. 기본 운영 방식은 monitor-and-record이며, enforcement 적용 여부는 배포 시 선택합니다. 따라서 정확한 설명은 Alpacon이 명령 단위로 작업을 차단하거나 보류할 수 있다는 것이지, 모든 환경에서 기본값으로 차단한다는 것이 아닙니다.
- 사람 승인. 판단이 모호한 작업은 사람 승인자에게 전달할 수 있습니다. 승인자가 허용하기 전까지 해당 작업은 진행되지 않습니다. 에이전트가 불확실한 상황에서 임의로 판단하고 실행하는 대신 승인을 기다리게 할 수 있습니다.
- 실행 중 특정 작업에 대한 개입. Enforcement가 활성화된 환경에서는 세션 전체를 종료하지 않고 특정 작업만 실행 전에 보류하거나 거부할 수 있습니다. 개입은 작업이 끝난 뒤가 아니라 명령이 실행되는 시점에 이뤄집니다. 킬체인과 공격 패턴 탐지는 현재 기록된 세션을 대상으로 하는 사후 포렌식 분석으로 제공되며, MITRE ATT&CK 매핑 역시 세션 종료 후 분석에 적용됩니다. 실시간 세션 내 공격 패턴 탐지는 로드맵에 있습니다.
- 실행 내역과 신원 추적. 통제되는 모든 세션은 기록됩니다. 사람과 에이전트의 작업은 하나의 타임라인에 저장되며, 각 작업은 인증된 신원과 실제 사용된 자격증명, 실행한 명령과 시각, 승인 정보, 선언된 목적에 연결됩니다. 공용 서비스 계정만 남는 구조가 아니라 실제 책임 주체까지 추적할 수 있도록 설계돼 있습니다. (이 부분은 별도의 감사 관련 글에서 더 깊이 다룹니다.)
- 상시 권한과 범위 제한 권한. 권한은 세션과 작업 범위에 맞춰 부여됩니다. 적시 접근과 자동 만료를 통해 작업에 필요한 동안만 권한이 유지되고, 세션이 끝나면 회수됩니다.
- 인바운드 공격 표면. Alpacon은 아웃바운드 전용 아키텍처를 사용합니다. 연결된 호스트에 인바운드 포트를 새로 열지 않으므로, 도구를 도입하면서 추가적인 인바운드 접근 경로가 생기지 않습니다.
이 가운데 일부는 PAM 제품의 기본 요건에 가깝습니다. 세션 기록, JIT(필요 시점 부여) 접근 만료, 아웃바운드 전용 아키텍처는 모두 유용하지만 AI 네이티브 벤더를 구분하는 핵심 요소만은 아닙니다. 차이는 실행 제어에서 드러납니다. 명령이 실행 시점에 평가되는지, 특정 작업을 그 자리에서 보류하거나 거부할 수 있는지, 개입이 사후 보고서가 아니라 실행 도중에 이뤄지는지입니다. 기존 데이터 처리자 질문지에는 이런 기준을 기록할 항목 자체가 없는 경우가 많습니다.
프롬프트 인젝션은 벤더가 기능을 과장하기 쉬운 영역입니다. 정확한 설명은 모든 프롬프트 인젝션을 탐지한다는 것이 아니라, Alpacon의 통제 지점이 프롬프트가 아니라 명령이라는 것입니다. 어떤 입력이 에이전트로 하여금 rm -rf를 실행하도록 만들었더라도, 생성된 명령은 여전히 위험 평가를 받고 실행 전에 보류될 수 있습니다. 프롬프트 인젝션을 탐지하는 기능과 그 결과 생성된 명령의 실행을 통제하는 기능은 서로 다른 보안 계층에 있습니다. 기록된 데이터를 바탕으로 프레임워크에 매핑된 SOC 2 또는 ISO 증적을 자동 생성하는 기능은 아직 출시되지 않았으며 로드맵에 있습니다. 해당 증적의 기반이 되는 실행 기록은 현재도 수집됩니다.
자주 묻는 질문 (FAQ)
AI 벤더 리스크 평가란 무엇인가요? AI 벤더 리스크 평가는 구매자가 서드파티 AI 도구를 승인하기 전에 진행하는 검토입니다. 일반적으로 벤더의 신뢰성, 데이터 처리 방식, 보안 통제, NIST AI RMF·ISO 42001·EU AI Act 같은 프레임워크와의 연관성을 확인합니다. AI 에이전트 도구를 평가할 때는 데이터 저장 위치뿐 아니라, 에이전트가 조직의 인프라에서 실제로 무엇을 실행하는지도 검토해야 합니다.
AI 에이전트를 대상으로 한 AI 벤더 리스크 평가에는 무엇이 들어가야 하나요? 기존 데이터 처리자 검토에 다음 여섯 가지 실행 제어 질문을 추가하는 것이 좋습니다. 런타임에서 어떤 명령을 차단할 수 있는가, 언제 사람의 승인이 필요한가, 실행 중인 에이전트나 특정 작업을 얼마나 빠르게 중단할 수 있는가, 에이전트가 무엇을 왜 누구의 신원으로 실행했는가, 권한이 상시 유지되는가 아니면 작업 범위에 맞춰 제한되고 자동 만료되는가, 그리고 도구 자체가 어떤 인바운드 공격 표면을 추가하는가입니다.
실행 제어로 AI 벤더를 어떻게 평가하나요? 각 런타임 질문을 제품이 실행 시점에 실제로 제공하는 기능과 연결해 확인해야 합니다. 명령이 단순히 기록되는 데 그치는지, 실행 전에 보류하거나 거부할 수 있는지 살펴보십시오. 특정 작업에 대한 개입이 실행 중에 가능한지, 각 작업이 인증된 사람과 정확한 자격증명까지 추적되는지도 확인해야 합니다. 현재 출시된 기능과 선택적으로 활성화하는 기능, 로드맵 기능도 명확히 구분해야 합니다.
핵심 정리
AI 벤더 질문지가 데이터 처리 방식만 확인한다면 AI 에이전트의 주요 위험을 놓칠 수 있습니다. 에이전트는 데이터를 저장하는 데 그치지 않고 인프라에서 직접 명령을 실행합니다. 따라서 벤더 평가에도 실행 영역을 포함해야 합니다. 최소한 어떤 명령을 실행 전에 차단할 수 있는지, 언제 사람 승인이 필요한지, 실행 중인 작업에 개입할 수 있는지, 무엇을 누구의 신원으로 실행했는지, 권한이 작업에 맞춰 제한되고 자동 회수되는지, 도구 자체가 새로운 인바운드 공격 표면을 만드는지 확인해야 합니다. Alpacon은 AI 에이전트와 사람이 인프라에서 실행하는 작업을 명령 단위로 평가하고 통제하기 위해 만들어졌습니다.
