AI 브라우저 에이전트에게는 전용 브라우저가 필요합니다
자율 에이전트에게 평소 쓰는 브라우저를 맡기면 내 쿠키, 로그인, 기기까지 넘겨주는 셈입니다. 에이전트가 격리된 프로필에 있어야 하는 이유와 프로필을 만들어 주는 방법입니다.
AI 에이전트에게 웹에서의 실질적인 능력을 주는 가장 빠른 방법은 브라우저를 조작하게 하는 것입니다. 그리고 가장 빨리 후회하는 방법은 내 브라우저를 조작하게 하는 것입니다. 평소 쓰는 브라우저에는 지금까지 로그인한 모든 세션이 들어 있고, 클릭할 수 있는 에이전트는 그 세션이 닿는 모든 곳을 클릭할 수 있습니다.
피해 범위의 문제
공급업체를 조사하라는 요청을 받은 에이전트는 은행 탭을 열 생각이 없습니다. 하지만 에이전트가 실행되는 브라우저는 그런 구분을 하지 않습니다. 쿠키 저장소 하나, 저장된 로그인 하나, 기기 아이덴티티 하나뿐입니다. 에이전트가 이동할 수 있는 곳은 이미 모두 인증되어 있습니다. 사람들이 가장 먼저 떠올리는 완화책인 별도의 Chrome 프로필이나 시크릿 창은 쿠키만 옮길 뿐 나머지는 그대로입니다.
격리가 실제로 다뤄야 하는 범위
- 저장소: 자기만의 쿠키 저장소, Local Storage, IndexedDB를 다른 어떤 것도 쓰지 않는 디렉터리에 보관
- 자격 증명: 그 프로필에 의도적으로 로그인한 계정만, 다른 것은 없음
- 네트워크: 자기만의 경로. 에이전트 트래픽과 내 트래픽이 같은 주소가 되지 않도록
- 기기 아이덴티티: 그 프로필에서 안정적이며, 내가 일하는 기기의 복사본이 아닐 것
- 확장 프로그램: 에이전트에게 필요한 것만, 내 비밀번호 관리자는 제외
이 목록은 격리된 브라우저 프로필이 이미 충족하는 목록과 같습니다. 브라우저의 관점에서 에이전트는 내 기기를 쓰는 또 다른 사용자일 뿐이며, 내 나머지 작업을 볼 수 없어야 합니다.
에이전트에게 프로필 만들어 주기
PowerOps에서 이 패턴은 짧습니다. 에이전트용 프로필을 만들고, 트래픽을 보낼 경로를 지정하고, 그 작업에 필요한 계정에만 로그인합니다. 그다음 Local API로 시작하면 브라우저의 디버깅 엔드포인트가 반환되고, 에이전트 프레임워크가 직접 띄운 브라우저가 아니라 그 엔드포인트를 가리키게 하면 됩니다.
# Start the agent's profile and take the endpoint it returns.
curl -s -X POST http://127.0.0.1:50326/v1/browsers/start \
-H "Authorization: Bearer $POWEROPS_KEY" \
-H "Content-Type: application/json" \
-d '{"profileId": "agent-research-01"}'Chrome DevTools Protocol을 사용하는 것이라면 이 호출이 반환한 대상에 연결할 수 있습니다. Puppeteer, Playwright, 또는 둘 중 하나를 감싼 에이전트 프레임워크 모두 가능합니다. 에이전트의 코드는 전혀 바뀌지 않고, 바뀌는 것은 에이전트가 들어가는 브라우저입니다.
에이전트당이 아니라 작업당 프로필 하나
본능적으로는 에이전트에게 프로필 하나를 주려 합니다. 더 나은 단위는 작업입니다. 공급업체 조사용 프로필, 게시가 허용된 계정용 프로필, 읽기 전용 대시보드용 프로필처럼요. 실행이 잘못되더라도 피해는 그 프로필 하나가 닿을 수 있는 범위로 제한되며, 디렉터리를 버리고 처음부터 다시 시작할 수 있습니다.
실행 결과를 비교 가능하게 유지하기
에이전트는 두 번의 실행이 같은 실행인 경우가 드물어서 디버깅이 어렵습니다. 실행할 때마다 같은 기기를, 같은 경로에서, 마지막에 남겨 둔 상태로 보고하는 프로필은 시도 사이의 차이 중 한 부류를 통째로 없애 줍니다. 실행이 다르게 동작할 때 환경은 더 이상 용의자가 아닙니다.
선
이 중 어느 것도 사이트의 약관, 요청 제한, robots 정책을 우회하는 방법이 아니며, 그런 용도로 판매되지도 않습니다. 이것이 에이전트에게 주는 것은 나의 것이 아니라 작업의 것인 브라우저입니다.
