서드파티 포털에 대한 UI 의존 자동화

모든 기업에는 자동화되어야 하지만 그렇지 않은 작업을 위해 직원들이 매일 수동으로 로그인하는 포털 목록이 있습니다. 주문 상태를 확인하는 벤더 포털. 규제 제출을 위한 정부 사이트. 자격 확인 및 청구 상태 확인을 위한 보험 페이어 포털. 자격 증명 확인을 위한 주 면허 위원회. 규정 준수 신고를 위한 세무 당국 포털.

이러한 포털에는 API가 없습니다. 아니면 문서화되지 않거나, 속도 제한이 있거나, 접근 비용을 지불하는 "우선 파트너"에게만 제한된 API가 있습니다. 데이터는 로그인 페이지 뒤에 HTML로 렌더링되어 있으며, 이를 꺼내는 유일한 방법은 로그인하여 UI를 탐색하는 것입니다.

기존 자동화는 브라우저 스크립트를 사용합니다. 로그인하고, 올바른 페이지로 탐색하고, CSS 셀렉터나 XPath로 요소를 찾고, 데이터를 추출하고, 로그아웃하는 Selenium, Playwright 또는 Puppeteer 스크립트. 이 스크립트들은 망가질 때까지 작동합니다. 포털 재설계로 CSS 클래스 이름이 변경됩니다. 로그인 흐름에 새로운 CAPTCHA가 추가됩니다. 탐색 메뉴가 사이드바에서 햄버거 메뉴로 이동합니다. 쿠키 동의 배너가 제출 버튼을 덮기 시작합니다. 스크립트는 조용히 망가지고, 데이터에 의존하는 다운스트림 프로세스가 오류를 내기 시작할 때까지 아무도 모릅니다.

주 의료 위원회는 특히 가혹한 예입니다. 50개가 있으며, 각각 다른 웹사이트, 다른 레이아웃, 다른 인증 방법, 다른 데이터 형식을 가지고 있습니다. 사전 통지 없이 자체 일정에 따라 재설계합니다. 이러한 사이트 스크래핑에 의존하는 자격 증명 확인 서비스는 언제든지 50개 스크립트 중 5~10개가 망가져 있으며, 각각 개발자가 새로운 레이아웃을 검사하고 셀렉터를 다시 작성해야 합니다.

Triggerfish의 해결 방법

Triggerfish의 브라우저 자동화는 CDP 제어 Chromium과 LLM 기반 시각적 탐색을 결합합니다. 에이전트는 DOM 트리가 아닌 렌더링된 픽셀과 접근성 스냅샷으로 페이지를 봅니다. CSS 클래스 이름이 아닌 보이는 것과 하는 것으로 요소를 식별합니다. 포털이 재설계될 때, 로그인 폼은 여전히 로그인 폼처럼 보이고, 탐색 메뉴는 여전히 탐색 메뉴처럼 보이고, 데이터 테이블은 여전히 데이터 테이블처럼 보이기 때문에 에이전트가 적응합니다.

셀렉터 스크립트 대신 시각적 탐색

브라우저 자동화 도구는 navigate, snapshot, click, type, select, scroll, wait의 7가지 작업으로 작동합니다. 에이전트는 URL로 탐색하고, 렌더링된 페이지의 스냅샷을 찍고, 보이는 것에 대해 추론하고, 취할 행동을 결정합니다. 페이지 컨텍스트에서 임의의 JavaScript를 실행하는 evaluate 도구가 없습니다. 이것은 의도적인 보안 결정입니다. 에이전트는 UI를 통해, 인간이 하는 것처럼 페이지와 상호작용하며, 악의적인 페이지가 악용할 수 있는 코드를 실행할 수 없습니다.

에이전트가 로그인 폼을 만나면, 시각적 레이아웃, 플레이스홀더 텍스트, 레이블, 페이지 구조를 기반으로 사용자 이름 필드, 비밀번호 필드, 제출 버튼을 식별합니다. 사용자 이름 필드가 id="auth-input-email" 또는 class="login-form__email-field"를 가질 필요가 없습니다. 재설계에서 해당 식별자가 변경되어도 에이전트는 그것들에 의존하지 않았기 때문에 알아채지 못합니다.

