Governance for regulated AI

Set organization-scoped policies, allocate Budgets, enforce routing rules before inference, and review configuration changes and AI interactions.

D×E routing policy

Set data sensitivity (D-class) defaults for messages and files, assign provider environment classes (E-class), and block incompatible chat requests before inference.

Explore data routing →

Native Tool modes

Choose how much human oversight each Native Tool needs in chat, from approval before execution to autonomous runs.

Explore Native Tool modes →

Budgets

Cap spend per member or API key and per provider. Organizations allocate the System Gateway pool; BYOK stays uncapped until you set optional caps.

Explore Budgets →

Usage and audit visibility

Inspect inference activity across chat and API, review configuration audit events for policy and provider changes, and trace administrative actions.

Explore audit visibility →

Routing

Data routing policy

Choose which provider environment classes may handle each data sensitivity level. Incompatible chat requests are blocked before inference runs.

Interactive demo. No data is saved.

Docs

Data sensitivity defaults

Message and file sensitivity can be configured separately. When a request includes a file, Steinkauz uses the stricter effective sensitivity.

Default sensitivity for message content in chat before routing is evaluated.

Pre-selected sensitivity for uploaded files. Attachments can raise the effective sensitivity above the message default.

Provider

Each provider has a provider environment class (E-class). Pick one to simulate a request.

Simulate a request

Choose whether the request includes a file attachment to see how effective sensitivity is computed.

Effective sensitivity: D0: Public

D×E routing matrix

Configure which provider environment classes may handle each data sensitivity level. Toggle cells to allow or block combinations.

AllowedBlocked
Data sensitivityE0: UnclassifiedE1: Public managedE2: Enterprise managedE3: Private cloudE4: Customer hostedE5: On premise
D0: Public
D1: Internal
D2: Confidential
D3: Restricted
D4: Critical
This request would be allowed at D0: Public.

The full D×E matrix applies to chat. API keys enforce a separate minimum provider environment floor (E-class only).

Native Tools

Native Tool operation modes

Not every Native Tool carries the same risk. Match human oversight to what the tool can do.

Why operation modes matter

Native Tools can read external data, generate images, or trigger side effects. Operation modes let organizations decide whether a tool runs autonomously, stays visible in chat, or requires explicit approval first.

HITL

Human in the Loop

The user must approve the tool call before it runs and can edit parameters before execution.

HOTL

Human on the Loop

The tool runs without a prior approval gate, but the user can see what happened in chat and intervene if needed.

HOOTL

Human out of the Loop

The tool runs autonomously without chat visibility, appropriate only for low-risk, well-scoped automation.

Configure per tool

Owners and admins set an operation mode for each enabled Native Tool. Members operate within those boundaries in chat.

Web search

Human on the Loop

Image generation

Human in the Loop

Platform API requests auto-execute tools without HITL approval. Chat is where operation modes apply.

Budgets

Budgets under one control plane

Budgets govern how much each member or API key may use on each provider—in chat and on the Platform API alike.

  • Caps are per member or API key × provider, not a single global limit
  • On Gateway plans, paid seats fund a System Gateway pool that admins allocate across members and API allocation—raising one cap reduces what's left for others
  • Chat and the Platform API share the same Budget rules
  • BYOK stays uncapped by Steinkauz until you set optional Budgets; Individual workspaces and organizations both configure caps in Settings → Budgets
Settings → Budgets

Static preview of pool allocation and per-subject caps.

System Gateway pool

This period
Pool
$120.00
Members
$90.00
API allocation
$30.00

Subject × provider

Alex (member)

System Gateway
Cap: $45.00Remaining: $18.40

Jordan (member)

System Gateway
Cap: $45.00Remaining: $31.05

Alex (member)

Azure OpenAI (BYOK)
Cap: Optional — unsetRemaining: Uncapped

Preview only. Configure live Budgets in the app under Settings → Budgets.

Audit

Audit built in

Two complementary surfaces: AI inference activity and configuration changes.

Quick metadata shows provider, model, tokens, response time, and cost for this reply.

Per-message transparency

See which model you used, what it cost, and inspect metadata on every reply. Then follow the full trail in searchable activity history.

Click the info icon for quick metadata on a reply.

AI inference activity

  • Per-message metadata in chat: provider, model, tokens, cost, latency, and quick routing context
  • Dedicated activity page for searchable requests across chat and API with API-key attribution
  • Step-level drill-down into model calls, tool executions, timing, and exportable history
  • Unified usage and cost visibility for reconciliation and review
Activity details

Every inference request, whether chat or API, appears in a searchable activity log with drill-down detail.

Chat
SuccessUser messageD2: ConfidentialE3: Private cloud
Modelclaude-opus-4-6
ProviderAnthropic
Tokens1,650
Cost$0.00234
Duration2.3s
Steps3
Request IDreq_8f2a…c91d
Tool
web_searchHOTL

Quick metadata is available per message in chat. Open Settings → Usage for the full activity page with filters, export, and step-level drill-down.

Filter by source, model, API key, or routing class. Inspect model steps, tool calls, timing, and cost attribution.

Configuration audit log

Every meaningful policy or provider change leaves a trace for review.

Routing policyToday, 09:14

Blocked D3: Restricted → E1: Public managed after matrix update.

Data sensitivityYesterday, 16:42

Default file sensitivity changed from D1: Internal to D2: Confidential.

Tool policyYesterday, 11:08

Image generation operation mode changed from HOTL to HITL.

ProviderMon, 08:55

Azure OpenAI provider environment class updated to E3: Private cloud.

Routing, tool, provider, and membership audit logs are available in organization settings.

Configuration audit

  • Routing policy audit for matrix changes, blocked routing attempts, and sensitivity downgrades with reason
  • Tool policy audit for operation mode and enablement changes
  • Provider audit for creation, updates, deletion, and environment-class changes
  • Administrative audit for membership and billing-sensitive organization changes

Govern AI without losing agility

Set policies in the control plane, then use the same stack through API access.