Privacy and access

Who can see your chats and data, where it is stored and where it goes. Read the first section for the shape of it, then the one that matches the question.

Projects, skills, apps and connectors all follow the same access rules, so this page calls any one of them an item where the rule does not depend on the kind.

Who can reach what#

Everything you keep in Ghostlyn has one answer to "who can see this", and it is one of three.

Only you. Your chats and everything pasted or uploaded into them, projects and skills set to Personal with their files, your rows on tables that are not shared, your scheduled tasks, your credentials and your connected accounts. A table that is not shared keeps a separate set of rows for each member. No teammate and no admin reaches these.

Everyone in your organization. Items the organization owns, items a member owns and has shared, the rows of shared tables, and the credentials an admin stores for everyone.

The companies that run the models. The text of a turn is sent to the model provider your organization runs on, and its embedding is sent to the provider that indexes it for search. This one is not a wider version of the other two. It applies to a private chat and a shared project alike, since running a model means sending the text somewhere.

Ghostlyn has a single operator with access to production data. They do not read your chats unless they are debugging a specific issue you reported and there is no way to fix it without reading the chat. Otherwise Ghostlyn looks at aggregate statistics across chats rather than individual ones, or a program reads the chats rather than a person.

Reach widens only when someone deliberately widens it: sharing an item with the organization, with people or groups or to the registry, sharing a chat, storing a credential for the organization or syncing an item's files to GitHub.

Organizations and teams#

Every user has a personal organization and can belong to one or more team organizations, all accessible from the sidebar:

Personal organization - your private space. Only you can see your chats, projects, skills and data here
Team organization - shared with its members. Projects, skills, apps, connectors and data can be shared with teammates

The organization row under Search at the top of the sidebar names the active one. It opens a menu to switch only when you belong to more than one. Switching reloads the page, and a chat or item page that belongs to the old organization returns to its list instead.

Team organizations have two roles:

Members can use skills, create projects, skills and apps and chat with the agent
Admins can also manage members, groups, organization settings and shared credentials

No admin of a team organization can reach your personal organization.

Inviting someone to your personal organization turns it into a team organization. Your chats and anything set to Personal stay private to you, but anything the organization already owns becomes visible to whoever joins. A new empty personal organization appears alongside it.

Who sees your profile photo#

Your photo is visible to you and to the active members of every organization you belong to, the same people who already see your name. A member who has left an organization keeps their photo on what they wrote there, since their messages stay. Nobody else can load it. Ghostlyn stores only a 256px square copy, never the original file.

Signing in with Google or Slack copies the photo from that account when you have none set. It never replaces a photo you uploaded. Remove deletes the stored copy, though the next Google or Slack sign-in copies the provider photo back.

What is inferred about you#

Ghostlyn guesses your form of address, feminine, masculine or neutral, from your name and timezone the first time you chat, so a language that marks gender on the person it addresses picks the right form. The guess is sent to the same model provider that already receives your messages. It is shown to no one else, though in a shared channel the agent's replies to you use it. Change it at any time on the Account page.

Access control#

Every item has a sharing setting that controls who can see it and the files and tables it holds:

Personal - only you can use it
Organization - all organization members can use it
Community - anyone can install it

Personal here is a sharing setting, not the personal organization. A project in a team organization can be set to Personal too.

An item can also be shared with specific people or groups as a Viewer, an Editor or an Admin. Anyone who is an Admin on an item can share it further. That is the member who owns it, any organization admin for an item the organization owns, and anyone given Admin on it. You need no organization admin role to share something of your own. Everyone else sees its Sharing page read only.

A member who opens a link to a project, skill, app or connector in their organization that they cannot access lands on a Request access page instead. It names the item and who owns it, and its Request access button emails the owner, or the organization admins for an item the organization owns, with an optional message. The email links to the item's Sharing page with the requester already chosen as a Viewer. A member with no link asks the owner or an admin to share it with them. A link to an item in another organization still reads as not found.

Search reads the same scope. The palette covers your own chats and the items you own, installed or were given access to, along with their files and tables, so a project shared with the organization but not with you never appears in a result or a count. Channels follow the channel page's rule: the ones you belong to and your organization's public ones, never a private channel you are not in or a channel in another organization. When a search under All finds nothing, it says what it searched, so you can tell "no match" from "not shared with you".

