Trust Center

What it connects to

The first question a private deployment gets, answered row by row below.

• Built inAt runtime the product never calls back to us: no licence server, update check, telemetry or crash reporting, and the console loads no external script, font or analytics. Our address appears in one place: pulling images at install time — the last row below.
• Built inOutbound destinations come from your configuration, a database row or a mounted file. A few carry a built-in default, each named in the table below.

A packet capture shows two things. At registration and heartbeat the agent probes the cloud metadata endpoints (169.254.169.254 for OpenStack-family clouds, 100.96.0.96 on Volcengine); they belong to your cloud platform, not to us. The console footer links to our website, which opens only on a click. The product never synchronises time, so licence expiry and login tokens follow the host clock. The inventory comes from reading the code, not from capturing traffic.

Who gets in, and what they may do

Accounts, authentication and permissions live in your deployment, held by your administrators. The console only hides controls; the backend decides every permission.

• Built inLocal account passwords are stored as bcrypt hashes. Minimum length, character classes, reuse history and maximum age are per-tenant settings; the defaults are 12 characters, four character classes, the last five passwords blocked and a 90-day maximum age. Consecutive failed logins lock the account — five failures and a 15-minute lock by default.
• Deployment settingMulti-factor authentication uses TOTP codes plus ten single-use recovery codes. A trusted device skips the prompt for seven days, five devices per user at most. The per-tenant policy is off, optional, administrators only, or everyone; there is no WebAuthn, SMS or email OTP.
• Deployment settingEnterprise identity covers OIDC, SAML 2.0, LDAP, Active Directory and RADIUS, all off by default. A provider activates only after its connectivity probe passes and a break-glass local administrator is in place. So far these protocols are verified in our own environment, with no acceptance against a customer directory. Integration with your directory gets proved in your environment first, then switched over.
• Built inPermissions are granted through roles, isolated per tenant and can be narrowed to a project. Watching a live session, exporting a recording and placing a legal hold are not among a tenant administrator's default permissions and need a dedicated role.
• Built inAutomation uses service-account API tokens: the server stores only a hash, a token's scopes must be a subset of its account's roles, and privilege-escalating permissions cannot be a token scope at all.
• Built inSensitive actions such as opening a remote session require an in-session step-up verification, bound to that session and that resource; an API token can never satisfy it.

One approval authorizes exactly one action

An approval binds to one action: this job, these targets, these parameters. All of it is re-checked when execution starts.

• Built inThe approval stores hashes of the job definition, parameters, command and the resolved target list. At execution the platform recomputes each one and refuses to run on any mismatch.
• Built inThe binding covers the resolved host list, not the selector. Changing the targets, the distribution path or the overwrite behaviour after approval invalidates it.
• Built inAn approval is single-use, expires, and can only be consumed by the person who requested it; approving your own request is refused by default. The window is 30 minutes by default and 15 for high-risk jobs, and a job definition may set its own between one minute and 24 hours.
• Built inA built-in command policy runs server-side: six rules refuse outright, seven route to approval. Interactive sessions apply the same rules at the Enter keystroke — keystrokes are relayed as they are typed, but the platform swallows that Enter and sends a line-kill, so a refused command never executes on the host. Five refused commands in one session trip a breaker: the platform closes the session and discards the rest of that input batch.
• Built inRisk level is re-derived server-side and can only be raised, never lowered by the caller. Unattended schedules and inspections may only use jobs the server classifies as low risk.
• Deployment settingBastion connections proceed after a recent MFA check by default. An enforced access policy can send every request, or only production and high-risk targets, to approval first. Kubernetes exec and log access always require a reviewer.

Boundary: command evaluation is platform-side, and three kinds of input are not fully visible to it — anything typed inside a full-screen program such as vim or top, the final command behind a Tab completion, which the remote shell resolves, and a command recalled from shell history with the arrow keys. The policy stops mistakes and high-risk commands; approval, recording and audit sit behind it. It will not stop someone determined to get around it.

AI advises; people decide what runs

AI diagnosis produces findings and suggestions; it never gets permission to act. The boundary is structural in the code.

• Built inThe AI module's only write into the job domain is creating a draft job definition. No AI endpoint executes anything.
• Built inAn AI remediation plan needs two different people to approve it, and the plan's author cannot approve their own. What approval produces is still a draft job that goes through the normal approval and execution flow.
• Built inA plan step may reference the product's built-in catalogue of operations, and referencing something outside it rejects the whole plan. Any step carrying a command that is not flagged read-only is marked as requiring approval, and dangerous commands in model output are forced to high risk. Either way the plan itself never runs.
• Built inThe verification receipt after a remediation is computed by a fixed rule and states only whether the alert recovered within a 30-minute window — never that the problem is fixed.
• Per environmentThe product bundles neither a model nor a key. With no model service configured, the AI features return “not configured” and no request leaves the platform at all. Assets, jobs and inspections never needed AI in the first place.
• Deployment settingThe model endpoint and the embedding endpoint are two separate settings, and both should point explicitly at your own gateway or private model. Give either a key without an endpoint and its compiled-in default is OpenAI's public API. We also operate a hosted model service. Point at it and the context used for diagnosis and retrieval reaches us — the one case where your data comes to us, and yours to decide.

