Controlled AI Access to Business Tools

An isolated AI chat can prepare a letter or a summary, but its business value quickly reaches the limits of having no ability to act. To review a customer record, find material, update a route, or prepare a report, the assistant needs tools from the corporate system. That same access creates the main risk: the model must not receive more authority than the employee or independently turn data retrieval into a modification.

In Sapphire, AI access is built as a governed part of the platform. Existing business modules publish strictly defined operations, while the central AIControl framework manages which of them are permitted for the organization and individual groups. Employees see only the set available to them, and the server verifies the policy again for every call. The chat interface helps select a tool, but it is not the security boundary.

Three levels of control

The first level is the corporate catalog. An administrator enables only the tools that are ready for use in AI scenarios. The existence of a function in a module does not mean it automatically becomes available to the model. This makes it possible to introduce AI in stages: begin with safe search and analytics, add draft preparation after reviewing the processes, and only then connect selected modification operations.

The second level is group permissions. Marketing, logistics, editorial teams, and customer support may work with different modules and actions. Permission to use AI does not by itself open every business function. The resulting set is formed from global policy, group permissions, and the current state of the tool. If an employee loses a permission, AI also loses the corresponding capability.

The third level is the selection made for a particular work session. A user can narrow the available set for the task, for example by leaving only knowledge-base search and catalog reading enabled. The user cannot expand permissions beyond the limits established by the administrator. Selected essential service tools can be maintained centrally so that the workflow remains stable.

Reading, modification, and critical operations

For a business, it is essential to distinguish obtaining information from changing the state of the system. Sapphire tools describe the nature of an operation, while external integrations separate areas for reading, writing, and deletion. A client may additionally request confirmation before modifications, but the final decision always remains on the server side: whether the account, group, permission, and access scope are valid at that moment.

Modification operations are performed within the boundaries of the business module. The model does not receive direct universal database access and does not construct arbitrary commands. It invokes a specific action with verifiable parameters: create a record, update permitted fields, change a status, or obtain a report. If validation fails or the module rejects the operation, the refusal applies to that call and does not disable the assistant's other capabilities.

This contract supports not only security but also quality. A tool returns a structured result, allowing AI to correct incomplete parameters, ask the operator for clarification, or continue the task in another safe way. Repeated failures are subject to limits that prevent an endless cycle of attempts, while a normal response to the user remains available.

Internal assistant and external connections

Sapphire supports an internal AI framework and separate external access to explicitly published tools. They use common business permissions but are not merged automatically. A tool available to the built-in assistant does not become external simply because it exists. The external framework requires separate publication and its own policy. The external MCP capability is currently in developer alpha, and ChatGPT is the only integration currently claimed as verified.

An OAuth connection starts with the minimal mcp.basic scope and expands through scope step-up when the client requests an additional tool. In the current developer-alpha implementation, a personal bearer token receives a fixed, server-owned scope bundle; actual execution is further constrained by the user's current permissions and module policy. Granular personal-token scope selection is not currently offered. A user or administrator can review safe connection information and revoke the connection without exposing active credentials.

This approach is useful for integrating the corporate platform with approved AI clients: the organization does not grant one application permanent universal access. Each connection is tied to an owner, current permissions, and a limited scope. A role change or permission revocation stops further use of the relevant operations.

Observability without unnecessary disclosure

Execution of an AI task retains the relationship between the request, the invoked tool, and its result. This helps investigate disputed changes, evaluate automation quality, and improve work instructions. An ordinary user sees a safe description of the activity, while detailed arguments and technical results are available only to a role with separate permission.

Data received from tools is treated as data, not as new system-level instructions for the model. Governing instructions are defined in centralized profiles and policies. This separation reduces the risk that text from an external document, record, or web page will try to alter the boundaries of behavior established by the organization.

Implementation scenario

1. Identify processes in which AI should only find and summarize information.
2. Enable a limited set of tools for a pilot group and test them on real tasks.
3. Add write operations only where process owners and outcome criteria are clear.
4. Separate permissions by group and let users narrow the set further for a session.
5. Regularly review the call log, refusals, and the quality of prepared changes.

As a result, AI in Sapphire operates not as a privileged robot alongside the corporate system, but as another governed participant in the process. It uses the employee's current identity, a limited catalog, and the rules of the relevant module. This enables practical returns from automation without trading governance for speed.