Skip to Content
Control & ConfigurationSecurity Classifications

Security classifications

Security classifications label how sensitive data in a chat may be. Steinkauz uses them in two places: per provider (in settings) and per conversation (in the chat UI). The server enforces that your selected provider is at or above the conversation’s required level before any message is processed—so higher-sensitivity threads are not sent to providers you only marked for lower sensitivity.

Available levels

These levels are fixed in the product (see Settings → Providers for your account):

  • Public — Non-sensitive; any configured provider at this level or higher can be used when the conversation allows it.
  • Internal — Internal-use data; restrict to providers you trust for internal data.
  • Confidential — Confidential data; only providers you set to Confidential or Secret (or higher in ordering) can run the chat when required.
  • Secret — Highest sensitivity; only providers explicitly set to Secret can satisfy a Secret requirement.

Ordering is strict: Public < Internal < Confidential < Secret. A provider “meets” a requirement if its classification is the same or higher than the conversation requirement.

Per provider (Settings → Providers)

Each integration (including the AI Gateway as a single provider) has its own security classification. That value describes how much you trust that integration for sensitive data. It is stored with your provider settings and is not overridden by individual chats.

  • BYOK: Set classification on each BYOK provider you enable. See BYOK provider configuration.
  • Gateway: The Gateway entry has one classification for “requests that go through Gateway.” It does not assign different classifications to each backend model vendor; for that level of control, use provider order, zero data retention, and BYOK as described in Gateway provider configuration.

Per conversation (chat)

While chatting, open the shield control next to Share (not read-only or archived threads). There you can see:

  • The conversation requirement — the minimum classification this thread currently demands.
  • Your policy:
    • Auto (default): The requirement can go up if you send a message using a provider with a higher classification than the thread’s current floor. It does not go down just because you pick a weaker provider in the UI; weaker providers are blocked until you lower the requirement (with confirmation) or switch back to a strong enough provider.
    • Manual: You fix the requirement to a chosen level. The provider / model picker only lists providers that meet that level.

The shield’s color reflects the conversation requirement, not only the provider you have selected in the footer.

What the server does

On every chat request, Steinkauz:

  1. Reads the conversation’s stored requirement and whether policy is auto or manual from the database (not from tampered client fields for existing threads).
  2. Compares your selected provider’s classification (from your saved settings) to that requirement.
  3. Rejects the request if the provider is too weak, with an error you can act on (change provider, or lower the requirement in the shield popover when appropriate).

New threads: the first message sets the initial row using your policy (Auto uses the first provider’s level; Manual uses the level you chose).

Why this matters

Together, provider labels and conversation policy give conversation-level control: once a thread’s requirement has moved up (for example in Auto after using a Secret-classified provider), you cannot accidentally continue that same thread on a Public-classified provider without explicitly lowering the requirement in the chat UI (with confirmation when that is a downgrade).

Last updated on
Provider ConfigurationZero Data Retention