Product docs

Security

ArchiBot Chat security overview

Review customer-visible security controls for access, credentials, artifacts, audit, backups, and data boundaries.

Customer adminsCustomer membersPlatform operators

Last updated

ArchiBot Chat security overview

ArchiBot Chat is built as a signed-in commercial chat and API service. It is separate from workspace-backed ArchiBot Console features, but it uses the same platform posture: identity-aware access, server-owned provider credentials, account-scoped audit evidence, and supportable request IDs.

This page summarizes the customer-visible controls. It is not a substitute for your contract, security addendum, or any deployment-specific authorization package.

Access control

Users sign in through OIDC-based SSO, such as Microsoft Entra through Authentik, an approved OIDC identity provider, or approved SAML federation after operator activation. Access to Chat, API, workspace, and operator functions is controlled by product groups and account billing state. SCIM lifecycle provisioning is available only for approved enterprise accounts after ISM configures the deployment-owned SCIM token; deprovisioning disables membership access while retaining audit history.

The service fails closed when access is not ready. A signed-in user may still be blocked if the account has no product group, billing is incomplete, payment requires review, or the requested product area is not enabled.

Credentials

Browser chat uses a hidden first-party credential generated by the service after account and billing checks. Users do not see or copy that credential.

API keys are separate user-generated endpoint keys. Treat them like passwords.

  • Create API keys only for scripts or integrations that need them.
  • Store keys in a secret manager or local environment variable, not source code.
  • Revoke keys that are unused, exposed, or no longer assigned to the right person.
  • Rotate keys when a machine, repository, or integration changes ownership.
  • User-generated API keys expire one year after creation.

Billing and usage gates

Chat and API usage debit the same shared chat credits. Credits expire one year after grant.

The service checks billing and credit state before browser chat, generated API-key use, and generated API-key creation. Failed preflight checks should not debit credits.

Chat and API requests

ArchiBot Chat proxies requests to the ArchiBot OpenAI-compatible endpoint from the server side. The server-side base key stays backend-only.

For generated API keys, the public /v1 endpoint verifies the bearer key before forwarding the request. Model discovery routes can be used without debiting credits. Responses requests debit shared chat credits only after local preflight and accepted upstream work.

Artifacts

Artifacts are files used in chats or created by assistant responses. Uploads go through application controls before object storage.

Current controls include:

  • Filename and content-type allowlists/blocklists.
  • Local signature scanning and optional configured malware scanning.
  • Text-like, spreadsheet, and PDF/OCR extraction when enabled.
  • Derived Markdown artifacts for extracted text.
  • Account-scoped artifact rows and audit events.
  • User-mediated download and delete actions.
  • Operator-configured retention cleanup.

Malware scanning (ClamAV) and document text extraction/OCR (OCRmyPDF/Tesseract) run as local, in-cluster components and do not add an external malware-scanning or document-intelligence subprocessor.

When you attach an uploaded file to a chat turn, only the file metadata is forwarded; the raw artifact bytes and any server-side extracted text are not automatically sent to the model endpoint. This metadata-only policy is advertised at /api/health, and changing it requires explicit privacy, security, cost, and customer-notice review.

Activity and audit

Activity shows account-scoped support evidence such as request IDs, API-key changes, chat/API usage, billing events, support-case updates, artifact events, blocked uploads, rate limits, and access problems.

Use request IDs from Activity when opening support cases. Do not paste API keys, cookies, raw tokens, passwords, sensitive customer data, or private file contents into support cases unless ISM gives you a secure exchange path.

Exports and closure

Account export is designed to omit raw API keys, hidden credentials, provider secrets, object-store keys, and other secret material.

Account closure and full-erasure workflows are operator-only. They revoke local generated keys and hidden credentials, zero local remaining credit lots, delete local chat/artifact/notification/onboarding content, and retain required account, billing, audit, Stripe, or legal evidence.

Backups and recovery

Production backup posture is operator-managed. The hosted service can include database backups, artifact object backups, and object-store snapshots depending on the environment.

Backups are for recovery and operational continuity. They are not a reason to place secrets or unapproved customer-sensitive data into the hosted commercial service.

Data boundary

Hosted ArchiBot Chat is a commercial SaaS product unless your contract explicitly says otherwise.

Use it only for data your organization has approved for the configured commercial SaaS, storage, backup, support, and model-provider paths. See ArchiBot Chat approved data use.

Customer responsibilities

Customers are responsible for:

  • Assigning only approved users to product groups.
  • Removing users who no longer need access.
  • Protecting generated API keys.
  • Approving what data may be used in a commercial SaaS system.
  • Reviewing Activity and support cases for account issues.
  • Requesting an enterprise security packet or dedicated environment when the hosted commercial service is not the right boundary.

Done When

  • Users understand how product gates and billing state control access.
  • API keys are stored and rotated like secrets.
  • Support cases use request IDs instead of raw secrets.