Skip to main content
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: 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 PermissionAgent Permission
Can view recordsCan view records
Cannot delete recordsCannot delete records
Read-only on financialsRead-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] [email protected] updated customer #1234
[2024-01-15 10:32:18] [email protected] 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.
For implementation details, see the WebMCP Tools guide.

​
Comparison: Session Inheritance vs Service Accounts

AspectService AccountsSession Inheritance
PermissionsOften over-privilegedExact user permissions
Credential storageRequiredNone
Token managementRequiredNone
Audit attributionService accountActual user
Session lifecycleIndependentTied to user
Setup complexityHighZero

​
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

Tool Hub

How tools are aggregated across apps

Federated Authentication

JWT validation and identity verification

WebMCP Tools

Register tools in your application

Context Isolation

What the agent can and cannot see