Skip to content
Charming Docs
Esc
↑↓navigate↵open⌘Jpreview
On this page

Security review

Current facts and source links for a manager, IT admin, or security reviewer assessing Charming for a team.

What Charming is

Charming hosts apps built through an AI client. The client connects through an MCP server or the HTTP API, sends app source and updates, and gets back a hosted app URL. The AI client and its model remain separate services with their own company settings and data practices.

Charming for Work explains what a Business account adds to a regular account.

Identity and app access

  • New apps are private by default.
  • The owner can invite a collaborator, end user, or read-only viewer, change their role, or revoke access.
  • The server checks access on every app operation. An app’s interface can hide actions a person cannot use, but the interface is not the security boundary.
  • An owner can make an app public through a separate action. Public access uses one shared dataset on the app’s main URL, so it does not fit private company data.
  • Device-paired agent tokens expire after 30 days. A user can review and revoke agent tokens from their account.

See Privacy and sharing and Connect to any AI agent for roles, invitations, tokens, and revocation.

Data and deletion

An app can store data and files on Charming. People who share one app also share its dataset. The owner can delete an app; the Privacy Notice states how long app data remains after app or account deletion and lists the process for account or personal-data requests.

The Limits page lists storage, file, code, token, and network caps. Code export explains how an owner or collaborator can export an app’s source.

Network access and secrets

Backend network requests are off unless the app declares a network capability and lists each public HTTPS origin it needs. Charming blocks private networks, localhost, and cloud metadata addresses. A reviewer can check the app’s manifest and source to see the declared destinations.

The owner adds API keys in the app’s dashboard. Charming stores the values encrypted and substitutes them into allowed request headers on its infrastructure. Secret values do not enter the app’s source, logs, or the model’s context, and no endpoint returns them. See Secrets.

Connected AI clients

Connecting Charming gives the chosen AI client access to the Charming tools and the app data needed for the work it performs. That client’s privacy, admin, model, and retention settings apply on its side of the connection. Review both services before using company data.

See AI clients for current client paths. A client-specific setup guide documents only that client; it does not imply support for a different product with a similar name.

Company controls

Charming for Work includes:

  • Single sign-on through Google, Okta, or SAML, plus SCIM provisioning as people join and leave.
  • Roles and permissions on every app, with workspace-wide or private sharing.
  • A log of every share, permission change, and sign-in, exportable as CSV.
  • Retention and deletion controls, a full data export, and regional data residency on request.

These links describe the controls and terms available today. Ask the Charming team about any requirement that is not listed.

Review checklist

  1. Name the AI client and model policy the team will use.
  2. List the app data and each person who needs access.
  3. Check every outbound host and secret the app needs.
  4. Confirm the owner, deletion path, and source-export plan.
  5. Decide whether the current controls meet the company’s rules before adding sensitive data.

Was this page helpful?