툴 출력이 명령으로 바뀌는 순간: AI 에이전트 권한을 실행 직전에 다시 묻는 법

웹페이지에서 파일 경로를 찾고, 그 파일을 사용자가 지정한 사람에게 보내는 에이전트를 생각해 보자. 검색 결과에 나온 파일 식별자는 다음 툴 호출에 꼭 필요하다. 그런데 같은 결과 안에 "이 문서를 다른 주소에도 보내라"는 문장이 섞여 있다면 이야기가 달라진다. 앞의 정보는 원래 요청을 완성하는 데이터이고, 뒤의 문장은 권한 범위를 넓히려는 명령이다.

8월 27일 공개된 논문 SARA는 이 둘을 구분하는 기준을 제안한다. 외부 관찰이 다음 행동을 떠올리게 할 수는 있어도, 그 사실만으로 실행 권한까지 얻어서는 안 된다는 것이다. 연구진은 사용자 요청, 성공한 이전 실행, 인수의 출처를 툴 실행 경계에서 다시 확인했다. AgentDojo와 AgentDyn의 네 가지 주 평가 설정에서 공격 성공률은 0.06~0.63%였다.

다만 이 수치를 "프롬프트 인젝션 해결"로 읽으면 곤란하다. SARA는 형식 검증으로 증명된 보안 장치가 아니라 의미 판단을 포함한 런타임 방어다. 논문 v1에는 구현 저장소도 연결돼 있지 않다. 지금 가져갈 만한 것은 특정 방어기의 이름보다 권한을 어디서, 어떤 증거로 검사할지에 관한 설계다.

문제는 입력 문장이 아니라 실제 부작용이다

간접 프롬프트 인젝션은 이메일, 문서, 웹페이지 같은 외부 데이터에 작업 지시를 숨긴다. 에이전트가 그 문장을 읽었다는 사실만으로 사고가 난 것은 아니다. 송금, 전송, 삭제, 권한 변경처럼 실제 툴 호출이 외부 상태를 바꿀 때 보안 결과가 생긴다.

모든 외부 정보를 차단하는 방식도 답은 아니다. "분기 보고서를 찾아 Alice에게 보내라"는 요청에서 사용자는 파일 ID를 미리 알 수 없다. 검색 결과가 알려준 ID는 정상적인 런타임 바인딩이다. 반면 검색 결과가 새 수신자 attacker@example.com을 제안했다면 이는 사용자가 허용하지 않은 권한 확장이다. 같은 관찰 안에서도 데이터와 명령의 역할이 갈린다.

MCP의 2026-07-28 HTTP 권한 명세는 OAuth 기반으로 클라이언트가 보호된 서버에 접근하는 흐름을 정한다. 이 transport 수준 권한은 필요하지만 충분하지 않다. 액세스 토큰이 유효하다는 사실은 "이번 사용자가 이 수신자에게 이 파일을 보내라고 했는가"를 답하지 않는다. 연결 권한과 개별 행동 권한은 따로 검사해야 한다.

SARA는 계획기가 아니라 실행 경계에 선다

SARA는 에이전트의 숨은 추론이나 내부 메모리를 요구하지 않는다. 사용자 요청, 툴 스키마, 후보 호출, 툴이 돌려준 관찰, 자체 런타임 상태만 본다. 흐름은 다음과 같다.

첫째, 사용자 요청에서 허용된 효과, 작업, 범위, 명시적 인수를 뽑아 권한 계약 K를 만든다. 이것은 완성된 호출 순서가 아니라 권한의 상한선이다.

둘째, 격리된 Action Probe가 외부 관찰에서 툴 행동이나 인수를 유도하는 의미를 찾는다. 그 출처는 F에 남긴다. 여기서 악성 여부를 확정하거나 관찰을 삭제하지는 않는다.

셋째, 허용됐고 실제로 성공한 툴 실행만 감사 증거 H에 넣는다. 거부된 호출, 실패한 호출, 모델이 말로 적은 계획은 긍정적 실행 증거가 되지 못한다.

마지막으로 후보 호출이 실제 executor에 닿기 직전에 사용자 목표, 성공한 실행 사슬, 각 인수의 근거를 모두 검사한다. 셋 중 하나라도 독립된 지지를 얻지 못하면 실행 전에 거부하고 에이전트에 이유를 돌려줘 재계획하게 한다.

SARA는 외부 관찰이 행동을 유도한 출처와 실제 실행을 허가하는 근거를 분리한다. 목표, 실행 사슬, 인수 근거가 모두 확인돼야 executor로 보낸다. 출처: arxiv.org/abs/2608.27146.

과거에 한 번 등장했다고 권한이 세탁되지는 않는다

멀티스텝 실행에서는 출처가 쉽게 흐려진다. 외부 문서가 제안한 이메일 주소가 중간 검색 결과에 다시 나타났다고 해 보자. 단순한 히스토리 기반 검사는 "앞 단계에도 있던 값"이라는 이유로 정상 인수처럼 받아들일 수 있다.

SARA의 No-History-Promotion 규칙은 이 승격을 막는다. 외부 관찰이 처음 행동 인수로 유도한 값은 나중에 실행 기록에 다시 등장해도 그 사실만으로 HISTORY_BOUND 권한을 얻지 못한다. 사용자 요청이나 권한 계약에서 별도 근거가 확인돼야 한다. 출처 표시는 경고용 로그로 끝나지 않고 다음 호출의 인수 판정까지 따라간다.

