Kernel Managed Auth

Use a managed auth connection to acquire a reusable authenticated browser profile, then continue the original website task with the browser-control method that fits it. This skill owns authentication and the handoff to a profile-backed browser; it does not assume the task is QA.

Decide whether managed auth is needed

Make this decision before listing or creating managed-auth connections:

1. Treat a URL as a resource identifier, not as evidence that the task requires browser access.
2. For structured reads and writes, prefer authoritative local records or a dedicated, service-specific API, CLI, MCP server, or other first-party integration when it supports the operation. Search the host's tool catalog, including deferred MCP tools, before concluding that no integration is available.
3. Choose a browser only when the task genuinely requires the authenticated website UI, the dedicated integration lacks the needed capability, or browser behavior itself is under test.
4. After choosing a browser, start hosted login only when the target operation requires authenticated state. Public or unauthenticated pages should not trigger managed auth.

If a dedicated integration can complete the task, use it and do not continue with this skill. If the decision selects an authenticated browser path, follow the workflow below; authenticated browser tasks must still use managed auth.

Core workflow