> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usechar.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Session Inheritance

> AI agents inherit existing browser sessions with cookies and permissions—no OAuth flows or service accounts required

When a user authenticates to your application, Char's embedded agent automatically inherits that session. No additional OAuth flows, no service accounts, no credential management.

## The Traditional Problem

Integrating AI agents with enterprise applications typically requires:

1. **Service accounts** — Privileged accounts that act on behalf of users
2. **OAuth flows** — Users re-authenticate to grant the agent access
3. **Token management** — Refresh tokens, expiry handling, secure storage
4. **Elevated permissions** — Service accounts often have broader access than any individual user

This creates both security risks and user friction.

## Char's Approach

The agent inherits the user's existing session:

```mermaid theme={null}
sequenceDiagram
    participant Agent as AI Agent (Client)
    participant Server as Backend Server (API)

    Note over Agent: Agent holds Inherited<br/>Session Cookies

    Agent->>Server: API Request (e.g., GET /data) with Cookie: session_id=...
    Server->>Server: Verify Session Cookie (Bypass Auth)
    Server-->>Agent: API Response (200 OK, JSON data)

    Agent->>Server: API Request (e.g., POST /action) with Cookie: session_id=...
    Server->>Server: Verify Session Cookie
    Server-->>Agent: API Response (200 OK, Success)
```

The key insight: **WebMCP tools execute in the browser tab's context**. When a tool calls `fetch()`, it uses the user's existing cookies and session.

## Security Properties

### Permission Parity

The agent has exactly the permissions the user has:

| User Permission         | Agent Permission        |
| ----------------------- | ----------------------- |
| Can view records        | Can view records        |
| Cannot delete records   | Cannot delete records   |
| Read-only on financials | Read-only on financials |

There's no privilege escalation path. The agent cannot access more than the user.

### Session Lifecycle

When the user's session ends, the agent's access ends:

* **Logout** — Agent loses access immediately
* **Session timeout** — Agent cannot make calls
* **Permission change** — Agent sees new permissions immediately

No stale tokens. No cached credentials. The agent's access is always current.

### Audit Trail

All agent actions appear as the user in your existing audit logs:

```
[2024-01-15 10:32:15] user@company.com updated customer #1234
[2024-01-15 10:32:18] user@company.com sent email to contact
```

Your existing compliance tooling works unchanged.

## Why This Works

### Browser as Authentication Layer

The key insight is that WebMCP tools execute in the browser tab's JavaScript context—the same context where the user is already authenticated. When a tool makes a `fetch()` call, the browser automatically attaches session cookies. No code is needed to "pass" credentials; the browser handles it.

This is fundamentally different from server-side agents, which must obtain and store credentials separately from the user's browser session.

### Standard Web Security Model

Session inheritance doesn't bypass or modify web security—it relies on it:

* **Same-origin policy** — Tools can only call APIs the page can reach
* **Cookie scoping** — SameSite and HttpOnly attributes work as designed
* **CORS enforcement** — Cross-origin restrictions apply normally

The agent operates within the exact same security sandbox as any JavaScript on your page. Your existing security controls and audit mechanisms apply unchanged.

<Info>
  For implementation details, see the [WebMCP Tools guide](/guides/webmcp-tools).
</Info>

## Comparison: Session Inheritance vs Service Accounts

| Aspect             | Service Accounts      | Session Inheritance    |
| ------------------ | --------------------- | ---------------------- |
| Permissions        | Often over-privileged | Exact user permissions |
| Credential storage | Required              | None                   |
| Token management   | Required              | None                   |
| Audit attribution  | Service account       | Actual user            |
| Session lifecycle  | Independent           | Tied to user           |
| Setup complexity   | High                  | Zero                   |

## Design Assumptions

Session inheritance assumes your application uses standard web authentication patterns:

**Browser-mediated sessions** — Authentication state must be accessible to JavaScript running in the page. This typically means session cookies, though any browser-based auth (localStorage tokens, etc.) works. Server-side-only sessions without browser state cannot be inherited.

**API accessibility** — Your APIs must be callable from the browser. If your backend only accepts server-to-server calls, tools cannot invoke it directly. Most modern web applications already expose browser-callable APIs for their frontend.

## Further Reading

<CardGroup cols={2}>
  <Card title="Tool Hub" icon="hub" href="/explanation/tool-hub">
    How tools are aggregated across apps
  </Card>

  <Card title="Federated Authentication" icon="shield" href="/explanation/federated-auth">
    JWT validation and identity verification
  </Card>

  <Card title="WebMCP Tools" icon="hammer" href="/guides/webmcp-tools">
    Register tools in your application
  </Card>

  <Card title="Context Isolation" icon="lock" href="/explanation/context-isolation">
    What the agent can and cannot see
  </Card>
</CardGroup>

<Snippet file="support-cta.mdx" />