Who can see your chats and data#

Chats are private to the person who ran them, in a personal organization and in a team organization alike. The product scopes every chat query to your own account, so no teammate and no admin can open your chat from the Chats page or turn it up in search, whatever role they hold. Anything you paste or upload into a chat travels with that chat's own privacy. The only way another person sees a chat is a link you create yourself, covered below.

Projects, skills, apps and connectors work differently, since sharing one is a choice its owner makes. They follow the sharing setting described in Access control above.

An admin of a team organization can download an Export organization snapshot from the organization settings page. That archive carries what the organization can already reach: the items the organization owns, the items a member owns and has shared organization-wide or to the registry, and the rows of every shared table. Left out are items set to Personal, your rows on tables that are not shared, your scheduled tasks, your chats, your credentials and your connected accounts. The snapshot draws the same line the organization draws when you leave it: the items you shared stay with the organization and your private ones in it are deleted.

One thing does reach past that scope: files synced to GitHub. Connecting a project or skill on its Sync page copies its files into that repository and keeps copying them as they change, so from then on the repository's own access decides who reads them. The sharing setting does not travel with the files and cannot pull them back. Check who can see the repository before syncing files you would not share that widely.

Who sees a company task's runs#

A company task belongs to an organization project, and everyone who can open that project sees the task, its instructions and every run's full transcript. Everyone who can change the project, organization admins included, can edit it. Who that is follows the project's own Sharing panel, so sharing the project wider shows the task's runs to more people.

A company task runs as the organization's shared agent rather than as you. It never reads a member's chats, personal projects or connections. It reaches only built-in skills, its project and the other projects attached to it, and a project can be attached only when everyone who sees the task can already open it, so attaching never shows a project to someone new. Its connector calls are limited to tools their server marks read-only, since nobody watches a run to catch a change it was steered into.

Making a company task from your own task copies it, and the copy cannot use:

Your earlier chats. Its recall searches earlier runs of the same company task and no chat, channel or direct message, so a source it needs has to be fetched or kept in an attached project
A private project, unless attached. Attaching one needs it shared first with everyone who sees the task, after which they all see run output drawn from it
Your Home, your pinned projects and the skills of projects not attached
Your connections and personal keys. Only organization credentials and the attached projects' own credentials reach it
Connector actions that change data

Who sees a Slack channel thread#

A thread the agent joins in a public Slack channel is visible to everyone who can read that channel, which in a public channel is everyone in the Slack workspace, with or without a Ghostlyn seat. The thread belongs to the organization rather than to whoever started it. When a member leaves, the thread stays and their messages in it stay too, no longer tied to their account.

The agent there runs as the organization's shared agent rather than as whoever mentioned it. It reaches only built-in skills and the projects an organization admin attached to the channel, never a member's own chats, files or connections. Every attachment asks an admin of that project to confirm, since a public channel reaches people the project's own sharing never named. Its recall searches earlier threads in the same channel, never another channel, a direct message or a member's own chats. Each reply counts toward the monthly limit of the person whose message it answers.

Ghostlyn also stores and indexes the ordinary messages of a public channel it was mentioned in, from everyone in the installing workspace, with or without a Ghostlyn seat. It sends them to the model provider, which decides whether to reply, keeps them like any other thread message and finds them through recall the same way. Deleting the Slack message drops Ghostlyn's copy of it, while a quote already taken into an earlier reply keeps its text.

Who sees a web channel#

Anyone in the organization can find, join and read a public channel, whether or not they joined it. A private channel is seen only by the people in it. Organization admins are no exception: an admin sees a private channel only once someone adds them. A public channel linked to a project someone cannot open stays closed to them until the project is shared with them.

A channel belongs to the organization rather than to whoever created it, and the organization's shared agent owns its messages. When a member leaves a channel, their messages stay in it. When the last member leaves a private channel, it is deleted with its messages.

Moving a chat into a channel shows it to everyone in that channel, earlier messages included. A moved chat never returns to private, and the person who moved it can no longer delete or rename it alone.

