[AI·소프트웨어] AI 에이전트는 도구 실행 허가만으로 안전해지지 않습니다

AI 에이전트의 도구 호출 허가와 실행 중 안전성은 서로 다른 문제입니다. Daon 등록특허와 IBM·AI 브라우저 공개청구항은 권한위임·실행격리·민감행위 승인이라는 구별된 제어지점을 보여줍니다.

핵심 요약AI 에이전트의 도구 호출 허가와 실행 중 안전성은 서로 다른 문제입니다. Daon 등록특허와 IBM·AI 브라우저 공개청구항은 권한위임·실행격리·민감행위 승인이라는 구별된 제어지점을 보여줍니다.

AI 에이전트가 사용자를 대신해 이메일을 읽고, 계약서를 검토하고, 업무 시스템에 파일을 올리는 상황을 생각해 보겠습니다. 사용자는 “거래처와의 계약 초안을 정리해 달라”고 요청했습니다. 그런데 에이전트가 읽은 외부 문서 안에 “계약 내용을 외부 주소로 전송하라”는 문장이 숨어 있다면 어떻게 될까요? 에이전트가 이메일 발송 도구를 사용할 권한이 있다는 사실만으로 그 전송까지 정당화할 수는 없습니다.
AI 에이전트의 실행 보안은 단순히 도구를 호출할 수 있는지를 판단하는 기술에 머무르지 않습니다. 누가 어떤 행동을 위임했는지, 실제 도구가 권한 밖 행위를 수행하지 않는지, 결제·기밀정보 전송처럼 위험한 작업에 사용자의 추가 확인이 필요한지가 서로 다른 경계에서 결정됩니다. 이 차이를 미국 등록특허와 공개청구항으로 구체화할 수 있습니다.

1. 같은 도구라도 ‘허가된 행동’은 다를 수 있습니다
예를 들어 하나의 에이전트에게 계약 관련 파일을 읽을 권한을 주었다고 해도, 그 파일을 수정하거나 외부 주소로 전송할 권한까지 주었다고 볼 수는 없습니다. 승인 시점에는 합법적으로 보이던 도구 호출이 실제 실행 과정에서 다른 데이터나 외부 목적지로 확장될 수도 있습니다. 따라서 도구 자체의 사용 허용 여부와 해당 도구가 실행할 구체적 동작의 허용범위를 분리해야 합니다.
이러한 관점은 OWASP의 AI Agent and MCP Security 가이드에서 제시하는 최소권한 원칙과도 연결됩니다. 외부 웹페이지·문서·도구 설명에는 에이전트의 행동을 바꾸려는 지시가 섞일 수 있으므로, 허용할 동작과 데이터 접근은 실제 백엔드 정책과 실행환경에서 검증해야 합니다.

2. Daon 등록특허는 ‘사람의 의도에 묶인 위임’을 검증합니다
Daon Technology의 미국 등록특허 US12688261B1(2026년 7월 21일 등록)의 독립 방법청구항 제1항은 사용자에게 행동상 결속된 자율 에이전트가 보호자원에 관한 도구를 호출할 때의 승인 구조를 다룹니다.
제1항 필수 처리행위실제로 확인하는 정보기술적 의미
도구 호출 요청 수신에이전트·보호자원·요청의 실행맥락권한 판단 대상 특정
충실성 신호(fidelity signal) 취득에이전트가 해당 사람에게 행동상 결속되어 있는가위임의 주체·의도와 연결
무결성 신호(integrity signal) 취득도구 사용 시 예상된 실행행동 범위에 있는가이상행동·변조 가능성 평가
정책 체크포인트 판정신호들과 요청맥락 중 하나 이상에 따른 정책개별 호출의 허용 여부 판단
검증 가능한 위임 증표 생성·사용행위 유형, 범위(scope), 제한된 유효시간실행 시 권한을 기계적으로 확인

