Security & privacy

What a Chataway app can and cannot do, what it learns about users, and how to keep your app's data use minimal and honest.

Chataway runs next to people's source code, credentials and client work. The platform is designed so that installing an app is a small, understandable decision — and your app's reputation depends on keeping it that way.

Most of this page is about store apps (cloud apps). Code that runs on the Mac — your own local apps and apps installed from GitHub — has a different, more powerful trust model; it's summarised below and detailed in Isolation & permissions.

#What a store app can do

#What a store app cannot do

• Run code on the Mac. No executables, no background processes, no shell. The only code is your panel's JavaScript, in a sandboxed iframe.
• Read the project or the disk. No paths, no directory listings, no project:read. Only files explicitly handed over reach you.
• Talk to arbitrary hosts. The panel's CSP and Chataway's downloads are limited to your declared domains.
• See the conversation. Your server sees tool calls and their arguments — not the chat, not the user's other messages, not other apps' tools.
• Act without a gesture. Anything with consequences waits for the user on a card. The agent can't approve your cards; only the user can.
• Hold secrets on the Mac. No secrets, no client secrets. Tokens stay in Chataway's vault.
• Impersonate. Cards are drawn by Chataway with your icon and name — never another app's, never Chataway's.

These limits are enforced three times: by the validator, by the store on upload, and by the desktop installer.

#Local apps and apps from GitHub

Local apps run their own code on the Mac, so the store's guarantees above don't apply to them. What users get instead is honesty about where the code came from:

Three rules hold for all of them:

• exec means full access to the Mac — programs it starts inherit Chataway's macOS privacy permissions (screen recording, mouse and keyboard, if granted). Chataway says so on the install screen, isolated or not. More
• Nothing silent. Installs are pinned to a commit; updates show a diff and wider access needs consent again; a GitHub app is off in every project until the user turns it on.
• The user's own agent can read it first (Check with my agent), and Chataway can revoke a repository's bad commits on every Mac.

Connectors ask before every tool call that isn't marked read-only, unless the user turns that off. See Connectors.

#What you learn about users

On every call your server receives:

The pseudonyms are an HMAC over your app id and Chataway's internal id, keyed with a secret generated on the user's Mac. They're stable — the same project always has the same pseudonym for your app on that Mac — so you can use them to keep per-project state. But:

• two apps get different pseudonyms for the same project, so apps can't correlate users with each other,
• they can't be reversed into Chataway ids,
• they differ between the user's Macs (the key never leaves the machine) — for anything that must follow the user, use your own account id,
• they don't prove a request came from Chataway (anyone can send headers) — authenticate with the account token, and treat pseudonyms as untrusted partition keys.

You never receive the user's Chataway account, email, device, IP-derived location beyond what any HTTPS request reveals, file paths, or project names.

#Data minimization

Reviewers read your listing, your permissions and your privacy policy (linked from your homepage) next to your manifest. Keep them consistent:

• Collect only what the tool needs. If a tool takes a title, don't also ask the agent for "context".
• Process and forget. Delete received files once you've done the job, unless keeping them is the point (an upload tool).
• Say it on the card. If data leaves the user's control — uploaded publicly, sent to a third party — say so in the confirm body.
• No training on user content without an explicit, separate opt-in on your own service.
• No selling or sharing of data received through Chataway.

#Securing your server

• HTTPS only, with a valid certificate. mcpUrl must be https.
• Authenticate every call that touches user data with the account token. Return 401 for bad tokens.
• Validate arguments — they're written by an AI agent following a user's request, possibly one crafted by a malicious document the agent read. Treat them like any untrusted input.
• Be careful with what your results say. Tool results are read by the agent. Don't echo untrusted third-party content in a way that reads like instructions to it.
• Rate-limit per user on your side too.
• Keep your domain list short. Every domain you add widens what your panel can reach, and needs review.

#Reporting a vulnerability

Found a security issue in Chataway or the app platform? Tell us privately from the developer dashboard rather than in public.

Users can report an app from its store page; reports go to the review team, who can suspend a listing or yank a version — which disables it on every Mac within the hour.