You can edit and delete your own messages in a channel or a direct message, and an organization admin in a channel can delete any member's message there. Deleting a message clears its text and its attachments from the live database at once, takes it out of search and of the agent's later turns, and removes the notifications it sent. Editing replaces the old text everywhere Ghostlyn stored it, notifications included, and no earlier version is kept. A push notification or Slack DM already delivered stays on the device. An agent reply that answered or quoted the message stays, and so does a summary the agent wrote when compacting a long thread or a tool result that captured it. Database backups keep copies until they are deleted, as for a deleted chat.

A voice call in a channel, a thread or a direct message runs as the shared agent, with the channel's tools and projects rather than the caller's own accounts. Every request, answer and spoken line it saves sits in the thread, so everyone who can read the channel sees it. Small talk before the first request of a call started from the channel's composer is never saved.

Who sees a direct message#

A direct message is seen only by the people in it. Organization admins are no exception, and an admin outside it cannot open, find or search it. It is never listed on Browse channels, in the sidebar or in search for anyone else. Like a channel it belongs to the organization, and the shared agent in it reaches no member's own chats, files or accounts, nor any project or connector. A request the agent files from a direct message tells the member it asks who is in the direct message and what was asked. When an account is deleted, its messages stay in the direct message, attributed to Someone.

A thumbs up or down is stored against your own membership. In a channel or direct message, a thumb on any message, a person's or Ghostlyn's, shows its counts and who gave it to everyone there. In a personal chat your rating of an agent reply stays yours alone, and a chat export carries only the ratings of the person exporting it.

What the agent can look up across channels#

The agent can list channels and direct messages, with each one's description, privacy, members and attached projects, and search what was said in them. What it reaches depends on who is asking, so an answer never shows its readers more than each of them could open:

In your own chat it reaches every channel and direct message you can read: public channels, private channels you are in and your direct messages. A public channel linked to a project you cannot open stays out
In a channel or direct message it lists public channels and that place, and searches that place alone, since everyone there reads the answer
A run drafting your answer to a request searches your own chats and the place that asked, never your other direct messages or private channels
An outside app connected to Ghostlyn, a script and an agent run started from one search your own chats alone and list no channels

Using your own accounts in a shared chat#

In a channel or a Slack channel thread the agent never reaches your own connections or files. When you ask it for something only they hold, such as your own email or calendar, it files a request instead. Your own agent then drafts an answer in a separate read-only run that only you can see. That run can read your connections but cannot change, send or post anything.

Nothing reaches the shared chat until you approve the exact text, and you can edit it first or skip it. The approved text appears as your own message, and the agent carries on from it. Skipping posts nothing and tells nobody. The draft and everything the run read stay in your own history, never in the shared chat. A request expires 24 hours after it was filed.

When a colleague asks for something only you know#

A colleague asking the agent in a shared chat for something only your accounts hold never lets the agent read them. The agent files a request on you instead, and your own agent drafts an answer in a read-only run that only you can see. The organization pays for that run rather than you.

The request reaches you alone, as a Slack DM if you use Slack and otherwise as a notice linking its own page. It names who asked, where, and everyone who would see the answer. Nobody else ever sees the draft. Approve posts the exact text into the shared chat as your message, and the agent does not reply to it. Edit lets you change it first. If anyone joined the chat since the request was filed, nothing posts and the card names them, so you approve again for the wider audience.

Skipping is never shown. Once a request expires, after 24 hours, the shared chat sees one line saying there was no answer from you, the same line whether you skipped it or never saw it, and the draft is deleted. One member can have at most three requests waiting on them, and one member can ask colleagues at most 10 times a day.

What an admin sees about your activity#

An admin of a team organization can open the organization's Activity page and filter it by member. It lists what each person did rather than what they wrote.

The contents of a chat never appear there, and neither does the name of anything private. When you export or share a private chat, a project or skill set to Personal or one of its files, the admin sees that you did it and when. They never see the chat's title, the item's name or the file's path, which reads as "Personal item" instead. Anything the organization owns keeps its name. Storing or removing a credential records the credential's name. Your own Activity page under Settings shows you the same events for your own account.

You can share a whole chat or a single answer as a link. Either way you choose who can open it: anyone with the link, or only the people you invite.

Sharing a chat shares it as it is now. Messages you add later do not appear. Sharing an answer shares only that answer, and the chat's title is not shown, on the page or in the invite email.