공유 도메인 보안

브라우저 탐색은 웹 페치 작업과 동일한 도메인 보안 구성을 공유합니다. triggerfish.yaml의 단일 설정 블록이 SSRF 거부 목록, 도메인 허용 목록, 도메인 거부 목록, 도메인-분류 매핑을 정의합니다. 에이전트가 CONFIDENTIAL로 분류된 벤더 포털로 탐색하면, 세션 taint는 자동으로 CONFIDENTIAL로 에스컬레이션되고, 해당 워크플로의 모든 후속 행동은 CONFIDENTIAL 수준 제한을 받습니다.

SSRF 거부 목록은 하드코딩되어 있으며 재정의할 수 없습니다. 프라이빗 IP 범위, 링크 로컬 주소, 클라우드 메타데이터 엔드포인트는 항상 차단됩니다. DNS 해석은 요청 전에 확인되어 DNS 리바인딩 공격을 방지합니다. 이것은 브라우저 자동화가 에이전트 시스템에서 가장 높은 위험 공격 표면이기 때문에 중요합니다. 에이전트를 내부 서비스로 리디렉션하려는 악의적인 페이지는 요청이 시스템을 떠나기 전에 차단됩니다.

브라우저 프로필 워터마킹

각 에이전트는 고유한 브라우저 프로필을 유지하며, 시간이 지나면서 포털과의 상호작용에서 쿠키, 로컬 스토리지, 세션 데이터를 축적합니다. 프로필에는 사용된 가장 높은 분류 레벨을 기록하는 분류 워터마크가 있습니다. 이 워터마크는 에스컬레이션만 가능하며, 감소하지 않습니다.

에이전트가 브라우저 프로필을 사용하여 CONFIDENTIAL 벤더 포털에 로그인하면, 프로필은 CONFIDENTIAL로 워터마킹됩니다. PUBLIC 분류로 실행되는 후속 세션은 해당 프로필을 사용할 수 없으며, 민감한 정보를 포함할 수 있는 캐시된 자격 증명, 쿠키 또는 세션 토큰을 통한 데이터 누출을 방지합니다. 프로필 격리는 에이전트별이며, 워터마크 적용은 자동입니다.

이것은 포털 자동화에서 미묘하지만 중요한 문제를 해결합니다. 브라우저 프로필은 접근한 데이터를 반영하는 상태를 축적합니다. 워터마킹 없이는 민감한 포털에 로그인한 프로필이 자동 완성 제안, 캐시된 페이지 데이터, 또는 지속적인 쿠키를 통해 더 낮은 분류 세션에 정보를 누출할 수 있습니다.

자격 증명 관리

포털 자격 증명은 OS 키체인(개인 티어) 또는 엔터프라이즈 볼트(엔터프라이즈 티어)에 저장되며, 구성 파일이나 환경 변수에는 저장되지 않습니다. SECRET_ACCESS 훅은 모든 자격 증명 검색을 기록합니다. 자격 증명은 워크플로 엔진에 의해 실행 시점에 해석되어 폼 값을 프로그래밍 방식으로 설정하지 않고 타이핑 인터페이스를 통해 브라우저 세션에 주입됩니다. 이는 자격 증명이 다른 모든 민감한 작업과 동일한 보안 레이어를 통해 흐른다는 것을 의미합니다.

일반적인 포털 변경에 대한 탄력성

일반적인 포털 변경이 발생할 때 일어나는 일:

로그인 페이지 재설계. 에이전트는 새 스냅샷을 찍고, 업데이트된 레이아웃을 식별하고, 시각적 컨텍스트로 폼 필드를 찾습니다. 포털이 완전히 다른 인증 방법(SAML, OAuth, 하드웨어 토큰)으로 전환하지 않는 한, 구성 변경 없이 로그인이 계속 작동합니다.

