기술 요약: 웹 에이전트는 계획 후 실행 (Plan-Then-Execute) 패러다임을 채택해야 합니다

문제 제기

이 논문은 대형 언어 모델 (LLM) 웹 에이전트의 현재 기본 아키텍처인 ReAct(Reasoning-and-Acting, 추론 및 행동) 가 웹 환경에서 근본적으로 보안이 취약하고 비효율적이라고 주장합니다.

핵심 취약점:
ReAct 루프에서 에이전트는 환경 (웹페이지) 을 관찰하고, 다음 행동을 위해 LLM 에 쿼리를 보낸 후 이를 실행합니다. 웹 콘텐츠는 본질적으로 신뢰할 수 있는 인터페이스 요소와 제 3 자의 신뢰할 수 없는 데이터 (예: 사용자 리뷰, 광고, 포럼 게시물, 스폰서 콘텐츠) 가 혼합된 형태입니다. ReAct 루프가 관찰과 행동 선택을 교차시키기 때문에, 신뢰할 수 없는 콘텐츠는 모델이 다음 제어 흐름 단계를 결정하는 순간 모델에 제시됩니다. 이는 공격자가 데이터 값에 영향을 미치는 것을 넘어 에이전트의 제어 흐름을 조작할 수 있는 간접 프롬프트 인젝션 공격에 대한 직접적인 경로를 만듭니다 (예: 데이터 유출이나 금융 이체와 같은 무단 행위를 수행하도록 에이전트를 장악).

2 차적 문제:

• 비효율성: ReAct 에이전트는 "근시안적"으로, 현재 상태에 기반하여 매 단계마다 재계획을 수립합니다. 이는 에이전트가 종종 정적이고 반복 가능한 워크플로우를 반복적으로 재발견함에 따라 토큰 사용량, 지연 시간 및 비용이 증가하게 만듭니다.
• 재현성: ReAct 의 동적 특성으로 인해 제어 흐름이 고정된 계획이 아닌 런타임 관찰에 의해 결정되므로, 에이전트 행동의 디버깅 및 검증이 어렵습니다.

방법론: 계획 후 실행 (Plan-Then-Execute, PTE)

저자들은 **계획 후 실행 (PTE)**을 안전한 대안 아키텍처로 제안합니다. PTE 에서 에이전트는 런타임 웹 콘텐츠를 관찰하기 전에 작업별 프로그램에 합의합니다.

주요 아키텍처 구성 요소:

1. 신뢰할 수 있는 API 인터페이스: 에이전트는 원시 DOM 요소나 스크린샷과 상호작용하는 대신 신뢰할 수 있는 API(웹사이트에서 제공하거나 클라이언트 측 SDK 로 구축된) 와 상호작용합니다. 이 API 는 알려진 입력/출력 스키마를 가진 타입 지정 함수 (예: search(query), add_to_cart(sku)) 를 노출합니다.
2. 계획 단계: LLM 플래너는 사용자의 목표와 신뢰할 수 있는 API 정의에 기반하여 결정론적 프로그램 (계획) 을 생성합니다. 중요한 점은 플래너가 런타임 웹 콘텐츠를 받지 않는다는 것입니다. 제어 흐름 그래프는 이 단계에서 고정됩니다.
3. 실행 단계: 실행기는 사전에 합의된 프로그램을 실행합니다. 런타임 웹 콘텐츠는 매개변수를 채우거나, 분기 결과를 결정하거나, 미리 정의된 실행 그래프 내에서 데이터 값에 영향을 주는 데에만 사용됩니다.
4. LLM 서브루틴: 유용성을 유지하기 위해 프레임워크는 고정된 계획 내에서 로컬 데이터 처리 (예: 추출, 분류, 요약) 를 위해 LLM 서브루틴의 사용을 허용합니다. 그러나 이러한 서브루틴은 엄격하게 제한됩니다: 새로운 코드를 생성하거나, 새로운 도구를 선택하거나, 제어 흐름을 변경할 수 없습니다. 이들의 출력은 타입이 지정되어 지시문이 아닌 데이터로 처리됩니다.

보안 보장:
PTE 는 제어 흐름(계획 단계에서 결정됨) 과 데이터 흐름(실행 단계에서 결정됨) 을 엄격하게 분리합니다. 신뢰할 수 없는 웹 콘텐츠는 값(예: 리뷰에 기반하여 선택된 제품) 에 영향을 줄 수는 있지만, 작업을 재정의하거나 모델이 런타임에 새로운 행동을 생성하도록 만들 수는 없습니다. 이로써 제어 흐름 장악이 방지됩니다.

주요 기여