A chat has at most one chat link but can have any number of answer links. Every chat and answer link you created is listed under Settings > Sharing, where you can limit it to the people you invite or stop sharing it.

An invite-only link reaches any email address you type, inside your organization or not, and the address needs no Ghostlyn account yet. Ghostlyn emails it the link with your name, the chat's title and any note you add. Links and web addresses are removed from the note. The dialog shows each invited address, never the name of an account behind it, and the add looks the same whether or not the address has an account. Invited addresses are kept until you remove them or delete the share.

The email is sent as "your name via Ghostlyn" from Ghostlyn's own address, so nobody can reply to you from it. A recipient who does not expect it can report it or choose Don't email me again, which stops every later share email to that address from anyone. They are still added to the share and can open it.

A recipient opens an invite-only link by signing in or signing up with an account holding the invited address, on any of their organizations. Two consequences follow. A Slack workspace admin who sets a member's profile address can open a share sent to that address, since Ghostlyn trusts the address Slack reports. A share sent to a work address still opens on the account that address belonged to after its owner leaves the company. A sharer's name is shown as they set it, so a sharer named "Ghostlyn Security" sends as "Ghostlyn Security via Ghostlyn".

Forwarding a message#

Forward copies one message you can read into a channel or direct message you belong to, or into a new direct message with a colleague. The copy is a new message from you, so everyone in the place sees it, and the original stays where it was with the same readers as before. Nothing else from the source travels: an agent reply arrives as its text without the tool calls behind it, which can hold what your agent read from your own accounts, and a message arrives with its images but without attached documents. You pick the message, so what it reveals is your call.

The card under the copy keeps the author's name, the place and the time as they were when you forwarded it. A later edit or delete of the original does not reach the copy, as with a forwarded email. View original links back only to a channel or a direct message, and someone outside it lands on a page saying the channel was not found. A forward from a chat with your agent links nowhere.

Before you send, the dialog warns in one line when the place you picked reaches someone who could not read the original, naming where it came from and who will now see it. It does not stop you. A message from your own chat with your agent never warns, since you are its only reader and see exactly what you forward.

Deleting a chat#

Deleting a chat removes it from the live database at once, together with its messages, attachments and every chat or answer link to it. Your Activity page keeps the fact that you shared or exported it but drops its title. Usage and billing totals are unaffected, since what a chat cost is recorded against your account rather than the chat. Database backups keep copies until those backups are deleted, so a restore after an outage may bring a deleted chat back until it is deleted again. A Slack thread cannot be deleted from Ghostlyn and stays in Slack.

Temporary chats#

A temporary chat changes what Ghostlyn keeps, not where the messages go. It stays out of your history, out of the account export and out of the agent's recall in your other chats. Its messages are never indexed, so they are not sent to the embedding provider. Ghostlyn deletes it with everything attached 30 days after the last message. Each turn still goes to the AI provider your workspace runs on, under that provider's terms, as for any chat. Files, records and messages the agent wrote elsewhere during the chat are not temporary. Do not describe a temporary chat as hidden from an administrator or as never used for training, since Ghostlyn can promise neither.

Credentials and connections#

Credentials are API keys you store in Settings > Credentials. They are stored securely and the agent uses them by name without ever seeing the actual values. A key is only ever sent to its own domain.

A project, skill, app or connector can also hold a shared account or a shared key of its own, which its admins connect, set, replace and remove on its Authorization page. Everyone who can use the item, through its organization, a share or a group, uses them without seeing the value or the sign-in, and no one can read a value back, not even the admin who stored it. Installing someone's public item never hands you its shared values. Only that item and items with the same owner can reach a shared value from a skill or script, and a skill from anywhere else is refused with a message naming it rather than asking you to allow it, since the value is not yours to allow. Your own key or connection with the same name wins over a shared one unless the request names the item first, as in sales-inbox:HUBSPOT_KEY.

Company keys are the shared keys the organization's default project holds. An admin of that project sets them on its Authorization page, and Organization settings > Credentials opens that page. Every member of the organization uses them, whether or not the project is pinned or active in a chat, and a key a specific project holds wins over a company key with the same name. A built-in connector such as Gmail may use a company key too.

