Credentials and access boundaries
Protect project credentials and authorize each person's access to browser state.
Keep project keys in the backend
Do not put a project key into frontend bundles, model prompts, website pages, or public issue reports. Use your application to authorize a user before acting on that user's browser session.
Sessions are project resources. Two keys in one project can access that project's resources within the current full-project key model. Metadata does not create a permission boundary.
Treat connection URLs as credentials
CDP and Live URLs contain authorization. Deliver them only to an intended client. Avoid logging, sharing, or sending them to third-party analytics and error trackers.
Grant expiry bounds a new connection handshake. It does not imply that every existing connection disconnects at that exact time. Session expiry, current controller, control epoch, and credential revocation continue to constrain access.
Preserve control ownership
Read-only viewing does not grant input control. Human handoff revokes prior control channels before giving control to the next party. Reconnect automation with a fresh grant only after the resource reports stable automation control.
The SDK redacts its own credential-bearing inspection output. Third-party clients and application logs still require your own configuration.
Verify the boundary you need
The implementation separates browser sessions and restricts browser access to private platform networks. It does not publish a security certification, enterprise compliance package, or formal security SLA.
Your application owns its user authorization, business data, model access, and external storage. Use the multi-user pattern and data lifecycle when designing those boundaries.