Trust Boundaries

Every security model must decide what to trust. Char’s trust model is built around a simple principle: your enterprise is responsible for the security of its own systems. Char trusts what you trust, and applies scrutiny to everything else.

​

The Enterprise as Trust Root

When Char validates a user’s JWT token, it establishes trust through your identity provider. The user is who your IDP says they are. Their permissions are what your IDP grants them. This same principle extends to tools. MCP servers that authenticate through your enterprise IDP are part of your enterprise. They’re internal. Everything else is external. The distinction matters because it determines what security controls apply: Internal tools run without content inspection. Your enterprise wrote the code, controls the deployment, and takes responsibility for its behavior. Char doesn’t second-guess your internal systems any more than your internal APIs second-guess your database. External tools are treated as untrusted. The assumption is that external content is potentially hostile. On the Enterprise plan, external tool responses pass through content inspection before reaching the agent.

​

Why Internal Tools Are Trusted

This trust model sometimes surprises security reviewers. Shouldn’t all content be validated? Isn’t defense-in-depth about multiple layers everywhere? The answer is practical. Consider what it would mean to distrust internal tools: False positives. Internal tools often return data that looks suspicious—code snippets, configuration files, documentation with examples. Content validation aggressive enough to catch real attacks would block legitimate internal workflows. Performance cost. Content inspection adds latency. Running it on every internal tool response would significantly slow down the agent. Operational burden. Every false positive needs investigation. Security teams would spend their time reviewing legitimate internal traffic instead of actual threats. Implicit insult. Distrusting internal systems implies the enterprise can’t secure its own infrastructure. This isn’t a position Char can credibly take—if internal systems are compromised, the attacker has access to far more than the agent. The alternative—treating internal and external tools identically—would either overwhelm users with false positives or weaken protection against actual external threats.

​

What Makes a Tool Internal

A tool is internal if it authenticates to Char using your enterprise’s identity infrastructure. This typically means one of: Same IDP. The MCP server validates tokens against the same identity provider as your embedded agent. When a tool call arrives, the server trusts it because it comes from a user your IDP authenticated. VPC connectivity. The MCP server runs in your private network and accepts connections only from your Char deployment through a VPC tunnel. Network isolation provides the trust boundary. Service-to-service authentication. The MCP server accepts requests signed with credentials your enterprise manages. The credential’s validity establishes trust. In all cases, the enterprise controls both ends of the connection. The tool is internal because your enterprise vouches for it.

​

What Makes a Tool External

External tools come from third parties. They might be SaaS applications, public APIs, or MCP servers operated by vendors. The defining characteristic is that your enterprise doesn’t control the code or the deployment. External tools authenticate differently. Instead of your IDP validating the user, the tool validates its own users—or accepts tokens that your users consented to share. The trust relationship is mediated by the user’s consent, not the enterprise’s control. This mediation creates risk. The external tool might:

• Return content designed to manipulate the agent
• Leak information it shouldn’t have access to
• Behave differently than its documentation claims

The trust boundary provides protection: external tools are identified and tracked separately from internal tools, enabling content inspection, rate limiting, and audit logging on the Enterprise plan.

​

Enterprise-Approved External Tools

Some external tools occupy a middle ground. The enterprise has reviewed them, approved their use, and configured them in the connector registry—but they’re still operated by third parties. These enterprise-approved external tools are tracked differently than fully untrusted tools. The rationale: if the enterprise approved the tool, they’ve accepted its intended functionality. The approval itself is the security control.

​

User-Consented External Tools

The riskiest category is tools that users connect without enterprise approval. A user might authorize a third-party MCP server that provides convenient functionality but hasn’t been reviewed for security. Char tracks user-consented tools separately from enterprise-approved tools. This classification enables:

• Different audit treatment (Enterprise plan)
• Different rate limits (Enterprise plan)
• Organization-level policies to disable user-consented tools entirely

​

The Responsibility Boundary

The trust model creates a clear responsibility boundary: Char is responsible for:

• Correctly identifying whether a tool is internal or external
• Enforcing infrastructure-level isolation between users
• Validating authentication tokens on every request
• Maintaining the trust boundary classification

The enterprise is responsible for:

• The security of internal MCP servers
• Reviewing and approving external tool connections
• Monitoring their own systems for anomalies
• Responding to security events in their infrastructure

This division matches how enterprises already think about security. Your SOC monitors your internal systems. Your vendor management process reviews third-party tools. Char fits into these existing workflows rather than replacing them.

​

Further Reading