Alert diagnosis scrubs first and keeps only hashes; knowledge-base answers are sent as written and retained in full. Automatic diagnosis of firing alerts is off by default.

What you can reconstruct afterwards

Audit records, session recordings and per-operation ledgers are kept separately: the audit record says who did what, the recording shows what was on the screen.

• Built inAudit records carry a request id, actor, tenant, source IP, user agent, module, action, resource, result and time. The application code has only an append path: no statement anywhere updates or deletes an audit row.
• Built inTokens, passwords and key-like fields are redacted on write and again on read. Inside an audit record, approval comments, stated reasons and ticket references appear only as a length and a hash; the text itself stays on the approval event it belongs to.
• Built inAn interactive session cannot start unless it is being recorded: WebSSH, SSH, Telnet, RDP, VNC and Kubernetes Exec are refused if the recording cannot be written. A recording is gzipped JSONL, chunked with a SHA-256 per chunk that is re-checked on read, and kept 30 days by default.
• Built inFile transfer, read-only database sessions, Kubernetes log reads and controlled web applications are not recorded; they write per-operation metadata instead — path and content hashes, size and result for a transfer; statement hash, row count and duration for a query.
• Built inEvery read of a recording is itself audited, including which part was read and whether a reason and ticket reference were supplied.
• Deployment settingThe runtime account can additionally be narrowed to INSERT and SELECT on the audit table by enabling the least-privilege database role at delivery; a default deployment uses the database owner account.
• Deployment settingAudit export (JSONL/CSV with a SHA-256 manifest) ships ready to use, governed by its own export permission, and caps one export at 10,000 rows, 20 MiB and a 366-day range. Signed recording export, object-lock storage, legal hold and SIEM forwarding are off by default and each has to be configured deliberately.

Boundary: a recording keeps what the host echoed back; the operator's own keystrokes are stored only as a hash and a byte count. The audit table itself has no hash chain or write-once protection, so anyone with direct database access can still alter rows. For tamper-evident retention, enable the object-lock storage above or hand the audit export to your own archive.

Where credentials and keys live

Administrators register the passwords and keys for target systems; the people using them never need to know them. The core service can seal that material but cannot open it.

• Built inTarget-system passwords, SSH keys and passphrases are stored as sealed envelopes: an AES-256-GCM data key wrapped with RSA-OAEP, bound to the tenant, credential, purpose and version.
• Built inThe core service holds only the encrypt-only public key; the decryption key lives solely in the separate access gateway process. The credential API is write-and-status only — there is no “reveal password” in the product.
• Built inRotation is an authorized, human-initiated task: the gateway generates the new secret itself, applies it to the target, verifies the login and rolls back to the previous secret if verification fails.
• Built inBastion SSH connections verify the target against exactly one registered host key. If the host key changes the connection aborts, an administrator has to confirm it, and both fingerprints go into the audit trail.
• Deployment settingAgents connect over mutual TLS. At enrolment the host uploads only a certificate request and its private key never leaves the machine. Certificates default to 90 days and renew themselves once under a third of the lifetime remains. Revocation takes effect immediately through a server-side ledger.

Boundary: keys are files mounted by the deployment. There is no KMS, HSM or external secret-manager integration, and no key-rotation routine. The platform database as a whole is not encrypted — only credential material and token seeds are sealed — so disk and backup encryption come from your environment.

The agent on a managed host

An operations platform necessarily holds high privilege. The agent's identity, ports, collection scope and uninstall residue are all below.

• Built inThe agent listens on nothing; every connection is dialled outbound to the platform's agent gateway (gRPC, 9090 by default). Managing a host requires no inbound port on that host.
• Built inThe default heartbeat reports host self-description only: hostname, operating system and architecture, machine id, non-loopback IPv4 addresses, CPU/memory/disk size and the agent version. It does not read account lists or collect process inventories.
• Deployment settingThe job execution channel is off by default on the platform side: until an administrator switches it on, no job can dispatch a command to a host, so you can enrol, inventory and inspect first. Interactive remote sessions (WebSSH) are a separate channel, governed by permissions and approval rather than by that switch.
• Deployment settingThe default service runs as root — a recorded product decision: the execution plane stays privileged, and the constraints sit on the platform side, in permissions, command policy, approval binding and audit. The same package ships a restricted non-root profile, at the cost of privileged operations failing on the host.
• Built inThe agent fetches no upgrade from the internet or from us. The artefact comes from your own platform, against a short-lived credential it issues. The binary is replaced only after its SHA-256 and Ed25519 signature verify and a health check passes. A rollback copy is kept, and restored automatically if the heartbeat does not return within two minutes.
• Built inUninstalling stops and removes the service and binaries but deliberately keeps /etc/chronoops-agent and /var/lib/chronoops/agent — including the identity file and certificates — for traceability. Remove those two directories yourself for a complete wipe.

