Who can read your data, and what protects it.

On your computer

Ikenga keeps your projects, artifacts, terminal history and agent sessions on your computer. Keys are kept in a passphrase vault. Your coding engine still sends your prompts to its own model provider, under that provider's terms.

On a multi-user server you run (beta)

• Members of one organisation share the server and are trusted with each other. It is not built to keep untrusted tenants apart.
• Each person's secrets are kept apart from everyone else's in the app. They are sealed under a key that the server holds, so agents can keep working when the person is not signed in.
• That means whoever controls the server can read what is on it. The server runs as root on its Linux host, so anyone with root access to that host can read every member's files, secrets and agent sessions. Give that access only to people you would trust with all of it.
• Back up the server's key separately from the server. A lost key cannot be recreated, and there is no command to rotate it yet.
• The audit log records sign-ins, pairings, role changes, approvals and dispatches in a hash chain you can verify and export. It helps you spot changes. Removing only the newest entries may not be detected, and it does not stop someone with root access to the host from rewriting it.

On a managed instance (not available yet)

When we run a dedicated server for your organisation, Ikenga staff are its operator. The server holds the key to your secrets, so we can technically read your code, files and secrets on it. We will not offer a managed instance until these controls are in place, and a managed contract will include them:

• Only named Ikenga operators can reach the host, and only to fix a problem you reported, respond to an incident on your instance, or apply an upgrade.
• Every operator sign-in to the host is recorded, and you can see those records on request.
• Your data can be exported on request within 5 business days. The instance and its backups are deleted within 30 days of the contract ending.
• A data processing agreement, and a list of the subprocessors, such as the server provider, that handle your data.

Model access

On a server we run, your engines use credentials you supply: an API key, or your own Amazon Bedrock or Google Cloud route. We never copy a personal subscription sign-in onto a server we run. Ikenga includes no model usage.

Certifications

No SOC 2 yet; security questionnaire on request.

Ikenga has no SOC 2 report or other certification yet. We answer a standard security questionnaire, CAIQ Lite, on request.

Ikenga itself sends no usage analytics; the engines you run follow their own settings. We checked this by searching the desktop app's source code and dependencies, not by capturing its network traffic.

• Signed catalogue Shipped Since 0.1.0

  The catalogue of apps and extensions is signed, and the app verifies it.

  • The index lists only packages Ikenga publishes itself today.

• Consent at install Shipped Since 0.17.0

  You see what each app or extension can access before it installs.

• Held updates Shipped Since 0.14.0

  An update that asks for more access is held until you review it.

• Trust-gated capabilities Shipped Since 0.2.9

  Sensitive capabilities are gated by trust, not by a paid plan.

• Personal and project scope Shipped Since 0.17.0

  Install an app for yourself, or for one project only.

• Passphrase vault Shipped Since 0.13.0

  Keys stay in an encrypted vault that locks itself when idle.

  • On Linux the vault uses Secret Service, with a read-only keyutils fallback.

• App lock Beta Beta since 0.16.1

  Lock Ikenga when you step away, with a PIN or your passphrase.

  • Work already running keeps running while the app is locked; the lock screen lists it.

These controls need a multi-user server, which you build and run yourself on a Linux host. It is not part of the desktop download. Each one is in beta.

• Multi-user server Beta Beta since 0.19.0

  Each person signs in to their own account and works in their own space, as their own Unix user.

  On a server you build and run yourself.

  • Members of one organisation share the server and are mutually trusted; it is not built for untrusted tenants.
  • Sign-in is by username and password; single sign-on is not available yet.
  • The server needs a Linux host: it runs as root under systemd and gives each person their own Unix user.
  • Not part of the desktop download: you build and deploy the server yourself.

• Members and roles Beta Beta since 0.19.0

  A role (Owner, Operator, Reviewer or Guest) limits what each person can see and do.

  On a server you build and run yourself.

  • The spend cap is shown but not enforced.
  • Invites are links you copy and send yourself; Ikenga does not send email.
  • Ownership cannot be transferred yet.
  • Work done through a share never uses the owner's secrets.

• Device pairing Beta Beta since 0.19.0

  A device gets in only after you confirm the same four-word phrase on both screens. Each device has its own access level, and you can revoke it at any time.

  On a server you build and run yourself.

  • Pairing is covered by automated tests; a check with a real phone over Tailscale is still to come.
  • Behind a reverse proxy such as Caddy or tailscale serve, pairing a phone can fail with a "cookie_rejected" message, because the server sees the proxy's address.

• Per-person secrets Beta Beta since 0.19.0

  Each person keeps their own secrets, separate from everyone else’s.

  On a server you build and run yourself.

  • Secrets are sealed under a key the server operator holds; a lost key cannot be recreated, so back it up.
  • A secret value can be at most 64 KiB, and one person's store at most 8 MiB; a write past either is refused.
  • There is no command to rotate the server's key yet.

• Audit log Beta Beta since 0.19.0

  Sign-ins, pairings, grants, revokes, role changes, approvals and dispatches go into a hash-chained log you can verify and export.

  On a server you build and run yourself.

  • Export to external logging tools is not available.
  • Removing only the newest entries from the log may not be detected.

Signed installers for macOS and Windows are next. Current downloads are not code-signed or notarized, so macOS and Windows show a warning the first time you open Ikenga. The install script fetches the same files from the GitHub release and does not turn off any security check on your computer.

Each release includes SHA256SUMS.txt, with the SHA-256 digest of every file, so you can check a download before you open it.

How to open Ikenga the first time

Claude Code has its own controls for organisations. Your admins can deploy managed settings that local settings cannot override. They can decide which MCP servers may run, require single sign-on, and route usage through Amazon Bedrock, Google Cloud or Microsoft Foundry. Ikenga does not replace any of that, and it does not route around it. Ikenga runs your own Claude Code installation with your own sign-in, so the settings your organisation deploys still apply.

Your MCP policy also covers Ikenga's tools. Ikenga adds the tools it installs to Claude Code's own configuration files, so your allowlists and denylists apply to them. If your admins deploy a fixed set of servers (managed-mcp.json), Claude Code does not load tools installed through Ikenga.

What Ikenga adds beside them

Next

• Signed installers for macOS and Windows.
• Sign in to a multi-user server with your identity provider (OpenID Connect).

Exploring

• SAML sign-in.
• SCIM provisioning.
• Sending the audit log to your SIEM.
• Admin policy for the apps and tools people can install.
• A private catalogue for your team.

Please report security problems privately, not in a public issue. Our security policy says how, and which versions get fixes.

Read the security policy