Why Char Exists

AI agents need access to your applications to be useful. But giving an AI access to your systems is dangerous. Char exists to resolve this tension—enabling powerful cross-application AI workflows while maintaining the security properties enterprises require.

​

The Integration Problem

Before AI agents, connecting applications required building point-to-point integrations. Want your CRM to know about invoices in your ERP? Build an integration. Add a ticketing system to the mix? Build two more integrations. The work scales quadratically with the number of applications. AI agents promised to solve this. Instead of building rigid integrations, you’d give the agent access to each application and let it figure out the workflows. “Find the invoice for Acme and add the status to their CRM record” becomes a natural language request instead of a custom integration project. But this promise came with a problem: how do you give an agent access to your applications without giving it the keys to the kingdom?

​

The Security Problem

Most AI agents that interact with applications fall into one of two categories: Server-side agents run on infrastructure you control, making API calls with service accounts. They’re secure in the sense that you control the code, but they require building OAuth integrations, managing credentials, and granting permissions that often exceed what any individual user has. When something goes wrong, the blast radius is the entire service account’s access. Browser automation agents run in the user’s browser, inheriting their session. They can do anything the user can do—which sounds right until you realize they can also see anything the user can see. A malicious webpage can embed instructions that hijack the agent’s behavior. Security researchers call this “prompt injection,” and it’s the defining vulnerability of browser-based AI. Char takes a third path.

​

Three Kinds of Tool Sources

The integration problem isn’t monolithic. Different applications present different challenges, and Char addresses them with three complementary approaches.

​

WebMCP: When the UI Is the Interface

Many enterprise applications don’t have public APIs. Or they have APIs that are incomplete, poorly documented, or require expensive licensing tiers. What they do have is a user interface—often one that represents decades of refinement. This isn’t accidental. UIs encode hard-won lessons about what users actually need. The placement of buttons, the flow of forms, the structure of dashboards—all of this reflects years of feedback and iteration. The UI is the interface, in the deepest sense. WebMCP tools execute in the browser, operating through the same UI the user sees. When you expose a “search customers” tool, you’re not recreating API logic from scratch—you’re leveraging the search functionality the application already provides, with all its edge case handling and business logic intact. The approach has a profound security benefit: session inheritance. The tool uses the user’s existing browser session. No OAuth flows, no stored credentials, no service accounts. When the user logs out, the tool stops working. Permissions are exactly what the user has—no more, no less. The tradeoff is presence. The user needs the application open in a browser tab. This is ideal for interactive AI assistance where the user is already working with the application. For unattended automation, enterprise deployments can use remote browsers—headless execution with delegated credentials that maintains session inheritance without requiring user presence.

​

Remote MCP: When APIs Exist

Not every application lacks an API. Many internal services—microservices, data platforms, custom tooling—expose well-designed programmatic interfaces. For these, browser-based execution would be unnecessarily indirect. Remote MCP servers connect directly to the Tool Hub over HTTP. They’re like API endpoints, but with two crucial advantages. No versioning headaches. Traditional APIs require careful versioning—breaking changes require coordination across all consumers. MCP’s tool model is more flexible. Tools declare their schemas, and the AI adapts. Add a parameter, and the AI learns to use it. Change a response format, and the AI adjusts. The human-in-the-loop nature of AI workflows absorbs variations that would break rigid integrations. Authentication built in. When an internal MCP server shares your enterprise identity provider, the Tool Hub can authenticate using the same user identity that’s already established. No service accounts, no separate credential stores, no orphaned access when someone leaves. The user’s IDP token flows through the Hub to the remote server—same identity, same permissions, same audit trail. This is particularly powerful for internal services. Your enterprise already has an IDP. Your internal MCP servers can trust it. The Tool Hub becomes the bridge that carries identity across service boundaries without credential sprawl.

​

External MCP: Third-Party Services