A skill, app or connector declares which credentials it wants in its manifest, naming each one's host and optionally a link to where to get a key. Declaring names nothing more than intent - it does not grant access on its own. Using a stored key from inside one also needs consent: an item you personally own may use any key you hold, a connector may use the account it connects, and everything else needs you to allow it once, per key, either by clicking Allow on the card it raises the first time it reaches for one or by storing the key in response to its own prompt. Settings > Credentials lists what holds that consent for each key, with a Revoke control on each.

The same Allow card appears when the agent is following a skill you installed and reaches for one of your keys.

A second card guards against a page tricking the agent in a chat you are in. If the agent has read a web page, a search result or a connector's data during the current turn, a request it writes itself that would send data using one of your keys waits for you. The card names the host, the method and the key, and nothing is sent until you allow it. A scheduled task, a webhook run or a script does not stop to ask, as What an unattended run may send below explains.

Connections link your account to external services like GitHub or LinkedIn. Set them up in Settings > Connections. Once connected the agent can interact with these services on your behalf. Connections refresh automatically. Disconnecting one, from that page or by uninstalling the last connector that used it, removes the stored token and gives up Ghostlyn's access at the provider as well, so nothing stays live there afterwards.

An outside AI assistant connected through MCP holds its own access to your account. Settings > MCP server lists each one for the current organization, with its permissions and the date you authorized it. Revoke on a row ends that assistant's access at once. An assistant granted permission to run code runs scripts that can use your files and the web as its other permissions allow, and every account you have connected, without the confirmation card a chat would show. Only an assistant that asks for this permission by name is offered it. When an assistant connects with a published metadata document, Ghostlyn fetches that public document from the address the assistant names and shows its host on the consent screen before you approve.

GitHub connects in two steps. Authorizing at Settings > Connections proves who you are, but reaches no repository until you also install the GitHub App on the repositories you want it to use. A connected GitHub row carries a "Repositories" link for that second step - follow it any time to add or remove repositories, even after the first install.

GitHub also has two access levels, because GitHub fixes what a connection can do at the moment you authorize it and there is no way to change that later for the same app. Connecting GitHub always starts read only: it can read issues, pull requests and repository contents, but never write. When you trust it enough to let it write - open an issue, push a change - click Allow changes on the GitHub row, the Sync page or the card a chat raises when a write needs it. That switches the connection to a second GitHub App that can read and write, and sends you to that app's own installation page to choose which repositories it may reach, since installations are per app. Downgrading back to read only means disconnecting and reconnecting.

Gmail starts read only too: connecting it asks Google only for permission to read mail, so the agent can search, read and triage but cannot draft, send, label or archive. Allow changes on the Gmail row, or on the card a chat raises when a write needs it, asks Google for the send and organize permissions on the same connection. A Gmail connection that already held full access keeps it.

Outlook and Outlook Calendar reach your Microsoft 365 or Outlook.com mailbox and calendar through Microsoft Graph, under one Microsoft sign-in. Connecting starts read only: the agent can search and read mail and read your calendars, and nothing else. Allow changes asks Microsoft once for drafting, sending, filing and calendar changes across both. Sending still needs your confirmation for each email. Microsoft offers no way for Ghostlyn to give up its access, so disconnecting deletes the stored tokens but leaves your consent at Microsoft. Remove it at My Apps for a work account or at account.live.com/consent/Manage for a personal one. Until you do, reconnecting comes back at the access you last allowed.

LinkedIn connects through LinkedIn's own sign-in and its official API, never by logging in as you in a browser, so using it puts no strain on your account. The connection reads only your own name and publishes posts as you, each one after you approve it. It cannot open anyone else's profile, search people or read anyone's activity, since LinkedIn grants that to no ordinary app. The agent can still open a public profile page the way a logged-out visitor does, which shows the name, current company and job title but no work history or activity.

Where your data is stored#

Ghostlyn and its database run on servers from Hetzner. Database backups go to Backblaze B2 in its EU region.

Deleting is not always immediate. A deleted table row, whether you or the agent removed it, moves to a recoverable trash for 30 days before it is purged. A file deleted from a project, skill or app can be restored from its History page. Chats and whole projects, skills, apps and connectors have no trash, so deleting one is immediate.

