Security
AI security model
This document is written for security researchers and reviewers assessing the security model of the 21RISK AI implementation. It describes the trust boundaries, authorization model, data egress, and the controls around the AI assistant. For the end-user perspective, see the AI assistant guide .
Architecture and trust boundary Architecture and trust boundary
The AI assistant is built on the Vercel AI SDK, and all model calls are routed through the Vercel AI Gateway . 21RISK never calls model providers (Anthropic, OpenAI, Google, etc.) directly — the gateway is the single egress point for inference traffic and handles provider routing and usage accounting.
- The gateway API key is stored in our secrets manager and injected server-side at request time. It is never exposed to the browser.
- Inference requests are constructed and sent server-side only; the client never holds provider credentials or talks to providers directly.
- The set of usable models is an explicit server-side allow-list; per-organization administrators further restrict which models are enabled.
Authorization model Authorization model
The core principle: the assistant never exceeds the permissions of the identity it acts for.
- User chat runs with the requesting user's own permissions. Any tool the assistant invokes (searching capabilities, reading documentation, or executing a supported procedure) is executed in the user's authorization context — it can only read or change what the user could read or change directly.
- AI agents are a distinct identity type with their own separately configured authorization. An agent acts with its permissions, not those of the person interacting with it, and the agent's authorization is built from the same effective-permission model as a human user.
- Tool execution goes through the same server-side RPC layer as the rest of the platform: input is schema-validated, permissions/scopes are enforced, and procedures marked as hidden are rejected.
Because authorization is enforced server-side on every query and mutation, prompt-injection or a manipulated model cannot escalate beyond the acting identity's permissions — the model can only request actions, which are then authorized independently.
Access control Access control
Access to AI chat is gated at two independent layers, both enforced server-side:
| Layer | Control |
|---|---|
| Organization | AI must be enabled for the organization |
| User | The user must hold AI chat access, granted directly or via a user group |
The chat entry point is hidden in the UI when a user lacks access, and — independently — the chat endpoint rejects requests from users without an effective grant. Effective access is computed into a dedicated table from the underlying grants and group memberships, and recomputed whenever a user's status or group membership changes. Granting and revoking access requires the IT-admin permission.
Data egress — what leaves the platform Data egress — what leaves the platform
For each request, only the data required to answer it is sent to the gateway and the selected provider:
- The conversation messages (including files the user attaches in chat).
- A system prompt identifying the assistant, the acting user, and the current tenant.
- The schemas of the tools the assistant may call.
The provider does not receive the wider 21RISK database. Any additional data only enters a request if the assistant invokes a tool that the acting identity is authorized to use, and the result is returned within that authorized scope.
Tenant isolation Tenant isolation
All AI data is scoped to the organization (tenant). Conversations and messages are stored under the tenant, model/usage accounting is per-tenant, and access grants and effective access are evaluated per (user, tenant) . The same row-level tenant scoping that governs the rest of the platform applies to AI data.
Cost and abuse controls Cost and abuse controls
Inference cost is recorded per message (derived from the gateway's reported usage, in EUR) and capped at two levels:
- An organization-wide monthly spend limit that blocks further requests once reached.
- Optional per-user / per-group monthly limits attached to access grants.
These limits bound both cost and the blast radius of a compromised or misused account.
Auditability Auditability
Granting, updating and revoking AI access are recorded in the platform activity log, and per-message usage and cost are retained for review. This provides an audit trail of who was given access, by whom, and how the assistant has been used.
Data at rest and retention Data at rest and retention
Conversations, messages, token counts and cost metadata are stored in the 21RISK database within the customer's tenant. Conversations support deletion. Data is retained per the customer agreement.
Sub-processors and contractual terms: Inference is processed by the Vercel AI Gateway and the underlying model providers. The authoritative list of sub-processors and the contractual data-handling terms (including provider training and retention commitments) are governed by the relevant agreements — see the 21RISK sub-processors documentation and Data Processing Agreement rather than relying on this overview for legally binding details.
Summary Summary
- Single inference egress point through the Vercel AI Gateway; no direct provider calls; gateway credentials are server-side only.
- The assistant operates strictly within the acting identity's permissions, enforced server-side; agents have their own scoped authorization.
- Chat access is gated at the organization and user level and enforced on the server, not only in the UI.
- Only request-scoped data leaves the platform; the provider never receives the wider database.
- Tenant isolation, per-message cost accounting, organization and per-grant spend caps, and an activity-log audit trail apply throughout.