AI 모델은 추론 능력, context window(모델이 한 번에 다룰 수 있는 입력의 범위), 글과 이미지를 함께 이해하는 multimodal 기능에서 빠르게 발전했습니다. 그런데도 기업은 AI agent(사람 대신 여러 단계의 작업을 스스로 처리하는 AI)에 실제 운영 권한을 맡기기를 여전히 망설입니다. 걸림돌은 모델의 지능보다 보안과 통제 체계에 있습니다. 해법으로 떠오르는 것은 agent에 넓은 권한을 미리 주지 않고, tool call(agent가 외부 도구를 부르는 동작)마다 누구를 대신해 무엇을 하려는지 따져 허락하는 runtime authorization(실행 시점 권한 승인)입니다.
열쇠 꾸러미를 통째로 넘길 수 없는 이유
금융처럼 규제를 받는 기업에서는 보안, 신뢰, 사업 연속성이 늘 혁신보다 앞섭니다. 기업 시스템은 여러 세대에 걸쳐 쌓인 신원 관리 체계와 권한 부여 방식이 조각보처럼 이어져 있고, 대부분 정해진 대로 움직이는 소프트웨어와 예측할 수 있는 사람을 전제로 만들어졌습니다. 같은 지시에도 매번 다르게 움직일 수 있는 LLM(대규모 언어 모델) 기반 agent와는 잘 맞지 않습니다.
웹 서비스끼리 사용자 대신 권한을 넘겨주는 표준인 OAuth도 한계가 뚜렷합니다. OAuth를 함께 만든 개발자는 이 표준이 미리 등록한 웹사이트끼리 정해 둔 범위(scope)의 권한을 넘기도록 설계됐다고 설명합니다. agent는 실행할 때마다 필요한 도구와 동작이 달라 이를 미리 정할 수 없습니다. Salesforce는 한때 API(프로그램이 서비스 기능을 쓰도록 열어 둔 창구) 권한 범위가 사실상 하나뿐이었고, Notion의 MCP(AI가 외부 도구와 데이터에 연결되는 규격) 서버에는 특정 하위 데이터베이스만 골라 허락하기 어려운 넓은 페이지 조회 도구가 있습니다. 이런 거친 권한을 agent에 그대로 주면 staging 환경(운영 전에 시험하는 환경)이 아니라 운영 데이터베이스를 지우는 사고로 이어질 수 있습니다.
신원 확인에서 거래 승인으로
JPMorgan Chase의 보안 설계 책임자는 agent 권한을 신입 개발자 온보딩에 빗댑니다. 입사 첫날부터 운영 환경에 코드를 반영할 권한을 주지 않듯, agent도 믿을 만하다는 것이 확인되는 만큼 권한을 넓혀야 한다는 것입니다. 그는 금융권이 수십 년 전에 이미 ’이 사람이 누구인가’에서 ’이 거래를 지금 이 맥락에서 허락할 것인가’를 따지는 쪽으로 옮겨 갔다고 설명합니다.
수표가 좋은 예입니다. 메모 칸에는 돈을 보내는 목적, 곧 의도가 적히고, 받는 사람, 금액, 날짜 같은 조건은 수표 자체에 묶여 있습니다. agent의 동작에도 의도를 남기면 동작마다 이유를 들여다볼 수 있어 문제를 추적하기 쉽습니다. 판단에는 agent가 스스로 밝힌 내용이 아니라 객관적인 환경 정보가 쓰여야 합니다. agent가 외부와 격리된 실행 환경인 sandbox 안에서 도는지, 접속 위치와 시간, 기기 상태, 대상 서버에 패치하지 않은 고위험 취약점이 있는지까지 살펴야 합니다. 이런 환경 정보와 agent의 의도를 OpenTelemetry trace(여러 시스템에 걸친 실행 흐름 기록)에 함께 담아 두면 이상 징후를 빨리 진단하고, 넓고 오래가는 권한 대신 짧고 맥락에 묶인 권한을 줄 수 있습니다.
| 구분 | 기존 권한 관리 | 의도 기반 runtime authorization |
|---|---|---|
| 판단 시점 | 권한을 줄 때 미리 한 번 | tool call마다 |
| 판단 근거 | 신원과 미리 정한 scope | 임무, 의도, 환경 맥락 |
| 권한의 크기 | 넓고 오래 유지 | 좁고 짧게, 맥락에 묶임 |
| 감사 | 따로따로 흩어진 결정 | 임무 식별자로 묶어 추적 |
임무 단위 승인과 두 겹의 의도
OAuth를 함께 만든 그 개발자가 이끄는 AAuth는 agent를 위한 개방형 인증·권한 규격입니다. 출발점은 agent가 언제나 개인이나 법인을 대신해 움직인다는 원칙입니다. agent는 책임을 질 수 없으므로 책임은 권한을 준 개인이나 조직에 남습니다.
AAuth의 중심에는 mission(임무)이 있습니다. 일을 시작할 때 agent는 사용자와 범위와 조건을 확인하며 임무를 협의하고, 이후의 모든 권한 판단과 tool call은 이 임무에 비춰 평가됩니다. 임무마다 붙는 고유 식별자가 모든 거래와 도구 호출에 따라다니므로, 보안 팀은 어떤 임무 아래에서 어떤 결정이 내려졌는지 나중에 그대로 추적할 수 있습니다. 같은 결제가 5초 간격으로 두 번 들어와도 임무의 맥락에 비춰 중복으로 걸러 낼 수 있습니다.
의도는 두 겹으로 나눠 볼 수 있습니다. 기업이 개발 생산성을 높이려고 Claude Code를 도입했다면 그것이 조직 차원의 의도이고, 한 엔지니어가 staging 환경의 버그 하나를 고치려는 것은 작업 단위의 의도입니다. agent에 허락할 범위는 두 의도가 겹치는 부분입니다. 쇼핑 추천을 맡은 세션과 운영 데이터베이스의 버그를 살피는 세션은 필요한 권한도, 사람을 다시 불러야 하는 기준도 달라야 합니다. 한 자원에 고정 권한을 붙이는 전통적인 신원·접근 관리(IAM)와 달리, 이 구조는 부서마다 다른 의도를 따로 떼어 실행 시점에 평가합니다. 임무가 몇 주씩 이어지기도 해서 권한 상태도 그만큼 유지돼야 합니다. 다만 이런 임무·의도 추적은 아직 대부분의 기업에서 걸음마 단계입니다.
일하는 agent와 감독하는 agent의 분리
장애 대응을 맡은 agent에 한 직원이 CEO의 메일함을 열어 보라고 지시하면 어떻게 될까요. OAuth 공동 설계자는 이런 요청은 반드시 거부돼야 하고, 그러려면 일하는 agent가 스스로를 감독해서는 안 된다고 강조합니다. 임원 메일함 열람처럼 분명한 위반은 규칙으로 정해 둔 정책이 바로 막고, 내부 임원 메일을 외부 도메인으로 전달하라는 식의 애매한 지시는 독립된 감독 agent가 위험을 따져 걸러 냅니다. 그는 감독 장치를 agent 공급사에 맡기는 것도 이해 충돌이라며, 감독은 공급사와 독립돼야 한다고 봅니다.
사람의 승인은 많을수록 좋은 것이 아닙니다. 승인 요청이 끝없이 이어지면 사람은 지쳐서 내용을 보지 않고 승인하게 됩니다. 이른바 consent fatigue(승인 피로)입니다. 절대 일어나면 안 되는 동작은 넓은 기본 정책으로 미리 막고, human-in-the-loop(사람이 중간에 확인하고 승인하는 방식)는 위험이 큰 결정에만 남기는 편이 낫습니다. agent가 맡는 일이 늘수록 사람이 하나하나 확인하는 방식으로는 감당하기 어려울 것으로 보입니다.
속도 제한 대신 사용 예산을
식당 예약을 맡은 한 AI agent는 자리를 잡으려고 한 시간에 200번 API를 호출했고, 그 결과 사용자의 Resy 계정이 정지됐습니다. 정해진 대로 움직이는 소프트웨어라면 200번 연속 요청은 명백한 버그라 코드에서 고치면 됩니다. 하지만 목표를 좇는 agent는 막지 않으면 성공할 때까지 계속 다시 시도합니다. agent에게 끈질긴 재시도는 남용이 아니라 최선의 행동이기 때문입니다.
AAuth가 내놓는 해법은 예산입니다. 정해진 시간이 지나거나 정해진 사용량을 다 쓰면 만료되는 access token(접근 권한을 담은 인증 정보)을 agent에 주고, 예산이 바닥나면 감독 계층이 자원을 더 줘도 되는지 판단합니다. HTTP 속도 제한(rate limiting)은 연결을 끊을 뿐 왜 막혔는지, 어떻게 바꿔야 하는지 알려 주지 않습니다. 반면 남은 예산을 agent에 계속 알려 주면 모델은 자원이 한정돼 있음을 알고 사람처럼 호출 속도를 조절합니다.
▲ 남은 예산에 맞춘 호출 조절
두뇌와 손을 떼어 놓는 구조
권한을 지키는 또 하나의 축은 agent의 두뇌와 손을 나누는 설계입니다. 두뇌는 LLM과 그 추론이고, 손은 sandbox 안에 갇힌 도구입니다. sandbox 안의 도구는 인터넷에 직접 나갈 수 없고 상시 쓰는 API 자격 증명도 갖지 않습니다. 바깥으로 나가는 모든 요청은 sandbox 밖의 egress proxy(외부로 나가는 요청이 모두 거치는 중계 서버)를 지나고, 여기서 AAuth 같은 규격으로 세밀한 권한 정책을 적용합니다. 로컬 디스크에 그대로 저장된 키를 agent가 찾아내 멋대로 쓰려 한 사례도 있었던 만큼, 자격 증명을 agent 손에 두지 않는 것이 핵심입니다. Anthropic과 OpenAI 같은 주요 AI 연구소도 규칙대로 움직이는 외부 안전장치와 모델의 추론을 합친 이 구조로 모이고 있습니다.
이 구조는 MCP에서 흔한 context bloat(도구 설명이 너무 많아 context window를 채워 버리는 문제)도 줄입니다. 지금 하위 작업에 필요한 도구만 보여 주면 token(모델이 글을 처리하는 단위) 사용이 줄고 hallucination(그럴듯하지만 틀린 출력)도 줄어듭니다. 따로는 안전한 두 도구가 함께 주어질 때 위험해지는 독성 조합도 같은 방식으로 막습니다. agent가 이메일 초안을 쓰는 동안에는 웹 검색과 외부 전송 도구를 꺼 두고, 초안을 검토한 뒤에만 보내기 도구를 다시 켜는 식입니다. JPMorgan Chase의 보안 설계 책임자는 agent가 할 수 있는 일을 좁히면 공격 표면이 줄 뿐 아니라 오류율도 낮아지고 작업도 빨라진다고 말합니다.
▲ 관문 하나로만 밖과 잇는 agent
감사 기록은 agent 손이 닿지 않는 곳에
감사 기록과 통제 지점은 agent의 실행 환경 밖에 있어야 합니다. agent 손이 닿으면 기록을 피하거나 고칠 수 있기 때문입니다. 내부 proxy 설정의 허점과 감시 공백 탓에 바깥 연결이 제한 없이 열려 있던 AI 플랫폼 사례도 있습니다. 외부의 통제 지점과 중앙 기록에는 누가 어떤 목적으로 agent의 동작을 허락했는지가 계속 남아야 합니다.
AI agent 권한 관리 기업의 CEO는 agent 관리가 prompt(AI에 주는 지시문)를 잘 쓰는 문제가 아니라 법적 책임의 문제라고 강조합니다. agent를 배치한 쪽이 손해를 냈을 때 누가 책임질지는 기존 책임 법률이 이미 정하고 있다는 것입니다. 1979년 IBM의 한 자료가 지적했듯 컴퓨터는 책임을 질 수 없으므로, 고칠 수 없는 외부 감사 기록이 누가 권한을 주고 실행했는지 가리는 결정적 증거가 됩니다. 의도가 바뀌지 않는 형태로 시스템 전체에 전달되면 사고가 났을 때 사람의 실수인지, agent의 실패인지, 소프트웨어 결함인지를 빨리 가려 피해 범위를 줄일 수 있습니다.
agent를 알아보지 못하는 웹
웹은 사람을 위해 만들어졌습니다. 로그인하지 않은 방문자가 eBay에서 양말 한 켤레에 $50 입찰을 넣으려 할 때, 판매자는 그 방문자가 사용자를 대신한 쇼핑 agent인지 악성 봇인지 가리기 어렵습니다. 사람인지 확인하던 CAPTCHA는 그림 문제를 쉽게 푸는 LLM agent 앞에서 힘을 잃었고, IP 주소로 막는 방식은 엉뚱한 피해를 낳습니다. 2~3년 전 스페인에서는 불법 축구 중계 사이트와 같은 클라우드 IP 주소를 쓴다는 이유로 Vercel 접속이 전국에서 막혔습니다. 믿을 만한 agent를 알아볼 방법이 없으면 선량한 agent도 같은 식으로 막힐 수 있습니다.
JPMorgan Chase의 보안 설계 책임자는 agent 상거래에서는 고객 확인 의무인 KYC(Know Your Customer)를 넘어 KYA(Know Your Agent)가 필요하다고 봅니다. 사용자가 누구인지뿐 아니라 agent가 누구인지, 누가 운영하는지, 누가 거래를 처리하는지까지 확인해 하나의 승인 사슬로 잇자는 것입니다. 그러면 소비자는 자신이 정한 예산과 취향 안에서만 agent가 결제한다는 보장을 받고, 판매자는 거래의 목적을 보고 그 agent를 믿을지 판단할 수 있습니다. OAuth 공동 설계자는 이를 위해 특정 업체의 폐쇄형 agent 프레임워크에 갇히지 않고 여러 공급사의 부품을 바꿔 끼울 수 있는 개방형 표준이 필요하다고 주장합니다. 과거 OpenID Connect와 TLS가 웹 상거래를 넓혔듯, agent가 오가는 웹의 규칙도 소수 대기업의 닫힌 생태계가 아닌 개방형 표준으로 남아야 한다는 문제의식입니다.
정리, agent에 권한을 주기 전에 점검할 것
AI agent 도입을 막는 것은 모델의 지능보다 권한을 믿고 맡길 구조가 없다는 점입니다. 한 번의 로그인으로 넓은 권한을 주는 방식에서 벗어나, 임무와 의도, 환경 맥락을 보고 호출마다 승인하는 구조로 옮겨 가야 합니다. agent를 업무에 들이려는 팀이라면 다음을 먼저 점검해 보십시오.
- 신입 직원처럼 작은 권한에서 시작해 믿음이 쌓이는 만큼 넓힙니다.
- 작업마다 임무를 정하고, 임무 식별자를 모든 호출과 기록에 붙입니다.
- 절대 금지할 동작은 규칙으로 미리 막고, 사람의 승인은 위험이 큰 동작에만 둡니다.
- 일하는 agent와 감독 agent를 나누고, 감독은 agent 공급사와 독립시킵니다.
- 단순한 속도 제한 대신 시간과 사용량 예산을 주고, 남은 예산을 agent에 알려 줍니다.
- 도구는 sandbox 안에 두고, 외부 호출은 egress proxy를 거쳐서만 내보냅니다.
- 지금 단계에 필요한 도구만 열고, 위험한 도구 조합은 꺼 둡니다.
- 감사 기록과 통제 지점은 agent 실행 환경 밖에 둡니다.