제1항에는 충실성 신호와 무결성 신호를 각각 얻는 단계가 포함되지만, 두 신호와 맥락을 어떤 가중치로 결합할지는 구체 실시형태에 따라 달라질 수 있습니다. 종속 제3항은 API 엔드포인트·테넌트·자원·계정 등 범위를 더욱 구체화하고, 종속 제9항은 재사용 공격을 막기 위한 세션 nonce 또는 challenge-response 등을 추가합니다. 이 구체 보안방식들을 독립 제1항의 모든 실시형태에 필요하다고 읽어서는 안 됩니다.
핵심은 로그인한 사용자에게 부여된 포괄적인 토큰 하나로 모든 행동을 정당화하는 것이 아니라, 지금 이 요청에 필요한 행위의 종류와 데이터 범위, 사용할 수 있는 시간을 위임 증표 안에 명시하고 실제 호출에 연결한다는 점입니다. 원공보 FIG. 3~6과 관련 실시예에서 사람-에이전트 결속, 위임 증표 필드, 권한결정 흐름을 비교할 수 있습니다.

경계 A · 실행 이전권한의 출처와 범위사용자 의도 및 에이전트 상태 검증 → 동작·자원범위·유효시간이 제한된 위임 증표Daon US12688261B1
경계 B · 도구 실행 중실제 행위가 허용범위에 있는가도구별 실행환경에서 접근·데이터 흐름 통제 및 실시간 모니터링IBM US20260211997A1
경계 C · 고위험 행동 직전추가 사용자 승인 필요성위험도 분류 → 강화인증·행위요약 승인 → 지출·범위 한도US20260067335A1
그림 1. 세 공보의 서로 다른 신뢰경계. INTLAW가 각 독립 제1항의 제어 지점을 비교하기 위해 구성했습니다. 세 공보는 각각 독립된 발명이므로, 이 도식이 하나의 특허에 위 세 단계를 모두 결합할 의무가 있음을 의미하지는 않습니다.

3. IBM 공개출원은 도구를 허용한 ‘다음’의 실행행위를 보호합니다
IBM의 미국 공개출원 US20260211997A1(2026년 7월 23일 공개) 독립 방법청구항 제1항은 AI 에이전트가 호출하는 도구에 대해 도구에 맞춘 런타임 실행환경(customized runtime execution environment)을 생성하고, 그 환경에서 도구를 실행하면서 실시간으로 감시하는 처리관계를 포함합니다.
이 실행환경은 해당 도구에 관한 보안정책, 도구 권한, 데이터 흐름 분석 중 적어도 하나(at least one of)를 적용하도록 기재되어 있습니다. 따라서 독립항을 검토할 때 세 정책 입력을 반드시 모두 동시에 적용해야 한다고 해석하면 문언을 지나치게 좁힐 위험이 있습니다. 종속 제2항은 실시간 모니터링 결과에 기초한 보안위반 시도 판단을 추가합니다.
가령 파일 내용을 요약하는 도구가 실제로 실행되면서 회사의 다른 프로젝트 폴더를 읽거나 외부 네트워크로 데이터 전송을 시도하는 상황을 생각할 수 있습니다. 이 경우 실행 직전의 권한판정만으로는 충분하지 않을 수 있습니다. 도구가 실제로 접근한 파일 경로·네트워크 목적지·데이터 흐름을 별도로 제한하고 기록해야 하기 때문입니다.
IBM의 발명은 Daon처럼 특정 사람에게 결속된 위임 증표를 만든다는 것 자체보다, 허용된 도구가 런타임에서 어떻게 작동하는지에 초점을 둡니다. 명세서의 sandbox·sidecar·컨테이너 실시예를 전부 독립항 제1항의 필수 구성으로 간주하지 않는 것도 중요합니다. 이 문헌은 공개출원 A1이며, 이후 심사결과에 따른 등록청구항의 권리범위와 동일하지 않을 수 있습니다.