탐색 재구성. 에이전트는 로그인 후 페이지를 읽고 URL 패턴이 아닌 링크 텍스트, 메뉴 레이블, 페이지 제목을 기반으로 대상 섹션으로 탐색합니다. 벤더 포털이 "주문 상태"를 왼쪽 사이드바에서 상단 탐색 드롭다운으로 이동했다면, 에이전트는 거기서 찾습니다.

새로운 쿠키 동의 배너. 에이전트는 배너를 보고, 수락/거부 버튼을 식별하고, 클릭한 후 원래 작업을 계속합니다. 이것은 특별한 목적의 쿠키 핸들러가 아닌 LLM의 일반적인 페이지 이해로 처리됩니다.

CAPTCHA 추가. 이것은 접근 방식의 솔직한 한계가 있는 부분입니다. 단순 이미지 CAPTCHA는 LLM의 비전 능력에 따라 해결 가능할 수 있지만, reCAPTCHA v3 및 유사한 행동 분석 시스템은 자동화된 브라우저를 차단할 수 있습니다. 워크플로는 조용히 실패하는 대신 이것들을 인간 개입 대기열로 라우팅합니다.

다단계 인증 프롬프트. 포털이 이전에 필요하지 않았던 MFA를 요구하기 시작하면, 에이전트는 예상치 못한 페이지를 감지하고, 알림 시스템을 통해 상황을 보고하고, 인간이 MFA 단계를 완료할 때까지 워크플로를 일시 중지합니다. 워크플로는 MFA 완료를 기다렸다가 중단된 곳에서 재개하도록 구성할 수 있습니다.

여러 포털에 걸친 배치 처리

워크플로 엔진의 for 루프 지원으로 단일 워크플로가 여러 포털 대상을 반복할 수 있습니다. 자격 증명 확인 서비스는 단일 배치 실행에서 모든 50개 주 의료 위원회의 면허 상태를 확인하는 워크플로를 정의할 수 있습니다. 각 포털 상호작용은 고유한 브라우저 세션, 고유한 분류 추적, 고유한 오류 처리를 가진 별도의 하위 단계로 실행됩니다. 50개 중 3개의 포털이 실패하면, 워크플로는 나머지 47개를 완료하고 포털별 상세한 오류 컨텍스트와 함께 3개의 실패를 검토 대기열로 라우팅합니다.

실제 활용 사례

자격 증명 인증 기관이 제공자 등록 프로세스의 일환으로 주 의료 위원회에 걸쳐 의료 제공자 면허를 확인합니다. 전통적으로 확인 보조원들이 각 위원회 웹사이트에 수동으로 로그인하고, 제공자를 검색하고, 면허 상태의 스크린샷을 찍고, 자격 증명 시스템에 데이터를 입력합니다. 각 확인에는 5~15분이 걸리며, 조직은 주당 수백 건을 처리합니다.

Triggerfish로 워크플로가 전체 확인 사이클을 처리합니다. 워크플로는 면허 번호와 대상 주가 있는 제공자 배치를 받습니다. 각 제공자에 대해, 브라우저 자동화가 관련 주 위원회 포털로 탐색하고, 저장된 자격 증명으로 로그인하고, 제공자를 검색하고, 면허 상태와 만료 날짜를 추출하고, 결과를 저장합니다. 추출된 데이터는 제공자 PII를 포함하기 때문에 CONFIDENTIAL로 분류되고, 쓰기 다운 규칙은 해당 분류 레벨 이하의 채널로 전송되지 않도록 방지합니다.

주 위원회가 포털을 재설계하면, 에이전트는 다음 확인 시도에서 적응합니다. 위원회가 자동화된 접근을 차단하는 CAPTCHA를 추가하면, 워크플로는 해당 주를 수동 확인을 위해 플래그하고 배치의 나머지를 처리합니다. 확인 보조원들은 모든 확인을 수동으로 하는 것에서 자동화가 해결할 수 없는 예외만 처리하는 것으로 바뀝니다.