Space Membership
A Viewer can read Threads. A Collaborator can take part and send requests to the Space's Workers. An Owner manages members and permissions. Joining a Space does not give anyone access to another member's AI accounts.
Share AI access without sharing your secrets.
Your AI provider logins and API keys stay on your own computer. Members of a Space send requests through Syntila; they never receive your credentials. This page explains what that does and does not protect.
Host Signs in to AI tools on their own computer
Host computer Credentials stay with the AI tool here · Not sent to Syntila Cloud or to members' devices
Space members Send requests to the Space's Workers in shared Threads · Never receive the credentials
Private by default
Your API keys, tokens, and provider sign-ins remain on the host computer. Members never see them.
Chosen per Space
You decide which Spaces may use your computer and which Workers each Space gets. Nothing is shared by default.
Easy to take back
Remove a permission or a member and new requests stop. You do not have to change your provider password or key.
Clear attribution
Each run records who asked and which Worker and model answered.
Sharing a Worker means trusting the people you share it with. A Worker is an AI agent running on your computer under your user account. To be useful it can read and change files, run commands, and use the network there, and it is not confined to one folder. Members cannot browse your computer or see your credentials in Syntila, but a request they send is carried out by that agent. Grant Workers only to people you would trust with that, and for wider groups consider a separate computer or user account that holds nothing private.
Who can do what.
Membership, Worker permissions, and local execution are separate decisions, each made by the person who owns that part.
Local execution, not a sandbox
Each Space gets its own working folder on the host computer. This helps organize work, but is not a security boundary: Workers run with the host user's own access. Concurrent runs can change the same files.
Read-only Chat
Chat requests are sent to the Worker as read-only. Workflows that do work, such as Work and Implement, can change files and run commands. How strictly read-only is enforced depends on the provider's tool.
MCP tool approval
Every MCP server needs the host's approval before use. Syntila records each tool's definition and blocks calls if it changes until the host reviews it again. Server tokens and environment variables stay on the host computer.
Transport & secret storage
Syntila Cloud and Syntila Workspace talk over an encrypted, authenticated connection with credentials unique to each installation. On the host, those credentials are kept in the operating system's secret storage.
What Syntila Cloud stores
Thread content, including messages, prompts, AI answers, and attached files, is stored in Syntila Cloud.
Practical answers on data and access.
Can collaborators read my files or keys?
They cannot browse your computer, and Syntila never shows them your credentials. But the agent that carries out their request runs with your user's access, so a determined collaborator could ask it to read files. Share Workers with people you trust, or host them on a computer that holds nothing private.
What if an MCP server changes its tools?
Syntila compares each tool with the definition you approved. If a server changes a tool's description or inputs, calls to it are blocked until you review and approve it again.
How do I stop sharing?
Remove the Worker or Workspace permission from the Space, or remove the member. New requests stop being accepted straight away, and you do not need to change your provider password or API key.
Does my prompt go to the AI provider?
Yes. A request and the Thread context it needs are sent to the provider behind the Worker, under the host's account, and are handled under that provider's own terms and privacy policy.
Security questions or vulnerability reports? Contact syntila@nohainc.com.