Opening a Ghostlyn page in a browser records a visit. It starts on the first page you open, before you sign in, and asks no consent first. The row holds your IP address and your browser's user agent string. Beside them sit the page you landed on, the page that sent you, any campaign tags in the link and the time. With the location lookup switched on, the server also derives a country, region, city and coordinates from the address. It reads a local copy of a database mapping IP addresses to geographic locations, so the address is never sent anywhere to be looked up. Two cookies carry the visit: visit, which expires after four hours, and visitor, which expires after two years. Once you sign in, each page you load links that visit to your account.

The IP address and user agent string are cleared 30 days after the visit. The rest of the row is deleted 730 days after it. Deleting your account unlinks every visit from you at once, and the unlinked rows are still deleted 730 days after the visit.

Where your messages go#

The text of a turn is sent to a model provider, because that is what running a model means. Which provider depends on your settings, since Ghostlyn can set it per organization or per user. Anthropic, OpenAI, Fireworks, DeepSeek and OpenRouter are the providers Ghostlyn can run on, and they sit in different countries. Ask your admin which one your organization uses before assuming where a message lands. Ask Ghostlyn support if your admin does not know or the question is about your personal organization.

Message text is sent a second time, as an embedding. Ghostlyn indexes messages and the files in projects, skills and apps so search and the agent's recall of past conversations work, and generating that index sends the text to an embedding provider, DeepInfra through OpenRouter. What goes is the first 20,000 bytes of a message or file, about 20,000 characters of English and fewer in another script, so a long paste is sent as its opening stretch rather than whole. A message under 20 characters is never indexed, so nothing of it is sent this way.

Read aloud sends a reply's text to Soniox or OpenAI, depending on your organization's setting, to turn it into speech. Only the reply you press Read aloud on is sent, with code blocks and links removed. Nothing is sent unless you press it.

Dictation streams your speech to Soniox to turn it into text as you speak. Nothing is recorded until you press the microphone or hold Space, and Ghostlyn keeps no copy of the audio. Only the text it returns lands in the composer.

Voice mode streams your speech to OpenAI's GPT-Live by default, whichever provider your organization runs on, and OpenAI's voice speaks back. An organization or member set to the Soniox voice engine instead streams the call's audio to Soniox both ways, the same provider dictation and read-aloud already use. Ghostlyn keeps no recording of the call either way. What you ask is transcribed and stored in the chat as a request, and the agent's answer is stored there too, exactly like typed turns. The agent answers on your organization's own provider, and only the voice runs on OpenAI or Soniox.

Soniox handles dictation, read-aloud and its voice mode in its European Union region, so that audio and text are processed in the EU.

Whether a conversation trains a model is a question about the model provider rather than about Ghostlyn. Nothing in Ghostlyn fine-tunes a model on that traffic. What a provider does with an API request afterward is set by that provider's own terms, and Ghostlyn configures no retention or training option on your behalf, so the answer follows whichever provider your organization runs on.

Ghostlyn's own operators can turn on tracing to a self-hosted Phoenix instance or to LangSmith for debugging and prompt iteration. When either is on, every model call sends its full system prompt, every message in the conversation and every tool call's arguments and result to that service as well. Ghostlyn's own chat deletion and the retention table above do not reach a tracing vendor's store, so a trace there can outlive a deleted chat and stays under that vendor's own retention policy. Ask Ghostlyn support whether your organization's traffic runs with tracing on.

What an unattended run may send#

A scheduled task, a webhook run or an external invoke call can send an email or chat message through a built-in send tool such as Gmail's or Google Chat's only to the recipients it was granted when you created or last edited it, which you confirm once at that time. A call naming anyone outside that grant is refused, nothing leaves and the run tells you what it would have sent. A task or webhook created with no grant cannot send at all.

A chat you are in works differently: every send, whatever the recipient, opens a card naming the exact recipients and content first, and runs once you approve it. A second identical send or any changed field opens a new card.

An unattended run can still call a connector's own tools, including connectors that send mail. It can also make a credentialed curl request, because the confirmation card for a credentialed write after reading external content does not run there. Only the built-in send tools are refused today.

Who decides whether the agent may write without asking#

