Skip to main content
Before you connect a cluster, you need to know what Ankra can reach inside it, what it keeps, where that data lives, who can get at it, and how to limit each of those. This page answers those questions in one place. Where the honest answer is “more than you might assume”, it says so, and every section links to the page with the detail.

​
What the agent can do in your cluster

Ankra works in your cluster through the Ankra Agent, a single pod you install with Helm. The agent’s ClusterRole grants every verb on every resource in every API group, plus all non-resource URLs, bound cluster-wide. In practice that is cluster-admin. It needs that reach because it installs whatever Helm charts and manifests you choose, keeps them in the state you declared, and carries kubectl requests, logs and terminal sessions for the whole cluster. The ClusterRole cannot be narrowed through chart values today. What limits that power:
  • No inbound path. The agent opens every connection, outbound, to the Ankra platform. Nothing on Ankra’s side can connect into your network, and there are no ports to open. Agent Compliance Posture lists the endpoints.
  • A hardened pod. Non-root, read-only root filesystem, all Linux capabilities dropped, RuntimeDefault seccomp, and no host namespaces or host paths.
  • An identity you can cut off from outside. Each cluster has its own registration token and its own message-channel credentials. Revoking the token at the platform disconnects the agent without needing access to the cluster.
  • Changes go through a reviewable path. Changes to your stacks are applied from a versioned definition, committed to your Git repository when one is connected. Changes the AI proposes are drafts a person approves, unless your organisation turns on chat autonomy for low-risk additive changes.
  • Uninstalling removes it. helm uninstall and deleting the namespace remove the agent, its ServiceAccount and the ClusterRoleBinding.
For a control-by-control review of the agent, including how to record the cluster-admin binding as a justified exception, see Agent Compliance Posture. To restrict its network egress and what it watches, see Hardening the Agent.

​
What leaves your cluster

Everything below travels over the agent’s outbound connection, except the audit log, which Ankra writes itself when someone acts through the platform. Retention is how long Ankra keeps the data by default. Two things never leave the cluster: container image contents, because Trivy scans in-cluster and only its reports are read, and values decrypted from Git, because the agent decrypts SOPS values at deploy time and never sends the result back. Your application traffic, volume data and database contents do not pass through the agent either. Backups are written straight from the cluster to a bucket you own, not to Ankra.
Browsing a cluster in Ankra shows a Secret’s key names and value digests, never the values. Reading the values needs the kubernetes.secrets_reveal permission, which the owner, admin and operator roles hold and member and viewer do not. It is a separate, explicit request for one Secret, and each one is written to the audit log with who, which cluster and which Secret. Listings never return values, and the AI never sees them, whatever the member’s role.The same permission covers the two other ways to read a credential through Ankra. A Helm release’s values hide passwords, tokens and keys until the member reveals them. kubectl through Ankra refuses any request for Secrets from a member without the permission, whatever Kubernetes role their access grant gives them, and records every request it lets through.

​
Where it lives

The control plane. The Ankra platform, its databases, its metrics store, the message channel agents connect to, and its secret store run in the EU, in Finland, with a warm standby in a second data centre in Finland. Database backups are kept in Germany. The providers behind these, and every other sub-processor, are listed at ankra.ai/trust. Ankra Cloud clusters (closed beta). A cluster you run on Ankra Cloud sits on infrastructure the Ankra team operates, so for that cluster Ankra is also your hosting provider. Every other cluster runs on infrastructure and accounts you control. Secrets you give Ankra. Cloud, Git and registry credentials, and AI provider keys, are stored encrypted in a Vault-compatible secret store (OpenBao or HashiCorp Vault) and decrypted only when a provisioning or deployment action needs them. Removing a credential deletes it from the store. For values that live in Git, each organisation has its own SOPS key pair: Git receives only ciphertext, and the private key is delivered only to your clusters. A value you enter in the Stack Builder is held by the control plane as entered, so that Ankra can seal it each time it writes to Git. The AI model provider. When a member uses an AI feature, Ankra sends the question and the cluster data its tools read (resources, events, logs) to a model provider. Detected secret values are redacted from tool results before the model sees them, and the AI’s tools read Kubernetes Secrets as key names and counts only. Which provider receives the data is your choice under AI → Settings → Models - see AI Provider:
  • Ankra (the default) - Ankra’s own key, routed to third-party model providers.
  • Anthropic or OpenRouter - your own key and your own agreement with that provider.
  • OpenAI-compatible - any endpoint you run or choose, including a self-hosted model, so model traffic goes only where you point it.
Scheduled AI analysis of your clusters (AI Insights) is off by default. Without it, AI features send data only when a member uses them.

​
Who can reach it

  • Sign-in. Members sign in through a managed identity provider (Auth0); Ankra does not store passwords. Federation to your own identity provider is available on the Enterprise plan. See Identity & Access Controls.
  • MFA. Authenticator apps, passkeys and security keys, and recovery codes. An organisation can require MFA for every member. See Account Security & 2FA.
  • Roles. Five built-in roles - owner, admin, operator, member and viewer - plus custom roles, each assigned for the whole organisation, one cluster, or a cluster group. The permission matrix shows exactly what each role can do.
  • Tokens. Scripts, CI and MCP clients use API tokens. A token carries its own scopes on top of the role of the member or service account behind it, so it can be narrower than that role but never wider. See Service Tokens and Tokens.
  • Kubernetes access. kubectl access goes through Ankra with short-lived tokens tied to the member, instead of shared kubeconfigs. See Cluster Access.

​
How to restrict it

​
Evidence and compliance

To have an organisation’s stored data removed when you leave Ankra, and for the offboarding timeline, contact support.
Take Ankra’s own certification status and its sub-processor list from ankra.ai/trust or from us directly, not from this documentation. That page is kept current as the programme progresses.
Next: if you are reviewing the agent for approval, go to Agent Compliance Posture. If you are ready to connect a cluster, start with Hardening the Agent so the restrictions above are in place from the first install.