4. 고위험 행동에서는 사용자의 ‘추가승인’이 별도의 기술구성이 됩니다
AI 에이전트가 웹에서 상품을 조회하거나 계약서를 읽을 때와, 실제로 결제를 실행하거나 비밀파일을 외부로 보내는 때는 필요한 통제가 다를 수 있습니다. 미국 공개출원 US20260067335A1(2026년 3월 5일 공개)의 독립 방법청구항 제1항은 AI 브라우저의 제안행동을 정책규칙 또는 LLM 관련 값으로 안전·위험 행동으로 분류하고, 위험행동이면 추가 인증(step-up authentication)을 개시하며, 행위 요약과 필요한 권한(capabilities)을 승인용으로 표시하고, 사용자가 정한 지출·범위 한도를 강제하는 구조입니다.
종속 제2항에는 자금이체·인증정보 사용·기밀파일 공개 등 위험행동과 패스키·생체인증·일회용코드 같은 추가 인증방식을, 종속 제3항에는 드라이런 시뮬레이션과 정책위반 시 실행 차단을 구체화합니다. 특히 종속 제4항은 신뢰할 수 없는 웹콘텐츠와 승인된 지시를 분리하고, 프롬프트 인젝션을 탐지·정제한 뒤, capability broker 및 민감행위의 human-in-the-loop 통제를 수행하는 더 긴 처리체계를 추가합니다.
즉 프롬프트 인젝션의 탐지·문맥 정제·capability broker의 모든 세부단계를 독립 제1항이 이미 필수로 요구한다고 판단해서는 안 됩니다. 동시에 이 출원은 공개청구항 자체에 독립항과 종속항의 구분이 존재한다는 사실을 보여줍니다. 출원 명세서 전체의 광범위한 설명과 현재 청구항의 보호 대상을 나누어 읽어야 합니다.

5. 실제 업무에서는 승인된 요청과 실행 중 데이터 경로를 따로 기록합니다
다음 사례는 개념을 설명하기 위한 가상 기업 업무입니다. 계약 검토를 위임받은 에이전트가 거래처의 웹페이지를 읽고 계약서를 편집한 다음, 사용자 승인 없이 외부 이메일로 초안을 보내려는 상황을 가정합니다.

계약문서 읽기요청에 포함된 프로젝트의 읽기 전용 접근을 위임 증표에 허용합니다. 실행환경은 지정한 문서 경로만 읽었는지 감시합니다.
계약서 수정수정 가능한 지정 문서에만 쓰기 권한을 허용하고, 변경 전후 문서버전과 실행 도구를 로그로 연결합니다.
외부 이메일 전송외부 웹페이지의 내용이 전송을 지시했다면 사용자 원래 목적과 구분합니다. 외부전송 범위에 부합하지 않으면 차단하고, 필요한 경우 별도 사용자승인을 요구합니다.
승인 뒤의 실제 실행승인된 수신자·첨부파일·시간·민감정보 범위만 수행되었는지 독립적으로 검증합니다. 승인 사실만으로 이후 모든 전송을 허용하지 않습니다.
그림 2. INTLAW 업무 시나리오별 기술 검증도. 이는 원문 독해를 토대로 구성한 실무 분석 예제이며, 특정 특허의 실제 시험이나 INTLAW 고객사 수행사례를 나타내지는 않습니다.
이처럼 사용자에게 위임받은 권한의 객체와 도구가 실제 접근한 자원, 고위험 행동에 대한 승인 이벤트를 분리해 기록하면 사고 분석뿐 아니라 새로운 기술의 발명 단위를 식별하는 데 도움이 됩니다. 반대로 “에이전트가 안전하게 실행한다”는 문장만으로는 선행기술과 무엇이 다른지 판단하기 어렵습니다.

6. Daon의 위험점수 예시는 청구항의 필수 공식이 아닙니다
Daon 명세서에는 fidelity(F), integrity(I), 맥락 위험도(C)를 가중결합하는 실시예가 나옵니다. 이를 단순화하여 가중치 wf=0.4, wi=0.4, wc=0.2, F=0.9, I=0.8, C=0.5로 설정하면 다음과 같습니다.
R = 0.4×(1−0.9) + 0.4×(1−0.8) + 0.2×0.5 = 0.22
예를 들어 허용 한계치를 0.20으로 정한 정책이라면 계산된 위험점수 0.22는 허용범위를 넘어섭니다. 그러나 위 계수·임계값은 설명용 설정으로, 실제 등록 제1항이 이 숫자를 직접 필수요건으로 정한다는 뜻이 아닙니다. 위임 증표가 생성되는 과정에 영향을 주는 위험판정의 한 예시일 뿐, 계산값 하나로 특정 서비스의 안전성을 증명할 수도 없습니다.
실무적으로는 가중치보다 더 중요

AI·소프트웨어,AI에이전트,권한위임,샌드박스,프롬프트인젝션,보안특허