An admin picks the organization's Tool approval on the Organization page: Allow all, which uses every tool without asking and is the default every organization starts on, Review writes, or Ask before writes, which reads without asking but asks before a tool makes changes. The choice applies to every member, who cannot loosen it for themselves, only tighten it where that is offered. A send follows the same setting as any write, and its confirm card is bound to the exact call. A scheduled task sends only to the recipients granted when it was created.

Under Review writes a write that would otherwise ask goes to a fast model first. It reads the member's recent messages in that chat, or for a scheduled task its instructions and the names and descriptions of its active skills, plus the calls the agent made earlier in the turn and the pending call itself. It never reads the agent's replies or what any tool returned. The review runs on the organization's own model provider and bills whoever the turn bills, against their monthly limit. A webhook, a delegated run and a request from an outside agent are never reviewed, since their prompt came from outside the member, and a tool someone set to Needs approval on its Tools page always goes to a person.

Under Ask before writes a credentialed curl request counts as a write too: it asks when the call carries a stored credential and a method other than GET or HEAD, the same way a native tool's write does. A run script or an outside MCP client cannot show the card a write needs, so a write it would otherwise ask about is refused there instead of parked, and a scheduled, delegated or webhook task stops and tells its owner which tool and setting stopped it.

An item's Tools page sets this per tool. A member's own choice applies to their own chats, and only where it is at least as strict as what the organization allows. An admin's choice For the organization binds every member and every surface: a tool the organization blocks is gone from the agent, from run scripts, from MCP Apps and from outside MCP clients, and a tool it allows skips the approval Ask before writes would ask for. A send still asks whatever either of them set. A channel, a direct message or a company task runs as the organization agent, so only the organization's choices apply there.

What the agent can send from a file#

The agent can send a stored file or a chat attachment to an outside web address as a request body, which includes files it never shows you as text, such as a photo or a PDF. It can do this only as the first outside call of a turn. Once a turn has read a web page or other outside content, the agent refuses to send a stored file in that turn, scheduled runs included, since the content could carry an injected instruction to upload something. A script is not covered by this guard and can send any file its owner can read.

What a webhook URL lets someone do#

A webhook URL is a standing grant. Anyone holding it can start a run as you, with your connections, until you replace or delete it. There is no signature check, since most senders such as form builders cannot sign a request. The request body reaches the run as data, labelled untrusted and fenced between random boundary lines, so the saved instruction stays the task. Only a hash of the URL is stored and the URL is shown once, on the Tasks page, never in a chat. Replacing the URL or deleting the webhook stops the old one at once and cancels runs it queued. A webhook run is unattended, so its built-in send tools follow the recipient grant in the section above. A webhook starts at most 25 runs a day and counts against your monthly cost limit like any other run.

What is sent when you report a problem#

Asking the support agent to file a bug, a feature request or feedback sends an email to the Ghostlyn team. It carries what the agent wrote up about your problem, the chat's id and your name and email so the team can reply. It does not attach the conversation itself, and the team cannot open your chat from that id. Say so in the chat if you would rather nothing was sent.

Crashes go to an error tracker with the stack trace and no message content, names or email addresses.

Deleting an account or an organization#

Both deletions are self-service and permanent. There is no recovery window, no undo and no restore through support, so each asks for an exact confirmation string before the button turns on.

Deleting an account removes that person's chats, messages, projects, skills, apps, files, tables, credentials, connected apps and their personal organization. Their connectors' access is given up at the provider afterwards, so no live grant is left behind. It is refused while they are the only admin of a team organization that still has members. Make someone else an admin first. An export of every chat they own, in every organization, is offered in the dialog.

Deleting an organization removes that organization and every member's work in it, and emails every active member afterwards. Their own accounts and any other organization they belong to are untouched.

One thing outlives the deletion for the rest of the month: a scrambled key made from the email address and sign-in ids, plus how much of the monthly allowance was used. It holds no readable address and is deleted when the month ends. Signing up again that month resumes the allowance where it was left rather than starting it fresh.

Two edges are worth knowing:

A Slack direct message thread is stored as one record owned by whoever started it, so deleting that person's account removes the record with the replies it holds. A channel thread belongs to the organization and stays. The thread stays in Slack untouched either way, and deleting an organization removes Ghostlyn's record of the Slack installation without uninstalling the app from the Slack workspace
A skill, app or connector published to the registry outlives its author, since anyone may have installed it. It stays available with its authorship reference cleared