Some tools come from outside your enterprise—SaaS applications, vendor APIs, public services. These require a different trust model. External MCP servers authenticate through their own mechanisms, typically OAuth with user consent. The user explicitly authorizes the connection, and the Tool Hub manages the resulting tokens. This is closer to traditional integration patterns, but unified under the same tool surface. The distinction matters for security. Internal tools—those authenticated through your enterprise IDP—are treated as trusted. Your enterprise controls the code, vouches for its behavior. External tools receive additional scrutiny because you don’t control what they return. This trust boundary isn’t arbitrary. It reflects how enterprises already think about security: internal systems are trusted until proven otherwise, external systems are verified before trust is extended.

​

Why Tools Instead of Automation

All three approaches share a common philosophy: agents operate through defined interfaces, not ambient capabilities. When an agent has ambient capabilities—like reading any DOM element or calling any API—you can’t reason about what it might access. The attack surface is unbounded and unauditable. You’re trusting the agent’s judgment about what to look at and what to ignore. When an agent operates through tools, you can enumerate exactly what it can do. Each tool has a defined schema, a documented purpose, and a clear boundary. Security teams can audit the tools. Developers can reason about the data flows. Users can understand what they’re authorizing. This is similar to how modern operating systems handle permissions. Early systems gave programs ambient access to everything. Modern systems require explicit permission grants—this app can access your location, this app can read your contacts. The tool model applies this principle to AI agents.

​

The Hub Architecture

Given that agents should operate through tools, the next question is: how do tools from different sources work together? The naive approach is to have each application maintain its own tool registry. The agent in your CRM knows about CRM tools. The agent in your ERP knows about ERP tools. Cross-application workflows require copying data between them manually. Char introduces the Tool Hub—a per-user registry that aggregates tools from all sources. Browser tabs register their WebMCP tools. Remote MCP servers register their tools. External services register theirs. All converge in a single, identity-scoped registry. This creates something previously impossible: unified tool access across browser sessions, internal services, and external applications. The agent can query your internal data platform, update your CRM, and schedule a calendar event—all in one workflow, all under one identity. The Hub is scoped to you specifically—your identity, your permissions, your tool registry. There’s no shared state between users. This scoping is enforced at the infrastructure level using Cloudflare Durable Objects, which means cross-user access isn’t just prohibited by policy—it’s structurally impossible.

​

The Identity Foundation

Everything in Char flows from identity. Your Tool Hub is scoped to your user ID. Browser tools execute with your session. Remote MCP calls carry your identity. Conversations are stored under your account. Cross-application workflows are possible because all your tools recognize the same user. This is why Char delegates authentication to your existing identity provider rather than maintaining its own user database. Your IDP is already the source of truth for who you are across your enterprise applications. Char validates tokens your IDP issues rather than creating a parallel identity system. For browser-based tools, identity enables session inheritance—the tool uses your existing session, your existing permissions. For remote MCP, identity enables token exchange—the Hub obtains appropriately-scoped credentials for each service, all rooted in your original IDP token. For external services, identity enables consent management—you authorize connections, and the Hub maintains them on your behalf. The design has implications:

• No credential storage. Char never sees your password. Browser sessions stay in the browser. Remote tokens are scoped and short-lived.
• Centralized revocation. Disable a user in your IDP and they immediately lose access to everything—browser tools, remote MCP, external services.
• Inherited policies. Whatever authentication policies your IDP enforces—MFA, password complexity, session timeouts—apply to Char automatically.

​

What This Enables

The combination of multiple tool sources, hub aggregation, and unified identity enables workflows that were previously impractical: Cross-application AI. An agent can orchestrate actions across browser-based applications, internal services, and external SaaS—all in natural language. The integrations that would have taken months to build become conversational requests. Permission-appropriate access. Whether the tool executes in a browser tab or calls a remote API, it operates with your permissions—not a service account’s elevated access, not another user’s data. The blast radius of any mistake is limited to what you could have done manually. Auditable boundaries. Security teams can review what tools exist across all sources, what data they expose, what actions they enable. The attack surface is enumerable rather than ambient. Incremental adoption. Start with browser-based tools for applications that have UIs. Add remote MCP for internal services with APIs. Connect external services as needed. Each addition expands capability without requiring rearchitecture. Legacy application access. Applications that will never have APIs—or whose APIs would take years to build—become accessible through their existing UIs. The decades of business logic encoded in those interfaces becomes available to AI workflows.

​

Further Reading