Your credentials never reach Ark8's servers.
This page describes what the app and Ark8's servers do today. Automated tests check the database access rules, the audit log and what a share sends.
Design principles
Four rules behind Ark8's design.
Credentials stay off Ark8's servers.
SSH keys stay where they are on your Mac (Ark8 keeps only the path), kubeconfigs in ~/.kube or a private copy on your Mac, and saved sudo passwords in the Keychain, used only after Touch ID or your Mac password. Your Vault sign-in is held in memory only. Each credential goes only to the system it signs in to: an SSH password to that host, a Vault token to the Vault that issued it. None is ever sent to Ark8.
Server-side authorization.
In Ark8's cloud, who can see which shared host, membership or audit entry is decided by the database, row by row. Client-side filtering is never the security layer.
PKCE sign-in.
Signing in to Ark8, and connecting a Google or Microsoft calendar, use PKCE with SHA-256. Ark8's Google and Microsoft client secrets live server-side in Ark8's identity service; they never reach the macOS app or the browser. Vault sign-in uses Vault's own OIDC flow, protected by a one-time client nonce.
Append-only audit.
Member, invitation, role, group, ownership and sharing changes are recorded in an append-only organization audit log. The database refuses to update or delete its rows, and every insert passes through a secret-redaction trigger.
Production safeguards
PROD asks before Ark8 acts.
Before Ark8 opens a terminal, the Files browser, a tunnel, a Docker action over SSH or a runbook step on a PROD host, macOS asks for Touch ID or your login password. One approval lasts five minutes for that session, and a runbook step also goes ahead on a PROD host whose terminal is already open. With no way to authenticate, access is refused.
Typed confirmations
On STAGING and PROD you type the environment's name to delete a session or a group that contains one, to move a session into or out of that environment, to delete files, and to upload with the Upload button. Files dragged in get a confirmation sheet that flags a PROD destination. An import can raise a host's protection but never lower it.
Verified host keys
A PROD host never connects with an unverified host key, and STAGING is blocked by default too.
Vault passwords held back
A Vault password is never sent to a PROD host whose key hasn't been verified.
Every decision recorded
Every PROD approval and denial is recorded in the Activity Log, and so is reuse of an earlier approval when a terminal, tunnel, Files browser or Docker action opens. The log and its security events are on by default, and switching either off is itself recorded.
Touch ID isn't asked for web tabs, or for Docker engines on this Mac or over TCP. STAGING gets typed confirmations and strict host-key checks, not Touch ID. The five-minute approval window is fixed. The check is on by default and Settings has no switch to turn it off, but it is stored per Mac: it can be changed outside Settings (Ark8 records the setting in the Activity Log at each launch), and an organization can't enforce it.
Host keys and connections
Trust is a decision you make, with the fingerprint in front of you.
- First connection. For PROD hosts, and for STAGING hosts by default, Ark8 shows a new host's fingerprint and asks you to accept it before the first connection. DEV hosts are trusted on first contact without a prompt (ssh's accept-new), and a key that later changes is still refused.
- Changed keys. When ssh refuses a host because its key changed, a bar under the terminal offers the exact “ssh-keygen -R” fix. Nothing is removed until you click, and STAGING and PROD ask you to confirm first. When a server comes back with a new key, Ark8 explains it from its own records, such as a Terraform destroy at that address, and flags a change it can't explain.
- Test Connection. Test Connection checks the address and the host key, and the sign-in when it uses keys or a Vault password, before you save a session. It offers no key or password until the host key checks out, so an unknown or changed key stops the test first. It never opens a shell or writes known_hosts, and PROD asks for Touch ID before a test signs in.
- Failed transfers. When a file transfer fails because a server's host key changed, the failure window shows the new fingerprint and the known_hosts file and line ssh named, and says whether Ark8's records show a rebuild. Remove old key runs exactly “ssh-keygen -R” on that file, on the server that refused when the transfer went through others. STAGING and PROD ask first. The retry goes through the normal host-key check, so the new key is never accepted silently, and every removal is in the Activity Log.
- Unsafe names. A host or user name that ssh could read as an option, or pass to a shell, is refused before anything connects. The server refuses such names on shared hosts too.
- Remote desktop and web tabs. RDP certificates are pinned by SHA-256, and Ark8 never negotiates the legacy RDP security layer; a downgrade is refused as a security failure. A web tab trusts a self-signed or internal-CA certificate only after you choose Trust for This Session. That trust is pinned to the certificate, logged, and forgotten when Ark8 quits.
Secrets and Vault
Values stay in Vault until you ask for one.
Secrets works on your own HashiCorp Vault, and Ark8 keeps no secret store of its own. Values you create or edit are written to your Vault. They are read from it only when you click Show, Copy or Edit, or when a connection or a runbook run needs one.
Reading values
- • Browsing never reads a value. Show, Copy and Edit each read it once, and a shown value hides after 30 seconds.
- • A copied value stays off Universal Clipboard, is marked so clipboard managers that follow the common convention skip it, and clears after 30 seconds unless you've copied something else since.
- • A secret linked to a PROD host asks for Touch ID or your Mac password before Show, Copy or Edit.
- • Every reveal, copy, edit, create, delete, restore, link and unlink is recorded in the Activity Log by path and field, never by value.
- • Saving uses Vault's check-and-set, so a newer change made elsewhere isn't overwritten.
Signing in to Vault
- • Ark8 doesn't store a Vault token. You sign in with your own identity through Vault's OIDC auth method, in your browser: the same flow as “vault login -method=oidc”.
- • The token Vault issues is held in memory only. Ark8 discards it after four hours at most, sooner if Vault's lease is shorter, and asks Vault to revoke it when you sign out of Vault, quit Ark8, or the sign-in expires.
- • If an earlier version saved a Vault token in the Keychain, Ark8 deletes it at launch and tells you to have it revoked in Vault.
- • Scheduled and webhook runs never open a browser: they stop at once if nobody is signed in to Vault. On PROD, the Touch ID check still comes first.
- • Vault is reached over https only (plain http only to an address on this Mac), and redirects to another host are refused. A private CA you import becomes the only trusted root for Vault, and a sign-in is tied to the Vault address, namespace and CA it was made with.
Needs: your own HashiCorp Vault with a KV v2 mount, and Vault's OIDC auth method enabled with a role by your Vault admin (Ark8 shows the setup commands).
Not covered today: other Vault sign-in methods (AppRole, LDAP, userpass) and KV v1. Touch ID is asked only for secrets linked to a PROD host. While an RDP session is open, a copied secret also reaches that computer's clipboard. A batch token can't be revoked and simply expires, and if Ark8 crashes, the token stays valid in Vault until it expires.
Data boundary
What travels to Ark8, and what doesn't.
Sharing is descriptor-only. Secrets aren't sent to Ark8: its database has no column for an SSH password, a private key, a kubeconfig or a Vault token, and a share never includes one.
- SSH passwords
- Private keys
- Kubeconfigs
- Sudo passwords
- Vault token
- Shared SSH host descriptors
- Organization + memberships
- Roles + audit events
Tenant isolation
Reading another organization's data is blocked by the database.
Every table that holds organization or user data has per-row access rules keyed to the signed-in identity. A user in Organization A cannot see Organization B, even by tampering with the URL, cookies or request body.
organization_id.The full list
What is sent to Ark8, and what never is.
These lists cover the credentials and connection details for your infrastructure. Ark8's own session token is a separate thing and is covered below. It travels, because that is how signing in works.
- • Host name, hostname, port, username
- • Tags and free-form notes
- • The sharing level you chose (everyone, or admins only) and the host's environment label
- • SSH login passwords: Ark8 does not store them at all
- • SSH private keys, key passphrases, key file paths
- • kubeconfig contents, client certificates, cluster tokens
- • Sudo passwords and every other Keychain item
- • Your Vault token, and every value read from your Vault
- • Terminal output, file contents, command history
- • Your Activity Log (SIEM export goes to your own collector, not to Ark8)
- • Your Google or Microsoft password: you type it only on the provider's own sign-in page. Signing in to Ark8 leaves no Google or Microsoft token in the app; a Google or Microsoft calendar you connect for runbook schedules keeps its own read-only sign-in in this Mac's Keychain
Signing in gives your Mac a session token, and it is sent as a bearer token on every request to our API: that is how the server knows who is asking. It grants access to your Ark8 account and to nothing on your infrastructure. It is stored in the Keychain, not on disk in the clear. Ark8's servers also hold your account (email, name and picture from Google or Microsoft) and, if you're in an organization, your membership, role and groups; your organization's admins can see when you last signed in and whether you use Google or Microsoft. The daily update check goes to Ark8's servers too, which see your IP address and app version. Only if you turn on Send crash reports to Ark8 in Settings do they also receive the app's crash and hang reports, redacted on your Mac first and kept 90 days.
A shared session's free-form notes upload exactly as you typed them. Nothing inspects them for secrets, so a password pasted into a note is a password uploaded. The note field is for context, not for credentials, and we would rather say so than claim a filter we do not have.
When you use Shraga, Ark8's AI assistant, your question and the context it needs go straight from your Mac to Anthropic's API, using your own API key. In Strict mode, the default, the names, addresses and usernames of your sessions and clusters, and any IP address, are replaced with placeholders; a name that appears only inside a script or note is sent as written. Standard mode sends real names. In both modes a filter removes values written next to a label it knows, such as password= or an Authorization header; a secret with no label in front of it can get through. PROD hosts are left out unless you include them, and nothing is sent until you accept a consent screen that names Anthropic. Shraga never reads terminal output, file contents, the Keychain or Vault. Every lookup it makes, every script it is asked to write and every failed request is recorded in the Activity Log. What is sent.
Ark8 also sends data to services you set up yourself: secret values to and from your own Vault, Activity Log events to your SIEM (with the Ark8 account that did each thing, once you set your Enterprise number), run notifications to Slack or your webhook, commits to your Git remotes and workflows to GitHub when you push them, and read-only calendar lookups to Google or Microsoft. When you open Helm Charts it also fetches the public chart indexes of nine built-in repositories, chart icons from the addresses those indexes give, and documentation from Artifact Hub; installing metrics-server downloads its manifest from GitHub.
Where your data lives
One region, in the United States.
Ark8's servers hold your account and your organization's records. Your infrastructure's credentials, and everything else the app works with, stay on your Mac.
Ark8's servers
Supabase on Amazon Web Services, us-west-1 (Northern California, United States)
Accounts, organizations, memberships, roles and groups, invitations, shared host details, the organization audit log, sign-in history and Terms acceptances. Also the app's downloads and update feed.
The website
Vercel's global network
Serves this site and the web admin console. Ark8's records stay in the database on Ark8's servers, and the console reads them from there. Vercel's request logs include IP addresses.
Your Mac
Stays there unless you share or export it
Sessions, credentials and the Keychain, kubeconfigs, runbooks, the Activity Log and assistant chats. What leaves it, and to whom, is in the full list above.
A choice of region (an EU region included), and running Ark8's backend on your own infrastructure. The Mac app connects only to Ark8's own backend. Who handles data for Ark8
Authentication
PKCE sign-in with Google or Microsoft, provider secrets server-side.
You sign in with a Google or Microsoft account. Sign-in is required, and Ark8 checks it each time it starts. On macOS the handshake runs in ASWebAuthenticationSession, so Google credentials, Microsoft credentials and provider secrets never touch the Ark8 process: the browser runs in Apple's system authentication context.
- Fresh PKCE verifier and SHA-256 challenge on every sign-in.
- Ark8's identity service exchanges the code server-side using its own configured client secret.
- Session tokens are stored in the macOS Keychain, not on disk in plaintext.
- Signing out ends every local terminal and SSH shell, so the next person to sign in can't inherit them. Your Vault sign-in is separate: sign out of Vault in Settings to end it.
Any second factor comes from your Google or Microsoft account; Ark8 doesn't enforce one of its own.
Ark8 doesn't offer sign-in through a generic or custom OIDC provider: such an identity is linked to an existing account by its email, so a provider one organization controls could sign in as someone in another.
Planned: SAML single sign-on for Okta and other SAML 2.0 identity providers, set up by your organization's Owner after verifying its email domain.
- Read. Your own membership. Admins and Owners can read every membership in their organization.
- Change. Only through audited database functions: Admins add, change, suspend and remove members, and a person joins by accepting an invitation or leaves on their own. Only the Owner can make someone an Admin.
- Owner. Only an Owner can create or grant an Owner membership, checked by the database before the row is written.
Authorization
The database is the security layer.
Every table in the Ark8 schema has explicit per-row access rules. The client never receives rows it isn't authorized to see, because the database filters them out, not the UI.
- • Per-row access rules on every table that holds organization or user data, tied to the signed-in user and their role (Owner / Admin / Member / Viewer).
- • Owner transitions gated by the database: non-owners cannot promote to Owner.
- • Internal database functions are closed to clients; memberships, groups and roles change only through audited functions.
- • Joining takes the invitee's own Accept on the invitation link, signed in with the invited, verified email. Signing in alone never joins an organization.
- • A suspended member's group roles stop counting, and a profile's email always comes from the sign-in account.
- • Cross-tenant isolation enforced in the database and covered by its test suite.
- • No privileged server key is ever loaded by the client.
- • Viewer is read-only. Ark8 for macOS re-checks your role when it starts, when it comes to the foreground, every five minutes, and before an organization action if the last check is more than a minute old. When your role or membership no longer allows a shared host, the tabs you opened from it close. That is Ark8's policy, not a lock on the host: SSH credentials are each person's own.
- • A shared host opens with the environment it was shared with, so a host shared as PROD gets PROD safeguards. A later change on the owner's Mac reaches teammates only when they share it again.
Audit
Two logs: one on every Mac, one for the organization.
Ark8 keeps an Activity Log (History in the app) on each Mac of what Ark8 opened, changed and ran, where, and by which Ark8 account. It is on by default. Export its newest 1,000 events as JSON or CSV, or stream every event to your SIEM as RFC 5424 syslog over TLS.
- • Each new event records the signed-in Ark8 account next to the Mac user: the email, whether it signed in with Google or Microsoft, the organization and role, or “Not signed in”. JSON and CSV exports carry the account, sign-in method and organization; the SIEM feed carries them too once you set your Enterprise number (without one, messages go as plain text with no structured fields).
- • Values written after a label Ark8 knows (password=, token:, an Authorization header and the like) are redacted before an event is written or sent. A secret with no such label in front of it is not caught.
- • SIEM export is off by default. It sends RFC 5424 syslog over TLS or plain TCP. If you import your collector's CA, only that CA is trusted, and you can add a client certificate for mutual TLS.
- • Delivery to the SIEM is at most once, from a queue of 1,000 events. Events lost on the way are recorded, and so are changes to audit settings (switching the log off included), clearing the log and changing the SIEM destination.
Not covered today: Ark8 never records keystrokes, the commands you type in a terminal, or terminal output. Uploads, downloads, renames and the use of a saved sudo password aren't in the log. The log and its security events are on by default; while either is switched off, PROD decisions, host-key removals and Vault secret actions aren't written (the switch itself is recorded). The file on your Mac isn't tamper-evident (clearing it is logged), so the copy in your SIEM is the one to trust. History shows the newest 1,000 events, and retention is 30, 90, 180 or 365 days.
Append-only, with secret-named fields redacted at insert. Every membership, invitation, role, group, ownership and sharing change produces an organization audit event.
The database refuses to update or delete its rows; the only exception is a retention purge that has to switch that guard off explicitly. Any metadata field whose name looks like a secret, at any depth, is replaced with [REDACTED] before the row is written.
Logged actions
Member added or invited; invitation resent, revoked, accepted or declined; role changed; member suspended or reactivated; ownership transferred; groups created or deleted; group members and roles changed; SSH hosts shared, changed or withdrawn.
Redacted keys
password · client_secret · access_token · refresh_token · private_key · service_account · assertion · authorization · saml_response · sshpass · cookie.
Read-only from the console
Admins can page through the log in the web admin console; nobody can edit or delete entries from there.
Planned: sign-ins recorded by the server. Until then, the organization audit log doesn't record sign-ins.
Updates and hardening
Signed updates, and what changed recently.
The app and its updates
- • Ark8 is signed with a Developer ID and notarized by Apple.
- • It checks for updates once a day unless you turn that off in Settings, and Check for Updates… is in the menu.
- • An update installs only after you approve it, and only if it carries Ark8's signature.
- • No analytics, telemetry or third-party crash-reporting SDK in the app. Crash and hang reports stay on your Mac unless you turn on sending them to Ark8, redacted.
In 1.7
- • Vault sign-in with your identity; no stored Vault token.
- • Internal database functions closed to clients; Admins can no longer grant Admin.
- • Viewer is read-only, and the Mac re-checks your role.
- • Activity Log events record the signed-in Ark8 account.
- • Joining an organization takes the invitee's own Accept on the invitation link.
- • A failed transfer names a changed host key and offers the exact fix.
In 1.6.1
- • FreeRDP 3.32.1 and OpenSSL 3.5.9.
- • A kubeconfig that runs a sign-in program waits for your approval of the exact command; a cluster imported earlier keeps the command it already ran, and any change to it asks.
- • Reading a Git repository can't run commands configured inside it.
- • Web tabs keep each site's cookies and storage separate, including services behind tunnels and port-forwards.
- • The runbook webhook listener rejects oversized deliveries, and a signed delivery replayed within a few minutes.
Vulnerability disclosure
Found a security problem? Tell us first.
Reports about the Mac app, this website, the web admin console and Ark8's servers are all welcome.
How to report
A security mailbox isn't set up yet. This section, the Contact page and /.well-known/security.txt will name it as soon as it exists. Until then, please don't publish the details.
What to include
- • The Ark8 version (Ark8 ▸ About Ark8) and macOS version, or the page's address.
- • The steps that reproduce it.
- • What an attacker could do with it.
- • Never real credentials or another person's data. Redact them.
While you test
- • Test against your own Mac, account and organization only.
- • Don't read, change or delete anyone else's data.
- • No denial of service, spam or social engineering.
- • Give us time to ship a fix before you publish. Fixes go out as a signed update, and its release notes say what was fixed.
Rolling Ark8 out to a team?
See Enterprise readiness for how organizations, roles and the web admin console work.