제가 Playwright를 통해 에이전트에게 브라우저를 줄 때마다 같은 문제가 저를 괴롭혔습니다. 유용한 작업을 수행하게 하려면, 에이전트는 사용자의 로그인 세션이 필요합니다. 그리고 로그인 세션은 기본적으로 모든 접근 권한을 한 번에 의미합니다. 그것은 왕국의 열쇠이거나, 아무것도 아닙니다.

바로 이 '모 아니면 무'가 실제 문제입니다. 저는 중간 지점을 찾기 위해 몇 가지 방법을 찾아냈습니다:

1. 에이전트에게 쿠키를 직접 주지 말고 — 이를 관리(custody)하세요. 브라우저 세션(Playwright의 storage-state, 즉 쿠키 + localStorage)을 봉인하여 에이전트 외부의 저장소에 보관합니다. 이 세션을 런타임에 격리된 브라우저 프로필에 주입하며, 에이전트 프로세스가 실제로 이를 보유하는 적은 없고, 실행이 끝나면 삭제됩니다.

2. 개별 사이트 단위로 봉인하세요(Seal per-site, not one blob). GitHub 전용 세션은 이메일 전용 세션과는 별개의 봉인된 자격 증명입니다. 에이전트에게 필요한 세션만 부여해야 합니다 — 따라서 레포지토리 자동화 에이전트는 사용자의 받은 편지함에 접근할 수 없습니다.

3. 로그인뿐 아니라 탐색 범위(Scope navigation)도 제한하세요. 세션이 로드된 상태에서도 이동할 수 있는 범위를 제한합니다. github.com/*만 허용하고 나머지 모든 것(mail.google.com 등)은 in-path에서 거부하며, fail-closed 방식으로 작동하게 합니다 — 이렇게 하면 프롬프트 주입형 에이전트가 승인하지 않은 사이트로 돌아다니는 것을 막을 수 있습니다.

4. 비상 정지 장치(Kill switch) = 실행 취소(revoke the run). 인스턴스를 취소하면 세션이 즉시, 작업 중간에 드롭됩니다.

솔직한 한계점: 하나의 봉인된 세션 내에서는 개별 쿠키를 필터링할 수는 없습니다 — 그 정밀도는 '어떤 세션을 봉인하는지' + '어떤 URL을 허용하는지'이며, 쿠키별 단위가 아닙니다. 좁은 범위의 세션을 봉인하면 매우 안전합니다.

저는 이 패턴을 오픈 소스 도구(Chancery — Go 바이너리, Apache-2.0, 자체 호스팅)에 구현했지만, 중요한 것은 도구보다 그 패턴입니다: 세션을 관리하고, 범위를 좁게 봉인하며, 탐색 범위를 제한하고, 취소 시 드롭되도록 만드세요. 만약 에이전트에게 브라우저를 제공하면서 이 과정을 더 깔끔하게 처리하는 방법을 알고 계시다면, 정말 듣고 싶습니다: [https://github.com/chanceryhq/chancery]