1. ReAct 에 대한 아키텍처 비판: 이 논문은 ReAct 의 관찰과 행동 선택의 교차가 웹 에이전트에게 아키텍처적 결함이며, 이를 프롬프트 인젝션에 본질적으로 취약하게 만든다고 규명합니다.
2. 웹 에이전트를 위한 PTE 제안: 저자들은 에이전트가 실행 전에 타입 지정 웹사이트 API 를 통해 프로그램을 작성하는 패러다임 전환을 도입하여, 계획을 신뢰할 수 없는 콘텐츠로부터 격리시킵니다.
3. 작업 분류 및 실증 분석:
   • 저자들은 웹 작업을 세 가지 유형으로 분류합니다: 안전(정적 코드), 영향 하에 안전(데이터 처리를 위한 LLM 서브루틴 필요), 재계획 필요(동적 데이터 기반 계획 필요).
   • 그들은 WebArena 벤치마크 (6 개 시뮬레이션 웹사이트에 걸친 860 개 작업) 를 분석합니다.
   • 결과: WebArena 작업의 100% 가 PTE 와 호환됩니다. 구체적으로 **81.28%**는 순수 프로그래밍식 계획 (런타임 LLM 서브루틴 없음) 으로 완료할 수 있으며, 나머지 18.72% 는 데이터 처리를 위해 LLM 서브루틴이 필요하지만 제어 흐름 장악으로부터 안전합니다. 어떤 작업도 동적 재계획을 요구하지 않았습니다.
4. 인프라 격차 식별: 이 논문은 PTE 채택의 주요 장벽이 모델링 능력이 아닌 인프라라고 강조합니다. 현재 웹 인터페이스 (클릭, 스크롤) 는 의미적으로 타입 지정되어 있지 않습니다. 저자들은 다음 개발을 주장합니다:
   • 타입 지정되고 완전하며 감사 가능한 웹사이트 API(또는 클라이언트 측 SDK).
   • 플래너가 관련 엔드포인트를 찾을 수 있도록 돕는 API 발견 메커니즘.
   • 정적 계획을 위한 강력한 오류 처리 전략(예: 명시적 재시도 로직).

결과 및 발견

• 보안: PTE 는 설계상 모델의 세 번째 위협 범주 (제어 흐름 장악) 를 제거합니다. "영향 하에 안전" 작업은 결과 조작 (예: 적대적 리뷰로 제품 선택 변경) 에 여전히 취약할 수 있지만, 피해는 제한적입니다. 공격자는 에이전트를 관련 없는 파괴적 행위로 전환시킬 수 없습니다.
• 적용 가능성: WebArena 분석은 쇼핑, 포럼 게시, 이슈 추적과 같은 일반적인 웹 작업의 대부분이 사용자 프롬프트만으로 결정될 수 있는 정적 제어 흐름을 가지므로 PTE 에 이상적인 후보임을 보여줍니다.
• 효율성: 한 번 계획하고 고정된 프로그램을 실행함으로써 PTE 는 반복적인 ReAct 루프에 비해 토큰 소비와 지연 시간을 줄입니다. 또한 공통 쿼리에 대한 계획 캐싱을 가능하게 합니다.

중요성과 주장

이 논문은 웹 작업은 기본적으로 반응성이 필요하지 않으며, 타입 지정되고 완전하며 감사 가능한 웹사이트 API 가 필요하다고 주장합니다.

• 책임의 전환: 저자들은 보안 문제가 "모델링 문제"(즉, 더 견고한 모델을 훈련시키는 것) 가 아니라 "인프라 문제"라고 주장합니다. 현재 웹은 안전한 에이전트 실행에 필요한 인터페이스가 부족합니다.
• 연구 의제: 이 논문은 필요한 인프라 구축에 초점을 맞춘 연구 의제를 제시합니다:
  1. 인터페이스: 에이전트 친화적 웹 API 표준화 및 클라이언트 측 SDK 자동 생성.
  2. 플래너 설계: 이러한 신뢰할 수 있는 API 를 사용하여 표현력이 풍부하고 작업별 프로그램을 생성하는 에이전트 개발.
  3. 검증: 생성된 프로그램을 보안 정책에 대해 정적 검사하고 타입 검증을 통해 LLM 서브루틴을 제한.
  4. 평가: 보안, 유용성, 효율성을 동시에 측정하는 벤치마크 개발.

저자들은 ReAct 가 여전히 매우 동적인 웹사이트, 탐색이 많은 작업, 또는 전처리되지 않은 사이트를 아우르는 워크플로우에서는 우월할 수 있지만, 보안과 효율성을 보장하기 위해 웹 에이전트의 기본 아키텍처는 계획 후 실행 (Plan-Then-Execute) 이어야 한다고 결론지었습니다.