kernel · juecd · Feb 10, 2026 · Feb 10, 2026 · Feb 10, 2026
diff --git a/info/pricing.mdx b/info/pricing.mdx
@@ -42,6 +42,12 @@ With Browser Pools, you pay the standard usage-based price per GB-second while b
 
 > Note: Disk space charges are waived for Enterprise plan customers.
 
+## Managed Auth
+
+Managed Auth is included on all paid plans with no per-connection fees. Under the hood, it uses browser sessions to log in and keep your sessions fresh—these count toward your browser usage and concurrency like any other browser session.
+
+Auth sessions are fast (typically 5-30 seconds each). Kernel monitors session health and re-authenticates automatically when sessions expire—most stay valid for days. For example, keeping 100 auth connections logged in typically costs less than $5/month in browser usage.
+
 ## Concurrency limits
 
 | Feature | Developer (free + usage) | Hobbyist ($30 / mo + usage) | Start-Up ($200 / mo + usage) | Enterprise |
@@ -54,12 +60,6 @@ With Browser Pools, you pay the standard usage-based price per GB-second while b
 
 > Note: Limits are org-wide by default unless stated otherwise. `Managed auth profiles` refer to the number of active auth connections that Kernel maintains using your stored [Credentials](/profiles/credentials) or [1Password connection](/integrations/1password).
 
-## Managed Auth billing
-
-Managed Auth is included on all paid plans with no per-connection fees. Under the hood, it uses browser sessions to log in and keep your sessions fresh—these count toward your browser usage and concurrency like any other browser session.
-
-Auth sessions are fast (typically 5-30 seconds each). Kernel monitors session health and re-authenticates automatically when sessions expire—most stay valid for days. For example, keeping 100 auth connections logged in typically costs less than $5/month in browser usage.
-
 ## Pricing calculator
 
 import { PricingCalculator } from '/snippets/calculator.jsx';

diff --git a/profiles/credentials.mdx b/profiles/credentials.mdx
@@ -3,15 +3,15 @@ title: "Credentials"
 description: "Automate authentication with stored credentials"
 ---
 
-Credentials are the automation layer for Managed Auth. Store login information securely, and Kernel handles authentication automatically—no user interaction needed.
+Credentials allow you to store login information securely and enable Kernel's automated re-authentication without requiring user interaction.
 
-**Three ways to provide credentials:**
-- **Save during login** — Capture credentials when a user logs in via [Hosted UI](/profiles/managed-auth/hosted-ui) or [Programmatic](/profiles/managed-auth/programmatic)
+**There are three ways to provide credentials:**
+- **Automatically save during login** — Capture credentials directly from the user when they log in via [Hosted UI](/profiles/managed-auth/hosted-ui) or [Programmatic](/profiles/managed-auth/programmatic)
 - **Pre-store in Kernel** — Create credentials before any login for fully headless automation
 - **Connect 1Password** — Use credentials from your existing 1Password vaults
 
 <Card title="1Password Integration" icon="key" href="/integrations/1password">
-  Connect your 1Password vaults to automatically use existing credentials with Managed Auth. Credentials are matched by domain—no manual setup per site.
+  Connect your 1Password vaults to automatically use existing credentials with Managed Auth. Credentials are automatically matched by domain.
 </Card>
 
 ## Save credentials during login
