기업이 AI agent를 들이는 속도는 빨라졌지만, 사람 직원이라면 당연히 거치는 온보딩과 권한 관리는 자주 건너뜁니다. 사내 계정과 도구에 접근하는 agent가 새로운 내부자 위협이 되는 이유입니다. 신원 관리 기업 Okta의 제품·기술 부문 사장과, agent를 격리 환경에서 돌리는 플랫폼을 만드는 한 스타트업의 공동 창업자는 해법을 같은 곳에서 찾습니다. prompt로 규칙을 당부하는 대신, 모델 바깥에서 실행 환경과 신원, 권한, 비상 정지 장치를 결정론적으로(같은 조건이면 늘 같은 결과를 내는 규칙으로) 통제해야 한다는 것입니다.
온보딩 없이 들어온 디지털 직원
사람 직원은 입사할 때 어떤 데이터와 앱, 도구에 접근할 수 있는지 경계를 정하는 절차를 거칩니다. agent는 이런 절차 없이 업무에 투입되는 경우가 많습니다. 기업은 agent를 사람 직원처럼 여기고 사람의 역할을 대신할 존재로까지 보면서도 그에 맞는 관리 체계는 갖추지 않는다는 것이 Okta 쪽의 진단입니다. 부서 예산 안에서 AI agent 구독료와 직원 채용을 같은 선상에 놓고 저울질하는 기업도 이미 나타났습니다.
agent가 고유한 신원과 계정 연결을 갖는다는 점은 위험을 두 방향으로 만듭니다. 통제를 벗어난 agent가 회사 시스템을 해칠 수 있고, agent가 쓰는 도구가 바깥에서 뚫릴 수도 있습니다. agent가 쓰는 headless browser(화면 없이 자동으로 웹을 다루는 브라우저)를 제때 패치하지 않으면 공격자가 작업 환경을 장악하고 연결된 계정까지 악용할 수 있습니다.
생산성 효과를 서두르다 기본 보안 통제를 갖추기 전에 AI에 큰돈부터 쓰는 기업도 많습니다. 최신 모델의 능력에 끌려 보안의 기본 원칙을 놓치고, agent가 접근할 데이터와 도구, 앱 권한, 움직일 범위를 처음에 정리하지 않는다는 것입니다. Okta의 제품·기술 부문 사장은 지금 시장을 ’혼란의 시기’라고 표현합니다.
지시가 아니라 울타리로 행동을 정한다
스타트업 공동 창업자가 1월 말 지금의 플랫폼을 만들기 시작한 계기는 실험 하나였습니다. AI를 중심에 두고 일하는 마케팅 대행사를 운영하며 OpenClaw로 최신 AI agent를 회사 곳곳의 시스템에 보안 제약 없이 연결해 보니, agent는 정규직 직원 한 명 몫의 일을 해냈지만 심각한 보안 구멍도 드러났습니다. 그래서 쓸모는 지키되 보안은 양보하지 않는 플랫폼을 만들기로 했다고 합니다.
그가 내세우는 원칙은 ’AI agent를 믿지 말라’입니다. AI의 쓸모를 의심하거나 도입을 멈추자는 뜻이 아니라, 내부 지시나 prompt가 안전한 행동을 보장한다는 가정을 버리자는 뜻입니다. system prompt(모델에 미리 주는 기본 지시)에 잘 행동하라고 적어 두는 것으로는 부족하고, 모델의 학습과 context(모델이 참고하는 입력 내용) 바깥에서 검증할 수 있는 장치로 안전을 보장해야 한다는 주장입니다.
이 플랫폼은 agent를 sandbox(격리된 실행 환경) 안에 두고, 필요한 데이터 소스와 외부 도구에만 제한된 접근을 열어 줍니다. 다만 작은 행동 하나하나에 사람의 승인을 받게 하면 마찰이 커져 agent를 쓰는 경제적 가치가 사라집니다. 그래서 중간 작업은 agent에게 맡기고, 결과가 바깥으로 나가는 순간에만 사람이 확인하게 합니다.
| 구분 | 예 |
|---|---|
| agent가 알아서 하는 일 | 이메일 검색, 배경 자료 조사, 스프레드시트 작성 |
| 사람이 승인하는 일 | 이메일 발송, 파일 게시, 스프레드시트 외부 전송, 운영 데이터베이스 변경 |
권한은 사람의 신원을 넘지 않는다
Okta는 신원을 AI 인프라의 마지막 보안 경계로 봅니다. agent가 어떤 직원을 대신해 일한다면 그 직원의 권한 범위를 그대로 물려받아야 하고, 그 범위를 넘어서는 안 됩니다. 직원의 신원 token과 권한 부여를 이어받아 허용된 작업만 하는 식입니다. Okta는 agent가 어떤 권한을 내세워 접근했는지 기록하고 추적해 이상 징후를 찾고, agent가 잘못 움직이는지 확인합니다.
통제는 여러 층으로 쌓습니다. IT, 보안, AI 조직의 책임자가 회사 전체의 큰 경계를 정하고, 각 직원은 최소 권한 원칙에 따라 자기가 쓰는 도구의 권한을 더 좁힐 수 있습니다. 출발점은 도구와 세부 행동마다 정해 두는 결정론적이고 세밀한 접근 통제입니다. 도구 접근과 행동이 각각 무엇을 뜻하는지, 데이터 저장 위치에 따른 위험은 없는지 미리 정의하고, 실행 중에는 자동 탐지 엔진이 사람의 개입 없이 권한을 판단해 이 경계를 지켜야 합니다. 스타트업 쪽은 agent의 연결과 접근 통제를 표준화하려는 새 표준 XAA를 Okta와 함께 도입했습니다. Okta의 제품·기술 부문 사장은 이런 여러 겹의 방어를 양파에 빗대, 조직 전체를 감싸는 Okta의 신원 계층과 agent가 도는 container를 바로 감싸는 스타트업의 격리 계층이 겹겹이 쌓인 구조로 설명합니다.
계획을 먼저 승인받고 행동을 대조한다
결정론적 규칙 위에는 agent가 무엇을 하려는지 먼저 드러내게 하는 의도 확인 층을 더합니다.
- agent가 작업 전에 단계별 실행 계획을 내놓습니다. 스프레드시트 검토, 특정 이메일 읽기, Jira에서 이슈 기록 가져오기, GitHub 내용과 대조하기, pull request(코드 변경 요청) 올리기 같은 순서입니다.
- 사용자가 이 계획을 검토하고 승인합니다.
- judge model(다른 AI의 행동을 평가하는 별도 모델)이 agent의 세부 행동을 하나하나 지켜보며 승인된 계획과 맞는지 대조합니다.
- 계획에 맞는 평범한 행동은 자동으로 승인하고, 계획에서 벗어난 행동은 막습니다.
이 방식은 ’이 행동이 안전한가’라는 모호한 질문 대신 ’사용자가 승인한 의도와 맞는가’를 물어 판단 기준을 분명하게 합니다. 이메일이나 공유 문서처럼 파급이 큰 결과물일수록 이 확인을 거쳐야 합니다.
▲ 계획 승인과 행동 대조
sandbox는 뚫린다는 전제로 인프라를 짠다
최소 권한 원칙은 사용자 권한에만 적용할 것이 아니라 인프라 차원에서도 지켜야 합니다. 설계의 출발점은 agent를 믿을 수 없고 sandbox 탈출은 언젠가 일어난다는 가정입니다. 실제로 container를 빠져나가는 일도, VM(가상 머신)을 완전히 벗어나는 일도 일어나며, 최근에는 VM을 완전히 벗어날 수 있게 한 zero-day 취약점(아직 패치가 나오지 않은 취약점)이 공개되기도 했습니다. 그래서 격리를 벗어난 agent가 container를 묶어 돌리는 pod, 호스트 노드, VPC(클라우드 안의 사설 네트워크), 클라우드 계정 가운데 어디까지 닿을 수 있는지 따져 봐야 합니다.
회사 안에서 움직이는 agent에게는 바깥에서는 악용하기 어렵다고 본 취약점도 쉬운 통로가 됩니다. 내부의 agent 무리는 우선순위가 낮던 CVE(공개적으로 등록된 보안 취약점) 여러 개를 엮어, 구멍 뚫린 치즈를 지나듯 시스템 사이를 옮겨 다닐 수 있습니다.
Okta의 제품·기술 부문 사장은 기업의 위험 관리 목록에 쌓인 과제부터 다시 보라고 권합니다. 이런 목록에는 5~10년 동안 방치한 보안 부채가 남아 있는 경우가 많고, 패치하지 않은 CVE는 언제 터질지 모르는 시한폭탄과 같다는 것입니다. 그가 그리는 위협은 한 개인이 Mac mini 여러 대에 open-weight 모델(가중치가 공개된 모델)을 돌려 기업의 취약점을 자동으로 공략하는 모습입니다. 공격 도구가 6개월마다 크게 발전하는 만큼, 자동화된 공격이 닥치기 전에 쌓인 부채를 정리해야 한다는 주장입니다.
새 모델은 위협을 만들어 내는 속도와 침투 시험 능력을 크게 끌어올리지만, 자동 패치와 꼼꼼한 감사, 방어용 AI를 갖출 여력은 일부 대기업과 자금이 넉넉한 제품 기업에만 있습니다. 패치와 설정 변경을 따라가기 어려운 자체 구축 인프라는 갈수록 큰 부담이 되고, 방어 수단이 부족한 미국 중서부의 지역 병원 같은 곳은 자동화된 랜섬웨어 공격에 끊임없이 시달립니다.
기존 네트워크와 데이터 환경의 길목도 다시 점검해야 합니다. 사내 시스템을 VPN 뒤에 두면 agent가 무엇을 하든 IT팀이 곧바로 네트워크 연결을 끊을 수 있습니다. 아주 민감한 데이터를 다루는 흐름이라면 데이터가 한 방향으로만 흐르게 하는 data diode를 검토할 만합니다. 가장 중요한 기본기로는 N-1 패치 관리(최신 버전에서 한 단계 넘게 뒤처지지 않게 유지하는 방식)가 꼽힙니다. AI 도구가 이제 취약점을 찾고 공격 수단을 곧바로 만들어 내는 만큼 패치하지 않은 시스템의 위험이 커졌지만, 이 주기를 제대로 지키는 기업은 거의 없다는 지적입니다.
kill switch는 한 겹으로 부족하다
두 사람은 agent 소프트웨어에 kill switch(비상 정지 장치)가 반드시 있어야 한다고 봅니다. 장치 하나로는 부족하고, 끊는 범위가 다른 장치를 여러 층에 둬야 합니다. agent가 VM을 빠져나와 사내 인프라를 탐색하려 할 때를 생각하면 더욱 그렇습니다.
| 층 | 끊는 방법 |
|---|---|
| 신원 | 특정 직원의 접근 권한 회수 |
| 도구 | 정책을 실시간으로 바꿔 특정 도구 접근 차단 |
| 네트워크 | VPC 전체를 긴급 차단 |
노트북 안의 sandbox에서 agent를 돌리는 것만으로 안심해서도 안 됩니다. 실제 기업 환경에는 여러 겹의 방어가 필요한데, agent가 격리되지 않은 직원 노트북에 제각각 깔려 있어 대부분의 기업은 효과적인 kill switch를 갖출 준비가 아직 멀었다는 것이 스타트업 공동 창업자의 진단입니다.
▲ 여러 층의 kill switch
막을수록 커지는 shadow AI
선의의 CISO(최고정보보호책임자)가 두려움 때문에 AI agent를 아예 금지하면, 오히려 shadow AI(회사가 승인하지 않은 AI를 몰래 쓰는 일)가 커질 수 있습니다. 승인된 도구를 연결하지 못한 직원은 정당한 업무를 끝내려고 위험한 우회로를 찾기 때문입니다.
한 대기업 직원은 업무 분석 대시보드를 만들려고 매주 data lake(회사 데이터를 모아 둔 저장소)에서 민감한 고객 기록 수만 건을 스프레드시트로 내려받아, 웹에서 쓰는 Claude에 직접 올렸습니다. 보안 감시를 완전히 벗어난 흐름입니다. 다른 기업에서는 허가받지 않은 데이터를 Claude에 올린 일 때문에 SOX(Sarbanes-Oxley) 규정 준수에 문제가 생겼습니다. 정책으로 접근을 막아 두어도 감시되지 않는 브라우저 업로드가 규제 위반 위험을 크게 키운다는 것입니다.
더 안전한 길은 금지가 아니라 통제된 통로입니다. Okta 같은 신원 관리 서비스로 접근을 관리하고 모든 사용 기록을 남기며 필요한 범위의 데이터만 꺼내 쓰게 하는 편이, 직원이 데이터를 몰래 빼돌리게 두는 것보다 훨씬 안전하다는 것입니다.
agent 팀 시대에는 책임자가 필요하다
기업의 요구는 직원 한 명을 돕는 보조 AI에서, 팀 전체가 여러 agent를 조율해 일을 나누는 방식으로 옮겨 가고 있습니다. 스타트업 공동 창업자는 한 팀에서 agent 32개를 동시에 돌리고 있다고 말합니다. 그는 위협적으로 들리는 swarm(무리) 대신 ’agent 팀’이라는 말을 씁니다.
그가 강조하는 원칙은 모든 agent에 책임을 지는 사람 소유자를 한 명씩 정하는 것입니다. 목표와 방향은 사람이 정하고, agent 팀은 주로 조직 사이에 정보가 흐르게 하는 데 씁니다. 그는 성능을 키우는 축이 학습 연산과 추론 연산에서 agent 팀의 규모를 수십, 수백 개로 늘리는 쪽으로 옮겨 가고 있다고 봅니다.
Okta 쪽도 기업의 관심이 사용자를 대신하는 행동에서 agent끼리 주고받는 상호작용, agent가 자동으로 거래하는 agentic commerce로 빠르게 옮겨 가고 있다고 전합니다. 개인이 쓰는 agent가 일터로 쏟아져 들어오면서 이를 관리하고 보호할 보안 수단을 찾는 기업도 많아졌습니다.
도입 전에 점검할 일
agent 보안은 새 기술 하나로 끝나지 않고 격리, 신원, 의도 확인, 인프라 관리, 다층 차단을 함께 설계하는 일로 보입니다. 보안·IT 담당자라면 다음부터 확인해 볼 만합니다.
- 배포 전에 역할별 권한, 데이터 범위, 도구 권한을 정리합니다.
- agent를 sandbox에 두고, 정책은 prompt가 아니라 모델 바깥에서 집행합니다.
- 사람의 승인은 이메일 발송, 파일 게시처럼 바깥으로 영향이 미치는 행동에 집중합니다.
- agent 권한은 대신 일하는 직원의 범위를 넘지 않게 하고, 모든 접근을 기록합니다.
- 실행 계획을 먼저 승인받고 judge model로 행동을 대조합니다.
- sandbox 탈출을 전제로 pod부터 클라우드 계정까지 최소 권한을 적용하고, 오래된 CVE를 정리해 N-1 패치 주기를 지킵니다.
- kill switch를 신원, 도구, 네트워크 층에 따로 둡니다.
- 전면 금지 대신 기록이 남는 공식 통로를 열고, 모든 agent에 책임자를 정합니다.
기업용 agent를 만드는 쪽이라면 일정도 따져야 합니다. 대기업의 보안 검토, 법무 검토, 구매 절차는 길게는 12개월이 걸렸고, 지금은 3~6개월로 줄이려 하지만 보안 평가만큼은 건너뛸 수 없습니다. 그래서 지금 부딪힌 문제보다 고객 기업이 4~6개월 뒤에 겪을 문제를 내다보고, IdP(직원 신원과 로그인을 관리하는 서비스) 연동 같은 기업 요건을 처음부터 갖추라는 조언이 나옵니다. 두 달 전에 만든 소프트웨어 구조를 지금은 절반의 시간에 다시 만들 수 있을 만큼 agent의 능력이 빠르게 좋아지고 있어, 작은 단계를 하나씩 밟는 방식은 금세 낡을 수 있습니다.