Security
ArchibotChat security overview
Review customer-visible security controls for access, credentials, artifacts, audit, backups, and data boundaries.
Last updated
ArchibotChat 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 an approved identity provider. Access to Chat, API, workspace, and operator functions is controlled by product groups and account billing state.
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
ArchibotChat 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.
Attached artifacts are not automatically sent upstream as raw bytes or extracted text. The current policy is metadata-first unless product behavior explicitly changes.
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 ArchibotChat 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 ArchibotChat 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.
Related guides
- ArchibotChat API keys
- ArchibotChat artifacts
- ArchibotChat activity and audit
- ArchibotChat support cases
- ArchibotChat subprocessors and service providers
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.