에이전트 링크 클릭, 유출·인젝션 방어
에이전트가 링크를 열 때 URL 유출·프롬프트 인젝션을 줄이는 지침 계층·URL 제약·샌드박스를 정리.
세 줄 요약
- 무슨 변화/핵심이슈인가? 에이전트가 외부 링크를 여는 과정에서 URL 기반 데이터 유출과 (간접) 프롬프트 인젝션이 실제 공격면으로 다뤄지며, Instruction Hierarchy·URL 제약·샌드박싱을 묶는 설계가 강조됐다.
- 왜 중요한가? 공개 자료에서는 완화 적용 시 취약성 지표가 62% → 23%, 공격 성공률이 **73.2% → 8.7%**로 낮아지고 **기준 작업 성능 94.3%**를 유지했다는 결과가 보고돼, 보안과 성능을 함께 보려는 논의가 가능해졌다.
- 독자는 뭘 하면 되나? 링크 열기 경로를 목적·도메인·출력(전송)으로 쪼개고, 네트워크 허용 목록 + 샌드박스 + 지침 계층을 한 세트로 점검·실험·로그화하는 규칙을 업무 흐름에 넣어야 한다.
브라우저 탭 하나가 에이전트에게 “작업 버튼”처럼 처리되는 순간, 그 탭은 데이터 유출 경로가 될 수 있다. 링크 클릭은 단순한 탐색이 아니다. 외부 텍스트가 모델의 행동을 바꾸는 통로(프롬프트 인젝션)와, URL이 데이터 운반 경로가 되는 접점(유출)을 동시에 연다. OpenAI는 “에이전트가 링크를 열 때 사용자 데이터를 지키는 방법”을 주제로 URL 기반 데이터 유출과 프롬프트 인젝션을 줄이기 위한 내장 가드레일을 설명했다. 에이전트가 제품 UI의 전면으로 이동하는 흐름에서, ‘클릭’은 보안 설계의 핵심 이벤트로 취급될 가능성이 커졌다.
예: 에이전트가 웹에서 문서를 찾다가, 페이지 안의 문장을 사용자의 요청으로 오해한다. 그 결과 사용자가 의도하지 않은 설정 변경이나 전송 단계로 넘어가는 장면을 상상해 보자. 링크 한 번이 ‘정보 수집’에서 ‘행동 변경’으로 넘어가는 경계가 된다.
- 무슨 변화/핵심이슈인가? 에이전트가 외부 링크를 열 때 생기는 URL 기반 데이터 유출과 (간접) 프롬프트 인젝션을 줄이기 위해, 지침 우선순위(Instruction Hierarchy)·URL 제약·샌드박싱을 조합하는 설계가 더 많이 언급된다.
- 왜 중요한가? 프롬프트 인젝션 완화가 없을 때 대비해 완화 적용 시 취약성 62% → 23%(Operator System Card), 연구 프레임워크에서 공격 성공률 **73.2% → 8.7%**로 낮추면서 **기준 작업 성능의 94.3%**를 유지했다는 보고는, “에이전트 보안은 성능을 희생한다”는 주장에 반례가 될 수 있다(평가 조건은 확인 필요).
- 독자는 뭘 하면 되나? 링크를 여는 경로를 “허용된 목적·허용된 도메인·허용된 출력(전송)”으로 분해하고, 네트워크 허용 목록 + 샌드박스 + 지침 계층을 함께 점검·실험·로그화하는 운영 규칙을 적용하라.
현황
링크를 여는 에이전트가 늘수록, 외부 웹 콘텐츠가 신뢰할 수 없는 입력으로 들어오는 빈도도 함께 늘어난다. OpenAI의 글(발췌)은 이를 전제로, AI 에이전트가 링크를 열 때 사용자 데이터 보호를 목표로 “URL 기반 데이터 탈취”와 “프롬프트 인젝션”을 줄이기 위한 내장 보호장치를 운용한다고 설명한다. 발췌문은 구현의 전부를 공개하지는 않는다. 다만 핵심은 외부 콘텐츠를 신뢰하지 않고, 링크 클릭으로 모델이 규칙을 바꾸거나 데이터를 실어 나르기 어렵게 만드는 방향으로 읽힌다.
조사 결과(출처 포함)에서 더 구체적으로 확인되는 축은 두 가지다.
첫째, OpenAI는 프롬프트 인젝션 대응 연구로 **Instruction Hierarchy(명령 계층 구조)**를 개발했다고 밝힌다(2025-11-07). 요지는 ‘시스템 지침처럼 신뢰할 수 있는 지침’과 ‘외부 콘텐츠처럼 신뢰할 수 없는 지침’을 구분하고, 우선순위를 세워 모델이 외부 텍스트에 끌려가지 않게 하는 접근이다.
둘째, 개발자 문서에서는 Codex가 OS가 강제하는 샌드박스에서 동작하며, 샌드박스가 파일/네트워크 등 “기술적으로 무엇을 만질 수 있는지”를 제한한다고 설명한다. 즉, 모델이 잘못 유도되더라도 실행 가능한 행동의 폭을 줄이는 방식이다.
성과를 둘러싼 수치도 일부는 문서/연구에서 직접 확인된다. Operator System Card는 완화책이 없을 때 62%, 최종 모델에서 **23%**의 “susceptibility”를 보고한다. 또 별도의 연구(2025-11 arXiv)에서는 결합 프레임워크가 공격 성공률을 **73.2% → 8.7%**로 낮추면서 **기준 작업 성능 94.3%**를 유지했다고 제시한다. 다만 이 수치들은 서로 다른 평가 조건일 수 있다. 특정 제품/환경에 그대로 대입하면 해석이 과해질 수 있어, 적용 전 확인이 필요하다.
경쟁 구도에서 OpenAI 방식의 포인트는 “브라우징/도구 호출 같은 에이전트 행위”를 행동 지침과 리스크 평가 프레임으로 관리하려는 흐름으로 요약된다. OpenAI는 Preparedness Framework 업데이트를 2025-04-15에 공개하며 고도 능력이 낳는 리스크를 추적·대비한다고 밝혔다. 비교 대상으로는 (조사 결과 기준) Anthropic이 MCP로 “프로토콜 수준의 연결”에 더 집중한다는 관측이 있고, Microsoft·Google은 클라우드 보안·컴플라이언스 도구를 활용하는 경향이라는 요약이 붙는다. 다만 구체 수치로의 비교는 확인되지 않았다.
분석
에이전트 링크 보안의 핵심은 LLM을 “텍스트 엔진”으로만 볼지, “권한을 가진 자동화 주체”로 볼지의 차이에서 시작한다. 링크 클릭을 허용하면 외부 페이지는 참고자료가 아니라 명령 전달 채널이 될 수 있다. 이때 Instruction Hierarchy 같은 우선순위 기반 규칙은 “무엇을 신뢰할 것인가”를 다룬다. 샌드박스/네트워크 제어는 “신뢰할 수 없을 때도 무엇을 못 하게 할 것인가”를 다룬다.
둘을 함께 쓰는 이유는 분리돼 있다. 규칙만 있으면 도구 호출·파일 쓰기·네트워크 같은 탈출구가 남을 수 있다. 격리만 있으면 모델이 여전히 잘못된 결론을 내리거나 부적절한 행동을 선택할 수 있다. Operator System Card에서 완화 후에도 **23%**가 남았다는 보고는, ‘모델 개선’만으로 끝나기 어렵고 운영 설계가 필요하다는 신호로 해석할 여지가 있다.
트레이드오프도 정리해 둘 필요가 있다.
(1) 기능성 vs. 차단 강도: 도메인 허용 목록을 촘촘히 만들수록 위험은 줄지만, 에이전트의 탐색/해결 범위도 함께 줄 수 있다.
(2) 관찰 가능성 vs. 프라이버시/비용: 인젝션 감지·감사를 위해 로그를 남기면 대응에는 유리하다. 대신 저장 데이터 범위와 운영 비용이 커질 수 있다.
(3) 정책(지침) vs. 기술(격리): Instruction Hierarchy는 유효한 방향으로 제시되지만, 외부 콘텐츠가 지침처럼 위장하는 패턴은 바뀔 수 있다. 따라서 단일 통제에 의존하기는 어렵다.
실전 적용
개발자 관점에서 링크 접근 보안은 “브라우저를 안전하게 만든다”보다 “에이전트의 행동 표면을 좁힌다”에 가깝다. 외부 페이지를 모델 입력으로 넣는 순간 텍스트 자체가 공격면이 된다. 따라서 (a) 지침 우선순위를 명시하고, (b) 도구 호출과 네트워크를 샌드박스에서 제약하며, (c) URL이 데이터 운반 경로로 쓰이지 않도록 제한하는 3단 조합이 기본 골격이 된다. 개발자 문서가 설명하는 “OS-강제 샌드박스”처럼, 모델이 닿을 수 있는 영역을 기술적으로 줄이는 접근은 운영 측면에서 예측 가능성을 높일 수 있다.
사용자/운영자 관점에서는 “에이전트가 링크를 열 때 무엇을 해도 되는가”를 업무별로 분리하는 편이 낫다. 예를 들어 ‘읽기 전용 조사’와 ‘업데이트/구매/설정 변경’은 위험도가 다르다. 전자는 허용 목록을 상대적으로 넓히되 데이터 반출을 막는 쪽이 맞을 수 있다. 후자는 허용 목록을 좁히고 사람 승인 단계를 두는 쪽이 관리하기 쉽다. Operator System Card 및 연구 결과의 수치(예: 62% → 23%, 73.2% → 8.7%, 94.3%)는 완화 여지가 있음을 시사한다. 동시에 잔여 위험을 운영 설계(권한, 승인, 감사)로 흡수해야 한다는 해석도 가능하다.
오늘 바로 할 일:
- 링크 열기 기능을 “읽기/요약”과 “행동(전송·설정 변경 등)”으로 분리하고, 행동 경로에는 승인 단계를 둔다.
- 네트워크는 도메인 허용 목록을 기본값으로 두고, 예외 추가는 리뷰 절차를 거치게 한다.
- 지침 계층(신뢰/비신뢰)을 프롬프트·툴 라우팅·정책 코드에 명시하고, 위반 징후를 로그로 남겨 점검한다.
FAQ
Q1. 프롬프트 인젝션은 결국 “모델이 속는 문제”인데, 기술로 완전히 막을 수 있나?
A. 공개된 자료만 기준으로는 “완화는 가능하지만 잔여 위험이 남는다”에 가깝다. Operator System Card는 완화 후에도 23% susceptibility를 보고한다. 목표를 ‘제로’로 단정하기보다, 잔여 위험을 전제로 승인·권한·감사(로그) 설계를 두는 편이 현실적이다.
Q2. Instruction Hierarchy는 기존의 “시스템 프롬프트를 강하게”와 뭐가 다른가?
A. OpenAI가 2025-11-07에 말한 바는 모델이 “신뢰된 지침 vs. 신뢰되지 않은 지침”을 구분하도록 연구한다는 점이다. 단순히 문구를 강하게 쓰는 방식이라기보다, 외부 웹 콘텐츠 같은 입력을 구조적으로 낮은 우선순위로 취급하게 만드는 프레임에 가깝다(구체 구현은 추가 확인 필요).
Q3. 샌드박스만 쓰면 링크 보안은 충분한가?
A. 충분하다고 단정하기 어렵다. 샌드박스는 “기술적으로 할 수 있는 것”을 줄인다. 그러나 모델이 잘못된 지시를 따라 부적절한 결정을 내릴 위험은 남을 수 있다. 공개 문서가 말하는 OS-강제 샌드박스는 하단 안전장치로 유용할 수 있지만, 상단의 지침 우선순위·콘텐츠 처리 규칙과 함께 설계하는 편이 안전하다.
결론
에이전트가 링크를 클릭하는 순간, 웹은 검색 공간을 넘어 규칙이 주입될 수 있는 인터페이스가 된다. Instruction Hierarchy 같은 우선순위 설계, OS-강제 샌드박스 같은 격리, URL을 데이터 운반 경로로 쓰기 어렵게 하는 제약을 한 묶음으로 적용하는 접근이 제시되고 있다. 다음 관전 포인트는 이런 가드레일이 어느 수준까지 표준화되어 개발자 기본값으로 제공되는지다.
다음으로 읽기
- AI 자료 모음 (24h) - 2026-02-12
- AI 자료 모음 (6h) - 2026-02-11
- AI 자료 모음 (24h) - 2026-02-10
- AI를 활용한 고도화된 리팩토링과 코드 무결성 확보
- AI 코딩 비서와 보안: 1인 개발 리스크 관리
참고 자료
업데이트 받기
주간 요약과 중요한 업데이트만 모아서 보내드려요.
오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.