Architect

Security and Data

This page answers the questions a security review asks about AIVory Architect: what is stored, where, how it is protected, and how it leaves.

  • Hosted in Germany (EU) on Hetzner, by AIVory
  • Vault secrets encrypted at rest with a key held outside the database
  • Every run in an isolated container: pinned image, no traffic between runs, cloud metadata blocked
  • The Jira app asks for no Jira permission and reads no issue data
  • Deletion on request, completed within 30 days

What is stored, and where

Data Where Notes
Designs and generated Terraform AIVory database, Germany Per organization
Run logs, drift and state checks, activity log AIVory database, Germany The terraform output of a run, without secrets
Terraform state AIVory state store, Germany Encrypted object store inside the cluster
Vault credentials AIVory database, Germany Encrypted at rest, see below
Account: email, display name, organization, seats AIVory database and Keycloak, Germany

Hosting sub-processor: Hetzner Online GmbH, Gunzenhausen, Germany. Payment: Stripe for web app plans; Atlassian for the Jira app; AWS or Azure for marketplace plans. No design or credential data reaches a payment provider.

The vault

  • A credential is encrypted with a key encryption key (KEK) that lives in the deployment’s secret store, not in the database
  • A read returns a masked tail (the last four characters), never the value
  • A run receives its credentials as environment values inside the runner container only, decrypted for that run
  • Credentials are named after the provider variable they fill (for example HCLOUD_TOKEN, AWS_ACCESS_KEY_ID), so a run gets only the ones it names

Runs and runners

Every Plan, Apply, drift, state or kubectl run executes in its own container:

  • A pinned image (by digest) with terraform or kubectl and nothing else, no shell
  • One CPU and 1 GB of memory per run, a time limit, a fresh working directory
  • A network with traffic between containers switched off
  • The cloud metadata endpoint (169.254.169.254 and the provider host names) blocked, so a run cannot borrow the host’s identity
  • Plan stops at a review gate. Nothing changes without an explicit Approve

The Jira app

  • Runs as a Forge app inside a Jira iframe under the Atlassian content policy
  • Sends to app.aivory.net: the Jira site URL, the user’s display name and Atlassian account id
  • Requests no Jira REST scope and reads no issue, project or user directory data
  • The Jira site links to one AIVory organization; a site admin can disconnect it under Billing > Marketplace in the web app
  • Uninstall cancels the licence at once and keeps the organization’s data for a reinstall

Transport and access

  • TLS 1.2 or higher for every connection, including the run-log socket
  • Sign in through Keycloak (OpenID Connect); the Jira app signs in through a Forge invocation token exchanged server to server
  • Organization membership and seats decide who sees a design

Retention and deletion

  • Data stays while the organization exists
  • Deletion: mail [email protected] from an organization admin’s address. Designs, runs, state and credentials are removed within 30 days; an invoice record stays as long as the law requires
  • Backups roll off within 30 days after the deletion

Reporting a vulnerability

Mail [email protected] with “security” in the subject. You get an answer within two business days. Please do not test against other customers’ organizations.

Documents