@@ -33,7 +33,7 @@ login = await kernel.auth.connections.login(
 ```
 </CodeGroup>
 
-Once saved, the profile stays authenticated automatically. When the session expires, Kernel re-authenticates using the stored credentials—no user interaction needed.
+Once saved, the profile stays authenticated automatically. When the session expires, Kernel re-authenticates using the stored credentials.
 
 ## Pre-store credentials
 
@@ -121,7 +121,9 @@ credential = await kernel.credentials.create(
 
 ### SSO / OAuth
 
-For sites with "Sign in with Google/GitHub/Microsoft", set `sso_provider` and include the OAuth provider in `allowed_domains`:
+For sites with "Sign in with Google/GitHub/Microsoft", set `sso_provider` and include the OAuth provider's domains in `allowed_domains`.
+
+The workflow automatically clicks the matching SSO button and completes OAuth:
 
 <CodeGroup>
 ```typescript TypeScript
@@ -163,13 +165,11 @@ auth = await kernel.auth.connections.create(
 ```
 </CodeGroup>
 
-The workflow automatically clicks the matching SSO button and completes OAuth.
-
 ## Partial Credentials
 
-Credentials don't need to contain every field. Store what you have, and the flow pauses for missing values.
+Credentials don't need to contain every field required by the login form. You can store what you have and collect the necessary fields from the user. `auth.connections.login()` pauses for missing values.
 
-**Example:** Credential has email + TOTP secret, but no password:
+As an example, the below credential has email + TOTP secret stored (and automatically handled), but no password. The password is dynamically collected from the user using Kernel's Hosted UI or your Programmatic flow:
 
 <CodeGroup>
 ```typescript TypeScript
@@ -251,6 +251,6 @@ This is useful when you want to:
 
 ## Notes
 
-- The `values` object is flexible—store whatever fields the login form needs (`email`, `username`, `company_id`, etc.)
-- Deleting a credential unlinks it from associated connections; they'll no longer auto-authenticate
-- One credential per account—create separate credentials for different user accounts
+- The `values` object is flexible and can be used to store whatever fields the login form needs (`email`, `username`, `company_id`, etc.)
+- Deleting a credential unlinks it from associated connections so they can no longer auto-authenticate
+- Use one credential per account. We recommend creating separate credentials for different user accounts
diff --git a/profiles/managed-auth/faq.mdx b/profiles/managed-auth/faq.mdx
@@ -1,45 +1,41 @@
 ---
 title: FAQ
-description: Frequently asked questions about Managed Auth
 ---
 
-## How does re-authentication work?
+## How does automatic re-authentication work?
 
-When you link credentials to a connection, Kernel monitors the session and re-authenticates automatically when it expires. Periodic health checks (default: every hour) detect logged-out sessions and trigger re-auth in the background, so the profile stays logged in without any action on your part.
+When you link credentials to a connection, Kernel monitors the login session and re-authenticates automatically when it expires. Periodic health checks detect logged-out sessions and trigger re-auth in the background, so the profile stays logged in without additional action on your part.
 
 <Warning>
-Automatic re-authentication only works when credentials are complete and don't require human input. If login needs SMS/email OTP, push notifications, or manual MFA selection, you'll need to trigger a new login session manually.
+Automatic re-authentication only works when the stored credentials are complete and don't require human input. If login needs SMS/email OTP, push notifications, or manual MFA selection, you'll need to trigger a new login session manually.
 </Warning>
 
-## How do I know if a connection can auto-reauth?
 
-Check the `can_reauth` field on a connection. This boolean tells you whether Kernel can automatically re-authenticate the connection when the session expires.
+## How often are health checks performed?
 
-`can_reauth` is `true` when **all** of the following are met:
+Health checks on regular cadences based on your plan:
+- Hobbyist (1 hr)
+- Start-Up (15 min)
+- Enterprise (configurable)
 
-1. **Credential linked** — A credential is attached to the connection (stored in Kernel or via an external provider like [1Password](/integrations/1password))
-2. **Login URL set** — The connection has a `login_url` (set automatically after the first successful login, or provided manually)
-3. **Login flow learned** — At least one successful login has completed so Kernel has learned the login flow for the site
-4. **No external action required** — The learned login flow doesn't require human intervention (see below)
+## How do I know if a Kernel can automatically re-authenticate a connection?
+
+Check the `can_reauth` field on a connection. This boolean checks the following conditions:
+
+1. **Credential linked** — A credential must be attached to the connection (stored in Kernel or via an external provider like [1Password](/integrations/1password))
+2. **No external action required** — The learned login flow doesn't require human intervention
+
+Only if all of the above conditions are met will `can_reauth` be `true`. When true, Kernel will attempt to automatically re-authenticate the connection.
 
 ### External actions that prevent auto-reauth
 
 After a successful login, Kernel saves the login flow. If the flow includes steps that require human action—like SMS/email OTP, push notifications, or manual MFA selection—Kernel marks the connection as unable to auto-reauth because those steps can't be automated without user input.
 
 If your login flow requires one of these, you can still automate around it:
 - **Switch to TOTP** — If the site supports authenticator apps, add a `totp_secret` to your credential. TOTP codes are generated automatically, so the login flow won't require external action.
-- **Trigger manual re-auth** — Start a new login session when `status` is `NEEDS_AUTH` and route the user through the [Hosted UI](/profiles/managed-auth/hosted-ui) or [Programmatic](/profiles/managed-auth/programmatic) flow.
-
-## How do I know if a connection needs authentication?
-
-Check the connection's `status` field:
-
-- `AUTHENTICATED` — Profile is logged in and ready to use
-- `NEEDS_AUTH` — Profile needs authentication (auto-reauth failed or isn't possible)
-
-If `status` is `NEEDS_AUTH`, start a new login session. This happens when auto-reauth fails (e.g., password changed), when credentials require human input, or when `can_reauth` is `false`.
+- **Trigger manual re-auth** — Start a new login session and route the user through the [Hosted UI](/profiles/managed-auth/hosted-ui) or [Programmatic](/profiles/managed-auth/programmatic) flow.
 
-## What authentication methods are supported?
+## Which authentication methods are supported?
 
 Managed Auth supports username/password authentication and most SSO providers. 
 
@@ -53,14 +49,14 @@ If a login attempt fails, Kernel will retry with exponential backoff. After mult
 
 - Invalid credentials
 - Bot detection blocking the login page
-- Captcha that couldn't be solved
+- CAPTCHAs that couldn't be solved
 
 ## Can I use Managed Auth with any website?
 
-Managed Auth works with any website. Sites with aggressive bot detection may require additional configuration (stealth mode, proxies). Passkeys and hardware security keys are not currently supported.
+Managed Auth works with most websites. Sites with aggressive bot detection may require additional configuration (stealth mode, proxies). Passkeys and hardware security keys are not currently supported.
 
 ## How is Managed Auth billed?
 
 Managed Auth is included on all paid plans with no per-connection fees. It uses browser sessions to log in and keep your sessions fresh—these count toward your browser usage like any other browser session.
 
-Auth sessions are fast (typically 5-30 seconds each). Kernel monitors session health and re-authenticates automatically when sessions expire—most stay valid for days. For example, keeping 100 auth connections logged in typically costs less than $5/month in browser usage. See [Pricing & Limits](/info/pricing#managed-auth-billing) for details.
+Auth sessions are fast (typically 5-30 seconds each). Kernel monitors session health and re-authenticates automatically when sessions expire—most stay valid for days. For example, keeping 100 auth connections logged in typically costs less than $5/month in browser usage. See [Pricing & Limits](/info/pricing#managed-auth) for details.
diff --git a/profiles/managed-auth/hosted-ui.mdx b/profiles/managed-auth/hosted-ui.mdx
@@ -3,7 +3,7 @@ title: "Hosted UI"
 description: "The simplest way to create authenticated browser sessions"
 ---
 
-Collect credentials via Kernel's hosted page, then use the authenticated session in your automations. This is the recommended approach for most applications.
+Collect credentials securely via Kernel's hosted page, then use the authenticated session in your automations. This is the recommended approach for most applications.
 
 Use the Hosted UI when:
 - You need users to provide their credentials
@@ -97,12 +97,12 @@ if state.status == "AUTHENTICATED":
 </CodeGroup>
 
 <Info>
-Poll every 2 seconds. The session expires after 5 minutes if not completed.
+Poll no more than every 2 seconds. The session expires after 5 minutes if not completed.
 </Info>
 
 ### 5. Use the Profile
 
-Create browsers with the profile and navigate to the site—the session is already authenticated:
+Create browsers with the profile and navigate to the site. The browser session will already be authenticated:
 
 <CodeGroup>
 ```typescript TypeScript
@@ -127,7 +127,7 @@ await page.goto("https://linkedin.com")
 </CodeGroup>
 
 <Info>
-Use `stealth: true` when creating browsers for authenticated sessions.
+Managed Auth Connections are generated using Kernel's [stealth](/browsers/bot-detection/stealth) mode. Use `stealth: true` when creating authenticated browser sessions for the best experience.
 </Info>
 
 
@@ -227,7 +227,7 @@ login = await kernel.auth.connections.login(
 ```
 </CodeGroup>
 
-After successful login, future login sessions for this connection will automatically use the saved credentials—no user interaction needed. See [Credentials](/profiles/credentials) for more on automated authentication.
+After successful login, future login sessions for this connection will automatically use the saved credentials without requiring user interaction. See [Credentials](/profiles/credentials) for more on automated authentication.
 
 ### Custom Login URL
 
@@ -253,7 +253,9 @@ auth = await kernel.auth.connections.create(
 
 ### SSO/OAuth Support
 
-For sites with "Sign in with Google/GitHub/Microsoft", add the OAuth provider's domains to `allowed_domains`:
+Sites with "Sign in with Google/GitHub/Microsoft" are supported. The user completes the OAuth flow with the provider, and the authenticated session is automatically saved to the Kernel profile.
+
+Make sure to add all of the OAuth provider's domains to `allowed_domains`:
 
 <CodeGroup>
 ```typescript TypeScript
@@ -273,11 +275,9 @@ auth = await kernel.auth.connections.create(
 ```
 </CodeGroup>
 
-The user can click the SSO button on the hosted page, complete OAuth with the provider, and the authenticated session is saved to the profile.
-
 ### Post-Login URL
 
-After successful authentication, retrieve the connection to get `post_login_url`—the page where the login landed. Use this to start your automation from the right place:
+After successful authentication, `post_login_url` will be set to the page where the login landed. Use this start your automation from the right place:
 
 <CodeGroup>
 ```typescript TypeScript

diff --git a/profiles/managed-auth/overview.mdx b/profiles/managed-auth/overview.mdx
@@ -7,13 +7,13 @@ description: "Create authenticated browser sessions for your automations"
   Managed Auth is currently in public beta. Features are subject to change.
 </Note>
 
-Managed Auth creates and maintains authenticated browser profiles for your automations. Store credentials once, and Kernel monitors auth state and re-authenticates automatically when needed. When you launch a browser with the profile, you're already logged in and ready to go.
+Managed Auth creates and maintains authenticated browser profiles for your AI agents and web automations. Store credentials once, and Kernel re-authenticates automatically when needed. When you launch a browser with the managed profile, you're already logged in and ready to go.
 
 ## How It Works
 
 <Steps>
   <Step title="Create a Connection">
-    A **Managed Auth Connection** links a profile to a domain. Create one for each domain + profile combination you want to keep authenticated.
+    A **Managed Auth Connection** links a profile to a website domain. Create one for each domain + profile combination you want to keep authenticated.
 
 <CodeGroup>
 ```typescript TypeScript
@@ -32,7 +32,9 @@ auth = await kernel.auth.connections.create(
 </CodeGroup>
   </Step>
   <Step title="Start a Login Session">
-    A **Managed Auth Session** is the login flow. Start one to authenticate—users provide credentials via the hosted page (or your own UI).
+    A **Managed Auth Session** is the corresponding login flow for the specified connection. Users provide credentials via a Kernel-hosted page or your own UI.
+
+    Specify a [Credential](/profiles/credentials) to enable re-authentication without user input.
 
 <CodeGroup>
 ```typescript TypeScript
@@ -74,9 +76,10 @@ if state.status == "AUTHENTICATED":
     print("Authenticated!")
 ```
 </CodeGroup>
+
   </Step>
   <Step title="Use the Profile">
-    Create browsers with the profile and navigate to the site—the session is already authenticated.
+    Once the auth connection completes, create browsers with the profile and navigate to the site. The browser session will already be authenticated.
 
 <CodeGroup>
 ```typescript TypeScript
@@ -100,7 +103,6 @@ await page.goto("https://netflix.com")
 ```
 </CodeGroup>
 
-    For fully automated flows, link [Credentials](/profiles/credentials) to enable re-authentication without user input.
   </Step>
 </Steps>
 
@@ -119,20 +121,17 @@ await page.goto("https://netflix.com")
   </Card>
 </CardGroup>
 
-<Tip>
-Layer in [Credentials](/profiles/credentials) to enable fully automated re-authentication when sessions expire—no user interaction needed.
-</Tip>
 
 ## Why Managed Auth?
 
 The most valuable workflows live behind logins. Managed Auth provides:
 
-- **Works on any website** - Login pages discovered and handled automatically
-- **SSO/OAuth support** - "Sign in with Google/GitHub/Microsoft" buttons work out of the box via `allowed_domains`
-- **2FA/OTP handling** - TOTP codes automated, SMS/email/push OTP supported
+- **Works on any website** - Login pages are discovered and handled automatically
+- **SSO/OAuth support** - "Sign in with Google/GitHub/Microsoft" buttons work out-of-the-box via `allowed_domains`
+- **2FA/OTP handling** - TOTP codes automated, SMS/email/push OTP are supported
 - **Post-login URL** - Get the URL where login landed (`post_login_url`) so you can start automations from the right page
-- **Session monitoring** - Automatic re-authentication when sessions expire (with stored credentials)
-- **Secure by default** - Credentials encrypted at rest, never exposed in API responses or passed to LLMs
+- **Session monitoring** - Automatic re-authentication when sessions expire with stored credentials
+- **Secure by default** - Credentials encrypted at rest, never exposed in API responses, or passed to LLMs
 
 ## Security
 

diff --git a/profiles/managed-auth/programmatic.mdx b/profiles/managed-auth/programmatic.mdx
@@ -305,7 +305,7 @@ if state.mfa_options:
 ```
 </CodeGroup>
 
-After selecting an MFA method, the flow continues—poll for `discovered_fields` to submit the code, or handle external actions for push/security key.
+After selecting an MFA method, the flow continues. Poll for `discovered_fields` to submit the code, or handle external actions for push/security key.
 
 ### External Actions (Push, Security Key)
 

diff --git a/profiles/overview.mdx b/profiles/overview.mdx
@@ -5,6 +5,10 @@ description: "Persist and reuse browser session state (cookies, local storage) a
 
 Profiles let you capture browser state created during a session (cookies and local storage) and reuse it in later sessions. This is useful for persisting login state or other site preferences across browser sessions.
 
+<Tip>
+  If you're looking to maintain authenticated browser sessions, check out [Managed Auth](/profiles/managed-auth/overview).
+</Tip>
+
 ## 1. Create a profile
 
 The first step in using profiles is to create one, optionally giving it a meaningful `name` that is unique within your organization.