Start Building

Trust Center

You hold the keys.
We enforce the rules.

Routing LLM traffic through Kimss does not make us a second model vendor or a key custodian you cannot inspect. Customer provider credentials are envelope-encrypted and client-write-only. The default proxy records metadata and token counts — not prompt archives.

Full architecture Contact sales
Three pillars

Security & Trust Architecture

The same three guarantees we give CISOs, the public security assistant, and developers integrating the vaulted proxy.

Last updated: August 15, 2026

01 · The Vault

Cryptographic isolation

BYO provider keys in iam.custom_model_endpoints are AES-GCM encrypted with a per-secret DEK. Azure Key Vault wraps that DEK with RSA-OAEP-256. List/register/rotate never return decrypted keys.

02 · The Payload

Data transience

Default telemetry is correlation IDs, identity claims, tool names, and token counts — including stream_options.include_usage on the BYO hop. Full request/response text is not stored in the compliance pipeline.

03 · Governance

Better than Shadow AI

Hermis enforces Entra-authenticated sessions, a tool allowlist, and a mid-hop kill switch on routed agents. GatewayLogs on the compliance path are the Article 12–oriented trail — labeled gateway-verified, never confused with self-reported usage.

Envelope

How the vault wraps a key

Plaintext DEKs exist only in process memory during encrypt and decrypt. The KEK never leaves Azure Key Vault.

1 · DEKRandom 32-byte key per secret
2 · AES-GCMEncrypts the provider API key
3 · RSA-OAEP-256Key Vault wraps the DEK
4 · Postgresenc.v3 blob only

Scope: Connected Infrastructure BYO keys and MCP auth headers. Kimss SDK keys are hashed. Platform Foundry access uses managed identity — not this vault.

Integrations

Secure MCP Integration

Don't expose your internal databases to unmanaged AI. Connect your Model Context Protocol (MCP) servers to the Kimss gateway. We automatically map every internal tool call to a verified SSO identity, enforce Role-Based Access Control (RBAC), and maintain an immutable audit trail of every database query your AI makes.

Identity

SSO-mapped tool calls

Every MCP tools/call is bound to the signed-in Entra tid/oid before Kimss contacts your server.

Vault

Write-only headers

MCP auth headers use the same enc.v3 envelope as Connected Infrastructure keys. List APIs never return decrypted tokens.

Audit

Article 12 trail

Executions land in telemetry.ai_requests as gateway-verified events, plus the tenant audit log. Kill switch severs MCP mid-hop.

Routing Internal MCP Servers
For reviewers

Send this page to IT

Deep technical detail, client-write-only behavior, and caveats live in developer docs. Formal attestations remain under NDA.

Developer whitepaper Compliance architecture security@kimss.ai
FAQ

Questions IT asks first

If we route LLM traffic through Kimss, can you steal our provider keys?
No. Customer BYO provider keys are envelope-encrypted (AES-GCM plus Azure Key Vault RSA-OAEP-256) and client-write-only. List, register, and rotate never return decrypted keys. See the whitepaper.
Do you store our prompts and completions?
Default telemetry is metadata and token counts, not full request or response text. Conversation memory in Hermis or Foundry is product state, not a knowledge lake. Kimss does not train foundational models on your prompts.
Can you stop a rogue agent?
For traffic that routes through Kimss or Hermis, disabling the agent is an authoritative kill switch (HTTP 403), including mid-hop. Register-only agents that never call Kimss remain inventory until they report or route.
Where should IT start a security review?
This page, then the technical whitepaper. Formal attestations are under NDA via Enterprise.