Internal AI and External MCP as Separate Environments
The same business data does not require the same access channel
When a company adopts AI, it is tempting to combine everything behind one universal gateway: the internal agent, external assistants, developer tools, and partner integrations. This makes a presentation diagram simpler, but it blurs trust boundaries. Sapphire I.C.D.S. takes a different approach. Built-in AI and external MCP are separate environments, even when they call the same native operation of a business module in selected cases.
The separation answers a practical question: who initiates an action, in which context they operate, and which data should be visible to that class of client at all. An internal platform user and an external AI client do not become equivalent merely because both can request a list of articles.
Internal AI operates inside the platform
The built-in AI agent runs in the authenticated Sapphire I.C.D.S. context. The platform determines the session owner, the available work surface, the selected model profile, and the authorised tools. The agent can use corporate instructions, memory, and a knowledge base when internal policy allows it. Its tasks, history, and actions remain part of the governed AI environment.
Tool access is assembled from global state, group rights, and session settings. A user request cannot declare a new role or enable a prohibited command by itself. This makes the internal agent suitable for employees' daily work, including preparing content, analysing data, maintaining plans, and executing authorised operations in installed modules.
External MCP is intended for other clients
External MCP in Sapphire I.C.D.S. is in developer alpha. In the current confirmed contour, only the ChatGPT connection to https://sapphire-project.com/mcp has been verified; other hosts, clients, and unfinished policy or hardening capabilities require separate validation.
MCP is a standard interface designed to let compatible external AI clients and work environments discover and call published tools. In Sapphire I.C.D.S., that access uses a separate HTTPS surface, its own authentication, and explicit scopes. The OAuth flow begins with mcp.basic; additional tool scopes are granted only through scope step-up. A personal bearer token receives a fixed, server-owned developer-alpha scope bundle that remains constrained by current user and module policy. This does not claim granular scope selection for personal tokens.
An external client does not receive the complete internal catalogue. Every module publishes a separate allowlist of MCP tools. The mere existence of an internal AI command does not make it external. The server revalidates granted scopes and the account's current rights when a tool is used. If a right is revoked, previously granted access must not become a permanent exception to policy.
| Criterion | Internal AI | External MCP |
|---|---|---|
| Primary user | An employee inside Sapphire I.C.D.S. | An external AI client or work environment |
| Context | Internal session, profile, and permitted corporate sources | Only data and tools published to the external environment |
| Tool policy | AI policy, group rights, and session selection | Explicit publication, scopes, and current rights |
| Purpose | Agent work inside the platform | Integration of compatible external clients |
Internal memory is not published externally
The most important boundary concerns corporate context. Instructions, internal memory, and the knowledge base belong to the built-in AI. They must not appear in the external tool list or be returned to an external client simply because that client has authenticated successfully. Authentication proves identity and granted rights, but it does not cancel the principle of minimum publication.
This decision reduces the risk of accidentally disclosing management rules, accumulated context, and internal materials. If the organisation genuinely needs an external workflow with a particular data set, it should design a dedicated tool with a clear schema, validation, and scope rather than expose a general internal source.
Shared business logic can still be reused
Separate environments do not have to duplicate implementation. A module may route internal and external calls to one tested business operation, retaining its transactions, validation, and domain restrictions. Before that happens, the external adapter filters the command list, validates arguments, binds the call to a trusted identity, and applies additional publication limits.
This creates an important engineering balance. The company does not maintain two diverging versions of an article or Roadmap update, but it also does not treat an internal function as automatically safe for external use. Logic is reused; trust is not.
Errors and results also have boundaries
External MCP returns a result as minimum-trust data. Even a successful server response does not turn text inside the result into an instruction for the external agent. A tool error is isolated as the result of that specific call and must not open access to neighbouring operations. Changes use separate permissions, and especially sensitive actions may remain unpublished altogether.
In the internal environment, the model also receives structured results, but an employee interface may display only a safe projection of activity. Detailed arguments and technical data require a separate right. Both environments are therefore observable, while each discloses only the level of information its audience needs.
Where each option belongs
- Internal AI is appropriate for employees working in the administrative and operational surfaces of Sapphire I.C.D.S. who need platform context.
- External MCP is appropriate for connecting compatible AI clients, developer tools, and automated work environments.
- Both environments can coexist: the organisation does not have to replace the built-in agent with an external service or do the reverse.
- Verified integration currently means the ChatGPT connection described above; it does not establish general availability for other external clients.
A practical architecture rule
Before publishing an operation, a technical leader should answer four questions: does it need internal context, who owns the session, what minimum data is required, and how is access revoked? If the operation depends on private memory or internal instructions, it remains within the built-in AI. If an external scenario is justified, an explicit MCP contract is created with a constrained schema and separate policy.
For a business owner, the separation means that external AI services can be used without surrendering the independence of Sapphire I.C.D.S. For security teams, it creates intelligible publication boundaries. For developers, it enables reuse of native business logic without mixing contexts. Internal AI and external MCP therefore complement one another, but they should not become one indistinguishable channel.