Security at Skris

Skris is designed to run on-premises, in a private cloud, or inside a customer VPC. It can operate as a focused service on a VM or bare metal, as Docker workloads, or as an internal Kubernetes workload behind the organization's existing ingress, secret management, network, and observability controls.

The deployment model lets customers choose the network boundary, outbound routes, storage, regions, providers, and operational access appropriate to their environment.

Applications, people, teams, and agents connect through organization-issued Skris keys. User API keys are stored as hashes, while upstream provider credentials are encrypted and remain centrally managed inside Skris instead of being distributed to end-user tools.

Each governed request is evaluated before it reaches a selected cloud, private, or local model. Access, rate, token, budget, and inline text rules can produce allow, warn, redact, or deny outcomes.

Approved instructions and transformations can be applied before routing, while model aliases help prevent clients from bypassing administrator-owned provider and model choices.

Skris separates live request processing from optional content retention. Raw prompt and response capture is off by default; an organization may explicitly enable bounded, encrypted capture with retention controls where a workflow requires it.

Operational events—such as identity scope, route, usage, cost, and policy outcome—can be recorded without turning Skris into a central warehouse of prompt content.

Administrators can use operational records to understand model access, routing decisions, policy outcomes, consumption, cost, and performance. Hash-chained audit exports are designed to support internal review and evidence workflows.

Customers remain responsible for defining appropriate access, monitoring, export, and retention procedures around their deployment.

Security depends on both the product and the environment in which it runs. Skris provides control points, but the customer remains responsible for infrastructure hardening, identity integration, secret rotation, network policy, backups, monitoring, administrator access, provider configuration, and incident response.

Specific architecture, availability, compliance, and assurance requirements should be validated during a technical review. This page is a security overview, not a certification or guarantee that a deployment meets a particular regulatory framework.

Skris is under active development. Capabilities, deployment patterns, and assurance materials may change as the product matures. Current behavior and controls should be confirmed against the version evaluated for your organization.

We do not currently present SOC 2 or ISO 27001 certification claims on this website. Where independent assurance or formal compliance evidence is required, include it in the evaluation criteria for discussion.

If you believe you have found a vulnerability in a Skris product or this website, send a clear description, affected component, potential impact, and reproduction steps to our security address. Do not access, change, download, or retain data that does not belong to you, and avoid actions that could disrupt service.

We will review responsible reports and coordinate next steps. Please consult the Vulnerability Disclosure Policy before testing or publishing details.