01
Govern
Set approved models, access rules, usage policy, and data boundaries.
Enterprise AI Control Layer
One governed route for enterprise AI.
Skris is an on-prem AI gateway and control plane between your people, applications, agents, and AI providers. It applies organizational policy before each request reaches a cloud, private, or local model.
Input
People · apps · agents
Skris
Policy · context · routing
Approved AI
Cloud · private · local
The operating model
More than access to AI. Control over how AI is used.
A single gateway gives leadership and platform teams one place to apply the controls they already expect from enterprise infrastructure—without forcing every application onto one model or provider.
02
Secure
Inspect text before provider egress and allow, warn, redact, or deny by policy.
03
Contextualize
Apply approved instructions and context resolved from the available identity, application, team, workflow, language, permissions, and risk metadata.
04
Orchestrate
Route across cloud, private, local, and OpenAI-compatible providers through model aliases.
05
Observe & optimize
Understand usage, cost, latency, policy outcomes, and routing decisions.
Before provider egress
Every request follows the same governed path.
Applications keep a familiar API experience. Skris adds the policy and evidence layer inside your environment.
01
Identify
User, application, team, key, or agent.
02
Evaluate
Access, data policy, usage, and budget.
03
Route
Approved provider, region, and model.
04
Record
Outcome, usage, cost, and audit evidence.
Customer-controlled deployment
Run the control plane inside your trust boundary.
Deploy Skris on-premises or in your VPC. Provider credentials are encrypted centrally, user keys are hashed, and raw prompt capture remains off by default.
Infrastructure fit
Deploy with the runtime your operations team already manages.
Skris is designed for customer-controlled compute. Place it inside the network boundary that already governs application traffic, secrets, storage, and outbound access.
Deployment locations
VM or bare metal
Run the lightweight Go gateway as a single service, with SQLite as the default database for focused deployments.
Docker
Package the gateway and supporting interfaces as repeatable workloads inside an on-premises network or customer VPC.
Kubernetes
Operate Skris as an internal cluster workload behind your existing ingress, service, secret, and observability controls.
On-premises Private cloud Customer VPC Sovereign environment
Private footprint
A lightweight Go gateway with SQLite by default for focused deployments.
Provider choice
OpenAI, Anthropic, OpenRouter, local models, and other compatible endpoints.
Central credentials
Keep provider secrets out of user tools and revoke access centrally.
Cost control
Apply rate limits, token limits, budgets, and accounting by scope.
Designed to fit existing AI workflows
OpenAI-compatible applications, coding agents, and IDE clients can connect by changing their base URL, API key, and model alias. Skris supports common chat, response, streaming, and tool patterns without distributing upstream credentials.
Applications Coding agents IDE clients Internal tools Employee chat
Inside the platform
A gateway, policy system, and operating layer in one deployment.
The components remain separated by responsibility, while administrators manage them through one customer-controlled platform.
AI Gateway / API
The OpenAI-compatible request entry point for applications, coding tools, agents, and employee experiences.
Policy and DLP
Evaluates access, usage, and inline text policy before an approved request reaches an upstream model.
Routing engine
Resolves model aliases, provider routes, fallback behavior, and the approved destination for each request.
Admin UI
Manages users, sessions, providers, model aliases, routes, policies, keys, and revocation.
Employee AI experience
A separate white-label chat surface can provide governed access without distributing provider credentials.
Metrics and audit
Tracks operational performance, usage, cost, policy outcomes, and hash-chained audit exports.
Request and data lifecycle
Control is applied before the selected upstream sees the request.
Skris separates the live request path from optional content capture, so operational evidence does not require a central prompt warehouse.
01
Authenticate locally
A hashed Skris key identifies the permitted user, application, team, or agent. Upstream provider credentials remain inside Skris.
02
Inspect and decide
Access, rate, token, budget, and inline text DLP rules produce an allow, warn, redact, or deny decision.
03
Transform and route
Company instructions and approved request changes are applied before routing. Rich role, tenant, ACL, geography, and knowledge resolution is platform direction where not already integrated.
04
Account and prove
Usage, cost, route, and policy outcomes are recorded. Prompt capture stays off unless explicitly enabled with encryption and retention limits.
Administrative control
Operate providers and policy as enterprise infrastructure.
- Validate provider configuration before it becomes routable
- Prevent clients from bypassing administrator-owned routing and credentials
- Scope rate limits, token limits, budgets, and accounting
- Simulate policy decisions before applying them to live traffic
- Keep prompt capture disabled or configure bounded encrypted retention
- Export hash-chained audit records for internal review
Discuss your control requirements
Start with one AI workflow where control creates clear value.
We will map the request path, data boundary, provider choices, and evidence requirements with your team.
Helpful details