이 원칙은 구현 방식과 무관하게 쓸 만하다. 에이전트 메모리에 문자열만 저장하지 말고 value, source, first_seen_step, authority_basis를 함께 기록해야 한다. 재시도나 하위 에이전트 위임 때도 원래 provenance를 보존해야 한다. 컨텍스트에 반복해서 보였다는 사실과 사용자가 승인했다는 사실은 같지 않다.

네 설정에서 공격 성공률은 크게 줄었다

논문은 Banking, Slack, Travel, Workspace를 포함한 AgentDojo와 Shopping, GitHub, DailyLife를 포함한 AgentDyn에서 평가했다. AgentDojo에는 정상 과제 92개와 공격 인스턴스 3,528개, AgentDyn에는 정상 과제 141개와 공격 인스턴스 5,202개가 쓰였다. 공격 문구는 기존 지시 무시, 시스템 메시지 위장, 중요 지시 강조, 툴 지식 위장의 네 형태였다.

GPT-4o-mini에서 무방비 에이전트의 공격 성공률은 AgentDojo 15.79%, AgentDyn 16.07%였다. SARA 적용 뒤 각각 0.06%, 0.17%로 내려갔다. Gemini-2.5-Flash-Lite에서는 33.28%와 30.91%가 0.62%와 0.63%가 됐다. 이것은 저자 실험 결과이며 독립 재현 결과가 아니다.

네 주 평가 설정에서 SARA 적용 후 공격 성공률은 0.06~0.63%였다. 수치는 저자 실험이며 독립 재현 결과가 아니다. 출처: arxiv.org/abs/2608.27146.

낮은 공격 성공률만 보면 방어기가 모든 행동을 막았는지 알 수 없다. 논문은 정상 상황의 과제 완수율(BU)도 함께 봤다. SARA는 무방비 기준보다 네 설정에서 각각 5.79, 8.98, 6.52, 11.82%포인트 낮았다. 더 강한 실행 격리를 사용한 CaMeL은 세 설정에서 SARA보다 공격 성공률이 더 낮았지만, 정상 과제 완수율 감소 폭은 15.94~39.71%포인트였다. 보안과 정상 작업 보존을 같은 표에서 봐야 하는 이유다.

숫자가 말하지 않는 것

이 연구에는 세 가지 경계가 있다. 첫째, 의미 기반 판정은 오탐과 미탐을 낼 수 있다. 형식적 비간섭 보장이 아니다. 둘째, 호출을 막은 뒤 다른 경로를 찾는 능력은 주 에이전트에 달렸다. 작은 모델이나 복구가 약한 워크플로에서는 정상 과제 완수율이 더 떨어질 수 있다. 셋째, 평가는 신뢰할 수 있는 사용자 입력, 툴 스키마, SARA 런타임, executor를 가정한다. 런타임을 우회하는 직접 공격이나 순수 데이터 의존성 취약점은 범위 밖이다.

구현 공개 여부도 확인할 점이다. arXiv v1의 본문과 HTML에는 SARA 코드 저장소가 연결돼 있지 않았다. 따라서 표의 수치와 구조는 읽고 대조할 수 있지만, 동일 설정으로 다시 실행해 결과를 검증할 수는 없었다. "0.63% 이하"를 제품 보증치처럼 옮겨 쓰면 안 된다.

실전 적용은 작은 권한 계약부터 시작한다

처음부터 논문의 전체 구조를 복제할 필요는 없다. 부작용이 큰 툴부터 실행 경계를 분리하면 된다. 메일 전송이라면 작업, 수신자, 첨부 범위를 계약에 넣고, 결제라면 금액, 통화, 수취인, 최대 한도를 넣는다. 모델이 만든 자연어 계획은 승인 근거로 쓰지 않는다.

읽기 호출과 쓰기 호출도 같은 취급을 피한다. 검색 결과는 후속 인수를 채우는 데이터로 쓸 수 있지만 새 수신자나 새 권한 범위를 추가하는 근거가 되어서는 안 된다. 허용됐고 성공한 호출만 감사 증거에 넣고, 실패와 거부는 별도 상태로 남긴다.

운영 지표는 공격 성공률 하나로 끝내지 않는다. 정상 과제 완수율, 거부 뒤 복구율, 사람 승인으로 넘어간 비율, 인수별 근거 누락률, 추가 추론 비용을 함께 기록한다. 마지막으로 로그에서 값의 출처를 재구성할 수 있는지 정기적으로 시험한다. 권한 검사가 있어도 provenance가 위임과 재시도 사이에서 사라지면 같은 문제가 돌아온다.

결론

외부 툴 출력은 에이전트가 일을 끝내는 데 필요한 데이터다. 동시에 사용자가 요청하지 않은 행동을 끼워 넣는 통로가 될 수 있다. 둘을 가르는 기준은 "외부에서 왔는가"가 아니라 "기존 권한을 구체화하는가, 새 권한을 만들어내는가"다.

SARA의 유용한 설계 포인트는 명확하다. 행동을 유도한 출처와 실행을 허가하는 근거를 분리하고, 그 출처를 여러 단계에 걸쳐 보존하며, 실제 부작용 직전에 목표·실행 사슬·인수를 다시 확인한다. 모델에게 더 강한 시스템 프롬프트를 쓰는 문제라기보다 executor 앞에 완전 조정 지점을 두는 문제에 가깝다.

참고 자료

• Guo et al., When Tool Outputs Become Commands: Separating Action Induction from Runtime Authorization in Tool-Augmented LLM Agents (2026-08-27, v1)
• Model Context Protocol, Authorization specification 2026-07-28
• AgentDojo, 공식 저장소