◆ SECURITY

We don’t get access to your cluster

Opsy is designed so the integration doesn’t require granting access to your cluster. Below – how it’s built, what we store, and in what form.

No inbound connections into the cluster Local model, no external AI services Install into an air-gapped perimeter Full action log kubeconfig is never sent to us

Access architecture

The agent lives inside your perimeter and initiates outbound HTTPS requests for tasks. It runs kubectl, helm and git locally, in your cluster. The agent has no Service and no open ports: it cannot be reached from the outside.

YOUR CLUSTER
agent (ServiceAccount)
kubectl · helm · git - locally
no Service, no open ports
outbound HTTPS
no inbound
OPSY CONTROL-PLANE
task queue · policy · audit
the agent polls the queue itself
initiative always stays on your side

Data protection

In transit
All traffic over TLS. The connection is established by the agent from inside your perimeter; inbound connections aren’t needed.
At rest
Sensitive fields are encrypted at the application level: Git tokens, kubeconfig, values from the deploy configuration. API keys are stored as hashes; the key itself is shown once.
Perimeter isolation
Log and incident analysis runs on a local language model. Your data is never sent to external AI services.

What data is stored where

No vague words: here’s the full list of what reaches our side, and in what form.

STORED WITH US
Repository and branch links
Cluster, environment and namespace names
Delivery configuration
Action log and task statuses
User contacts
STORED ENCRYPTED
Git access tokens
Variable and secret values from the deploy configuration
NEVER REACHES US
kubeconfig and cluster credentials: the agent runs under its own ServiceAccount
Source code: the build runs in your CI
Plaintext API keys: hashes only
Cluster contents: requests are run by the agent on your side
STORAGE AND DELETION
The action log is kept for 90 days, then rotated · Organization data is deleted after contract termination · You can request an export of your configuration at any time

Control and audit

RBAC by namespaces
Who can ship where – you decide.
Prod approval
Critical changes go through a human, not automatically.
Blocking SAST gate
Critical stops the deploy. If the check fails or is unavailable – no rollout. Only the organization can loosen it.
Action log
Who, what, when and with what result.
Disable the agent at any time
The agent is revoked by an org admin and removed from the cluster.
Roles from your Git
Permissions are inherited from GitLab, GitHub or Azure DevOps.

Continuity

Dockerfile and CI - in your repository
They’re committed to you and stay yours: ordinary readable files that keep building the image without us.
The agent comes off with one command
The image is deployed in your registry and removed from the cluster. No traces left in the infrastructure.
Install into your perimeter
Opsy installs entirely on your side, including moving images into an air-gapped perimeter. A connection to our infrastructure isn’t required.
Responsible disclosure
Found a vulnerability – write to us. We reply within a business day and don’t pursue researchers who acted in good faith.
security@deostech.kz

FAQ

Does the AI see our code and logs?
Analysis runs on a local model: it works on our side, and when installed in your perimeter – on yours. Your data is never sent to external AI services in any mode.
Do you need our kubeconfig?
No. All cluster access is done by the agent inside your perimeter under its own ServiceAccount – kubeconfig is never sent to us. You can only upload it when installing Opsy into your perimeter, where it stays.
Does Opsy replace Vault?
No. Opsy is not a secrets manager: we don’t manage their lifecycle or rotate them. Values specified in the deploy configuration are stored with us encrypted and available only to your organization.
Do you have SOC 2 or ISO 27001?
Not certified yet. The security model rests on architecture: no cluster access is granted, the build runs in your CI. This is verifiable by your security team directly. We’ll pass your internal checklist and answer in writing.
What happens if the check is unavailable?
The deploy won’t pass. The gate is fail-closed: no response – no rollout. Only your organization can allow passage when the check is unavailable, in its settings.
What permissions does the agent need in the cluster?
The agent runs under a ServiceAccount with the permissions you set yourself. We send the full list of required permissions before installation.
Can it be installed fully offline?
Yes. Air-gapped installation is supported, with images moved into your registry and an offline license, without a connection to our infrastructure.
Who owns the rights to Opsy?
The rights to the product belong to DEOSTECH, authorship registered in the Republic of Kazakhstan. The client receives a usage right under a license agreement.

Documents for your security team

The security model, the list of required agent permissions, the contract and the data processing agreement – sent on request.

Request documents Delivery review, 60 min