把真实登录交给无头 AI agent：Lightpanda Session Bridge
自主 AI agent 要操作现代 Web 仪表盘时，把密码或会话 token 塞进 prompt 是安全灾难。作者构建了 Lightpanda Session Bridge——一个开源的 MV3 Chrome 扩展 + 加固的 loopback relay，通过 CDP 把你活的浏览器会话安全复制进本地 Lightpanda 无头运行时。零凭据输入、零 secret 暴露给 LLM。
痛点
agent 要查 AWS 账单控制台、SaaS 仪表盘私有日志、内部门户时，演示就崩了。现代应用不在 basic auth 后面——它们在 Google OAuth、SSO 联邦、硬件 passkey、生物识别 2FA 后面。无头浏览器无法点安全密钥、答手机验证器、对 FaceID 眨眼。 于是大家妥协：把密码硬编码进 prompt 或 .env（泄漏进 LLM 上下文日志、聊天历史、trace）；把会话 cookie 复制粘贴。
三件套架构（原文主线）
Chrome 扩展（MV3）：只申请最小作用域权限（activeTab、cookies、storage）。点击时捕获当前域 cookie、归一化、准备传输信封。首次启动自动配对握手（
/v1/bootstrap），共享加密 token 存本地隔离存储，无需手动复制粘贴。加固 Loopback Relay（relay/server.py）：只听 127.0.0.1:8765，是安全网关——强制 origin 匹配；把浏览器 cookie 结构翻译成 Lightpanda 兼容的 CDP 消息（含
lax→Lax大小写转换，避开 -31998 InvalidEnumTag 崩溃）；按 RFC 6265bis 归一化__Host-/__Secure-前缀；经 CDP WebSocket 转发给无头引擎。Lightpanda 无头引擎：Zig + V8 写的超快开源无头浏览器，专为 AI 自动化打造；跑在 WSL2 里与 Windows 宿主隔离。
SSRF 与本地泄漏防线
把本地 HTTP relay 当可信边界是本地提权发生的方式。既然 relay 收 cookie，作者从一开始就当对抗性 SSRF 表面设计：
- 零日志：cookie 名和值绝不打印到 stdout、不落盘、不进历史；
- 仅 loopback：硬编码绑定 127.0.0.1，不暴露任何可路由网卡；
- 严格 IdP 黑名单：自动拒绝发给身份根（accounts.google.com、login.microsoftonline.com、appleid.apple.com、github.com、auth0.com）的传输；
- SSRF IP/DNS 校验：目标域必须解析到合法公网 IPv4/IPv6；localhost 别名、127.0.0.0/8 等一律拒绝。
实践建议
- agent 要登录态时用"会话桥接"而非凭据注入：无头引擎里复制活会话，LLM 永远碰不到 secret；
- 本地 relay 一律按 SSRF 表面设计：loopback only、IdP 黑名单、IP/DNS 校验、零日志；
- cookie 结构跨引擎有差异（sameSite 大小写、前缀规则），传输层要归一化而非原样转发。
来源：Handing Real Logins to Headless AI Agents: Building the Lightpanda Session Bridge - DEV Community