At registration and heartbeat the agent probes the cloud link-local metadata address (169.254.169.254 and similar) to correlate a cloud instance id. If nothing answers, it moves on.

Deployment, backup and upgrades

Docker Compose or Helm, in your environment, including private-network and fully offline delivery. The database and object storage can be instances you already run; the Compose offline package carries PostgreSQL and Redis images, the Kubernetes chart neither.

• Built inOffline delivery ships as one package: images, the Helm chart, the migration binary, multi-architecture agent builds, install/upgrade/rollback tools, an SBOM and a per-file SHA-256 list. That list is always checked before install, upgrade and rollback, and a mismatch stops the run. Signature verification has to be switched on and pointed at the public key we deliver separately; otherwise it falls back to the key inside the package, and is skipped when no signature is present.
• Built inRun through the delivery tool, install, upgrade and rollback default to a dry run: a real run means switching the dry run off and confirming that specific operation, with a second confirmation for a database schema rollback. (The one-command quick installer is a separate path and runs for real by default.)
• Deployment settingMigrations are run by a separate binary. Splitting the migration account from the application's runtime account, so the application holds only the privileges it needs, is a step enabled at delivery: a one-shot job then provisions the restricted role and re-checks its grants before startup. In a default deployment the two are still the same account.
• Built inThe backend image is distroless and runs as a non-root user, and the access gateway container runs with a read-only root filesystem. Backend and frontend images are built for linux/amd64 and linux/arm64; the agent adds windows/amd64.
• Deployment settingCompose deployments come with backup and restore scripts: a logical dump plus volume archives, with checksums and row-count manifests. Restore defaults to a verify-only mode and a destructive restore passes four separate checks. Backup for Kubernetes belongs to that environment's storage layer and is not covered by the scripts.
• Per environmentLocalized stacks are assessed case by case against the exact operating system, kernel, chip architecture and database. The product ships arm64 artefacts and a fixed validation matrix. No combination has been taken through it end to end and archived yet, so the compatibility conclusion comes out of running that matrix in your environment.

Two things before delivery. Backups deliberately exclude the key and licence files, so archive those separately — without them a restored database cannot open the credentials it holds. The default deployment is single-replica: multiple replicas mean planning storage, messaging, the session directory and one database migration together. That is still not high availability: when an owner node goes away, the sessions it was holding are interrupted.

Licensing and renewal need no connection

A licence is an offline signed file, verified locally in your environment. There is no licence server and no activation call-back.

• Built inLicence files are signed with Ed25519 and verified against a locally mounted public key. The licensing code contains no network calls at all: verification reads a local file and your own database.
• Built inA licence binds to your tenant identifier, not to a machine. The signed payload contains no machine id, MAC address or host fingerprint; scale is bounded by a signed node count instead. The community edition's ceiling is one tenant, 50 managed nodes and one Kubernetes cluster.
• Built inRenewal and rollback are offline too: we sign a new file against your current licence fingerprint and sequence number, the sequence must increase and the fingerprint must match, and a replay or broken chain is refused. Nothing renews itself and nothing calls home on a timer.
• Built inWhen a licence expires the business API returns a clear error code and no data is deleted. The licence management routes stay reachable, so importing a new file restores service — an expiry never locks the administrator out.
• Per environmentAt issuance and renewal we receive only what you tell us: tenant identifier, entity name, edition, node count, feature scope, expiry, and — for a renewal — the current fingerprint and sequence. The product sends back no usage data, no inventory and no runtime metrics.

How releases are made, how to report a problem

You can check the integrity of what we ship yourself. Where our process is enforced by tooling and where it rests on convention, we say which.

• Built inEvery file in a delivery package carries a SHA-256, the manifest is signed separately, and install, upgrade and rollback all verify it first. Check it with the public key we hand over separately rather than the copy inside the package.
• Built inAgent upgrade artefacts are signed with Ed25519 by the release pipeline. The platform re-hashes each artefact and verifies the signature before an upgrade can be dispatched.
• Our practiceChanges are classified by blast radius: anything touching identity, audit, jobs, agents, licensing, terminal access or database migrations is treated as high risk and adds race-detector runs, the PostgreSQL integration suite and the matching smoke gates. The full regression is reserved for changes to the pipeline itself, to deployment configuration and to unrecognised paths — and for the nightly run.
• Our practiceDecisions about product scope, security boundaries, default policies and edition lines are written up as numbered product-decision records — including, where it happened, that an independent review was not obtained.
• Our practiceTo report a security issue in the product, write to weiwendi@aiops.red with reproduction steps, impact and the version — please leave out real credentials and customer data. We confirm receipt, work the fix and tell you how to obtain the patch in an offline environment. Acknowledgement times, fix windows and which versions a patch covers follow the service plan or contract we agree; the product itself carries no blanket response time.

What we do to a release is integrity verification: vulnerability scanning of third-party dependencies and image signing are not in place yet, and a published disclosure policy and supported-versions list are still being written. Support scope and service hours likewise follow the service plan or contract we agree.