# Privacy and permissions

> Understand which owner, provider, recipient, or connected tool receives workflow data, and manage sharing, permissions, and access deliberately.

Source: https://kaitoi.io/docs/reference/privacy-and-permissions/
Section: Account and help
Written for: Anyone deciding what to upload, connect, run, or share.
Last reviewed: 2026-10-24

---

A workflow can send data to Kaitoi storage, model providers, connected accounts,
external tools and local services. Review the actual operations and destinations
before uploading, executing or sharing.

## Follow data to its destination


Workflow inputs can travel to Kaitoi services, configured providers, connectors or tools used by the selected operation. Inspect each destination and the data it needs. Revoke REST keys, MCP access, shared links and provider grants through their respective controls; disconnecting one does not universally revoke the others. Copies already received are not recalled by removing a share.

Only the selected authored image follows the operation’s data path; the credential follows a separate authorization path. Revocation blocks future authorized use while a previously received copy remains visible at its destination.

*Figure: Grant access for the intended resource and revoke it at the right boundary.*

## Follow the inputs and results

A model call sends the input needed by its provider. A connector uses its
authorized service account. An external MCP tool receives the arguments passed
to it. A local model uses its configured service, while another step in the same
workflow may still call a cloud provider.

Read Kaitoi's governing [Privacy Policy](https://kaitoi.io/privacy/) and the
policies of the providers you use. Product controls alone do not establish
training, retention, residency or compliance guarantees.

Keep secrets in their supported settings, outside prompts, shared graphs,
public source, screenshots and URLs. Inspect literal input values and bundled
files before publishing a template or package; sharing is not a credential
scrubbing service.

## Manage the particular access grant

Signing out does not by itself revoke independent keys, connectors or shared
links. Use the control for the grant you intend to end.

| Access                                  | Where to manage it                                                                                                |
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Managed providers                       | **Settings → Account → Providers**                                                                                |
| Eligible personal provider keys         | **Settings → Variables**                                                                                          |
| Connected service account               | **Settings → Connectors → Disconnect**, then the provider's connected-app permissions if its grant should end too |
| REST API key                            | **Settings → Developer → REST API Keys → Revoke**                                                                 |
| Incoming MCP token or authorized client | **Settings → MCP → MCP Access**, then **Revoke** or the authorized app's **Disconnect**                           |
| External MCP server called by Kaitoi    | **Settings → MCP → MCP Servers**, then disable or remove that configuration                                       |
| Team membership and roles               | **Settings → Account → Teams**                                                                                    |

Disconnecting a connector removes Kaitoi's stored connection. Review the
provider-side authorization separately; removal in Kaitoi does not necessarily
revoke that remote grant.

A server REST key belongs in a trusted backend. A browser key is visible to
end users and needs the registered Developer App, origins, narrow scopes and
your application's own user authorization. An origin restriction is not a
hidden secret.

## Review and end shared access

Open **Settings → Account → Profile → Shared Links → Manage**. The
**Projects** and **Web Apps** categories expose supported edit, expiry and
**Revoke** controls.

The **Stations** category has **Take down** and **Restore**. Taking down a
Station stops its runnable link; taking it out of the gallery only removes
discovery. Review its Access settings when restricting who can run it.

A read-only project share, permission to clone, team membership and Station
execution are different grants. Use [Sharing and embedding](/docs/studio/sharing/)
and [Teams](/docs/studio/teams/) to choose the intended one.

## Manage copies as well as permissions

Copying a Personal file into team Files creates a destination copy governed by
the team's access. Downloaded files, cloned projects and material already sent
to another service do not disappear when you revoke the original link.

Review public covers, previews, bundled outputs and supporting assets before
sharing. If you move or copy material, manage the destination as well as the
source. Station restrictions do not replace permission to redistribute the
content you choose to include.

## Share useful diagnostics deliberately

Before reporting a problem, remove secrets, private inputs and signed URLs from
your own description or screenshots. Read the feedback form's disclosure:
bounded diagnostic context accompanies a report, and error text can still
contain project material. A copy-to-clipboard action does not send a report
until you choose a destination and submit it.