AI Security
How TotalApp protects AI traffic and the data behind it — the data path, transport and session security, prompt hardening, egress control, file handling and tenant isolation.
Overview
AI adds new ways for things to go wrong: instructions hidden in text, personal data sent to a third party, one tenant reaching another’s records, credentials ending up in the browser. This page describes the technical protections TotalApp puts in the way of each. The rules your organization chooses — permissions, blocked topics, masking policy, audit export — are in AI Governance & Access; this page covers how they are enforced and what protects the platform underneath.
| Risk | Protection | Section |
|---|---|---|
| Credentials exposed to the browser | Provider keys exist only on the server | The AI data path |
| Traffic intercepted or session hijacked | HTTPS everywhere, short-lived signed tokens | Transport & session security |
| Instructions smuggled into a prompt | Input sanitization and injection detection | Prompt security |
| Personal data sent to a model provider | A single egress control point with masking | Data egress control |
| Unsafe uploads | Server-side type allowlists, text extraction without execution | Secure file handling |
| One tenant reaching another | Per-tenant storage with path containment, tenant taken from the token only | Tenant isolation |
The AI data path
Every call to a cloud model is made by the TotalApp server, never by the browser. Provider keys are read from the server’s environment and are not sent to the client, in responses or in error messages, so there is no key in the browser to steal.
| Path | Where your text goes |
|---|---|
| Local Ollama (chat or embedding) | Browser to your own machine. Nothing reaches TotalApp or a provider. |
| In-browser models | Processed inside the browser tab. Nothing leaves the device. |
| Cloud LLM, hosted embedding, rerank | Browser to the TotalApp server over HTTPS, then to the provider you chose. This is the path the egress controls govern. |
Choosing a local path is the strongest data-handling option: the text never leaves your environment.
Transport & session security
- HTTPS only. Responses carry a one-year HSTS policy that includes subdomains and is preload-eligible.
- Browser hardening headers. The app cannot be framed (clickjacking protection), content-type sniffing is disabled, referrer information is trimmed for cross-origin requests, and camera and microphone are limited to the app’s own origin while geolocation is off.
- Strict cross-origin policy. Cross-origin requests with credentials are accepted only from an explicit allowlist of TotalApp origins.
- Signed, short-lived tokens. Access tokens are signed with HMAC-SHA256 and expire after 15 minutes. They carry the tenant and role; the server takes the tenant from the token, never from a request field. Signatures are compared in constant time.
- Refresh without exposure. The 7-day refresh credential lives in an HttpOnly cookie that page scripts cannot read.
- Rate limiting. Requests are limited per client address and per route group, with tighter limits on expensive AI routes such as image generation.
Prompt security
Prompts are built from user text and from data pulled into the prompt, including text extracted from uploaded files. When Sanitize prompts is on, that text is cleaned before it is sent to a model:
| Layer | What it removes |
|---|---|
| Hidden characters | Control characters, zero-width characters and bidirectional-text overrides — invisible to a reviewer, readable by a model |
| Script blocks | Embedded script tags |
| Injection phrases | Five families: “ignore previous instructions” variants, requests to reveal the system prompt, jailbreak persona switches, fake system/assistant role lines, and chat-template control tokens |
- Strip or block. In strip mode a detected phrase is replaced with a visible marker and the request continues; in block mode the request is declined and never sent.
- What is rewritten. Only user-role message text. TotalApp’s own system instructions and earlier assistant turns are not modified.
- Same coverage everywhere. The cleaning happens at the transport layer, so it applies to every AI feature without each screen opting in.
A hardening layer, not a guarantee
Detection is pattern-based. It removes the well-known attack shapes and hidden-text tricks, but it cannot recognise every novel phrasing. Treat model output as untrusted text, which is how TotalApp uses it: answers are displayed, not executed. Production also rejects any request that tries to run the local command-line engine.
Data egress control (DLP)
All outbound AI traffic passes one control point on the server, before it leaves for a provider. There is no per-screen code to forget: the point sits on the three ways the server talks to model providers — direct provider calls, the shared HTTPS helper, and the model gateway.
- The request is matched against the AI endpoints the server uses (chat, embeddings, rerank). Anything else — for example a GitHub or Shopify call — is left alone.
- The tenant and user of the signed-in request are looked up, then that tenant’s policy (cached for a few seconds, off by default).
- Prompt text is sanitized and masked, blocked topics are checked, and the rewritten request is what is sent. A blocked request is never forwarded; the caller receives a policy error.
- The response is masked and checked the same way, then returned. Streamed responses pass through unmodified.
- If the audit trail is on, a metadata record is written in the background.
Personal-data detectors are validated, not just pattern-matched: payment cards must pass the Luhn check, IBANs the mod-97 check, and Turkish national IDs their own checksum. That keeps false positives low on ordinary numbers. The masking types and how to choose them are described in AI Governance & Access.
If the policy cannot be read
The guard fails open: if a tenant’s policy file cannot be read, the request is sent unmodified and a warning is logged on the server, so a storage problem cannot take AI features down.
Secure file handling
- Type allowlists. Uploads are accepted only for an explicit list of document and image types. The extension is chosen by the server from the allowed type, not copied from the file name, and anything else is rejected with an unsupported-type error.
- Size limits. Limits apply per upload type, for example 2 MB for profile photos; oversized files are rejected.
- Stored in the tenant folder. Uploaded files live in the tenant’s own storage and are never executed.
- Text extraction. Documents analysed with AI are parsed to text on the server and capped in length. That extracted text then passes through the same prompt controls as anything else, because the controls sit at the transport layer.
Tenant isolation
| Mechanism | How it works |
|---|---|
| Folder per tenant | Every tenant’s records live under their own folder, split by module. AI governance policy and audit files live in the same tenant folder. |
| Validated identifiers | A tenant ID must match a strict character pattern, and the resolved path must stay inside the tenants root, otherwise the request is refused as a traversal attempt. |
| Validated file names | Names with parent-directory segments or backslashes, or nested deeper than the module layout allows, are rejected. |
| Tenant from the token only | The tenant is read from the signed session token. A missing or invalid token returns an unauthorized error and never falls back to a default tenant. |
| Per-user data | Personal files live under a per-user folder whose name is sanitized from the user ID. |
| Administrator-only governance | Reading or changing the policy and exporting the audit trail require a tenant administrator. |
Boundaries today
Stating what is not covered is part of describing the protections honestly.
- Uploads are checked by allowed type and size; there is no antivirus or content-signature scanning engine.
- Prompt and response controls do not rewrite streamed answers.
- Controls apply to requests from a signed-in session, not to background jobs, and not to the local command-line engine (which production disables).
- Tenant records are stored as files on the server’s persistent disk; TotalApp does not add per-record encryption on top.
- Injection detection is pattern-based (see Prompt security).