Licensed to be used in conjunction with basebox, only.
// security
Connectors
Applies to
Product: Demo · Cloud · Server · Audience: Security / Compliance reviewer
Security properties all connectors share: credentials per user, credentials stored write-only, approval per app, the access control gate in AISRV, egress allowlist, write tools off by default. Connectors (MCP servers) link basebox to your own systems – wiki, ticket system, e-mail, business systems. The principle: basebox manages no foreign permissions; it makes sure every request reaches the target system as the right user, and the target system decides.
The gate
Before the model even sees a tool, AISRV checks three things and forms the intersection:
| Check | Source | Without it |
|---|---|---|
| Organization has enabled the connector | Administration | The connector does not exist for the organization |
| App exposes the tool | The app's tool settings; write tools individually | The tool is not offered to the model |
| User has enabled the connector and – where needed – stored credentials | User settings | The tool is not offered to the model |
Only then does AISRV insert this user's credentials and call the connector; the connector passes them unchanged to the target system. Sequence diagram: MCP authorization flow.
Guarantees
| Property | Implementation |
|---|---|
| Isolation per user | Credentials stored separately per user and loaded per request by user identifier |
| No shared admin token | basebox holds no privileged token for all users; a service account is acceptable only for generally accessible content |
| No credential caching | Fresh from the database per request; not in process memory across requests |
| Target system enforces permissions | No filter layer, no copy of permissions; 401/403 from the target system become visible tool results, no fallback |
| Write access off by default | Per app; the administrator exposes write tools individually |
| Confidentiality of credentials | Stored write-only; administrators do not see them; never in production logs |
| Immediate revocation | Revoked token or deactivated account → next call fails; no session, no cache |
| Egress allowlist | Every connector reaches only its declared target hosts; the MCP gateway blocks everything else |
| Audit | Tool calls in the audit log with metadata (organization, user, tool, result, timestamp) |
What flows
In a tool call, the target system receives: the call's parameters (which the model forms from the conversation – for example a search term or a ticket number) and the user's credentials. Back comes the target system's result, which serves the model as context and thus enters the answer – and on the AISRV → inference path reaches the inference hardware (Data flows). With write tools, changes occur in the target system under the user's identity.
Limits you should know
- Knowledge bases are different. Documents in an app knowledge base are visible to everyone who may use the app – there is no per-user permission check there. Sensitive content belongs behind a connector with personal credentials, not in a knowledge base.
- Web search + internal connector in the same app is the exfiltration path – separate them (Web search).
- What the user sees, the model sees. A connector makes accessible to the model what the user may read anyway – no more, no less. Tool visibility per group is announced.
- Own connectors are subject to the same rules, but you are responsible for their implementation – checklist under Permissions.
- Organization-wide credentials (for example a target system's API key stored by the administrator) are a deliberate exception to the per-user principle and acceptable only for content all users of the app may see (Connector authentication).
Per deployment model
- Cloud: basebox provides the connector services; they reach target systems in your network from the Noris data center – you allow exactly one path per connector (Network connectivity). basebox connects your own MCP servers in coordination with you.
- Server: connectors run as separate deployments in the cluster (MCP connectors with Helm); target systems are mostly internal; the egress allowlist complements your firewall.
- Demo: to try out the gate behaviour with test systems.
For the review
- List of enabled connectors with target system, user group, read/write permissions and credential model (per user / organization-wide).
- Write tools: justification per app in which they are exposed.
- Web search in a separate app, apart from internal connectors.
- Review the audit log for tool calls; exports to the SIEM (SIEM integration).
Next step: Audit & logging