What your security team will want to know
An AI knowledge assistant holds your documents, your past conversations and the keys to your other systems. Here is how SupaCortex protects each of them - written to answer a questionnaire, not to reassure in the abstract.
How does SupaCortex secure company knowledge?
Each SupaCortex workspace has its own two databases - one for business data and a separate pgvector database for embeddings. API keys, OAuth tokens and connector credentials are encrypted at rest with AES-GCM and are write-only. Sign-in supports roles, Google and Microsoft SSO and two-step verification. Answers are scoped by project and by customer, and actions in your systems need the user's confirmation. The AI runs on open models on infrastructure we operate, and your content is never used to train models.
- Two databases per workspace - never shared tables.
- Secrets encrypted with AES-GCM and never shown again.
- Roles, Google and Microsoft SSO, two-step verification.
- Answers scoped by project and by customer.
- Open models on infrastructure we operate - no third-party AI API.
- Your content is never used to train models.
Isolation
- Two databases per workspace
- Each workspace gets its own business database and its own vector database (PostgreSQL with pgvector). Your documents, passages and embeddings never sit in a table beside another customer's.
- Resolved first
- Every request is resolved to exactly one workspace from its sub-domain or key before any workspace data is opened - and refused rather than guessed.
- Projects inside a workspace
- Knowledge is organised into projects, each with its own documents, feeds, widget, connector and API-key grants. A key or widget for one project cannot search another.
- Files
- Uploaded files are stored under a per-workspace root, so another workspace's file key does not resolve.
Secrets and encryption
- Encrypted at rest
- API keys, OAuth tokens, feed credentials, connector secrets and authenticator secrets are encrypted with AES-GCM, bound to the workspace and the item they belong to - a ciphertext copied elsewhere does not decrypt.
- Write-only
- Once saved, a secret is never shown again - not in the app, not in an API response, not in a log. You replace it; you cannot read it back.
- API keys
- Shown once at creation, limited to chosen projects and scopes (search, answer, ingest, drafts), and revocable at any time.
- In transit
- TLS on every endpoint. Session tokens never travel in a URL.
Sign-in and access
- Roles
- Viewer, Editor, Admin and Owner. Viewers can ask; Editors manage content; Admins manage settings, users and keys.
- Single sign-on
- Google and Microsoft sign-in for existing users - SSO never creates an account. An organisation can turn passwords off and be SSO-only.
- Two-step verification
- Authenticator-app codes, asked even after SSO, with one-time recovery codes. Each code works once; five wrong codes lock the step for fifteen minutes.
- Login throttling
- Repeated failed sign-ins from one address are slowed and then refused, for passwords and codes alike.
Who can be answered what
- Scoped by project
- A widget, an API key or a help desk integration answers only from the projects it is granted. You choose what each project contains and who can ask it.
- Scoped by customer
- Content tagged with a CustomerId is searchable only for that customer. Shared content answers everyone the project serves.
- Identity from signed tokens
- In identified mode your backend signs a short-lived token (15 minutes at most). Who is asking comes from that token, never from what the user types - so nobody can ask about another customer's order.
- Not per-user permissions
- SupaCortex does not mirror Drive, SharePoint or Confluence sharing user by user. Keep internal and public knowledge in separate projects.
Calls to your systems
- Public widget stays public
- A widget in public mode never calls your systems. Only lookups you mark public-safe can run there; everything else needs an identified user.
- Actions need confirmation
- An action - raising a request, changing a booking - runs only after the user confirms it, and carries an idempotency key so a retry never does it twice.
- SSRF checks
- Every URL the service fetches - crawled pages, S3 endpoints, connector endpoints - is checked so it cannot be turned against internal networks. Connector endpoints are checked again on every call, after DNS resolution.
- Audited
- Every connector call is logged with what was called and the outcome, and kept for 90 days.
AI and your content
- Models we operate
- Language and embedding models are open models running on infrastructure we operate. Your documents are not sent to a third-party AI API such as OpenAI.
- No training
- Your content is not used to train, fine-tune or improve any model, and never answers another customer.
- Past tickets
- Mined conversations are redacted - emails, phones, IDs and names become placeholders - before the model reads them, and nothing mined is searchable until a person approves it.
- Drafts, not sends
- Reply drafts for help desks are suggestions. In UnifyDesk an agent edits and sends, and UnifyDesk's own approval rules still apply.
Retention
- Widget conversations
- Deleted after 180 days without activity.
- Team chat
- Kept as each user's private history until they delete it; deleted conversations are removed after 30 days.
- Help desk threads
- The redacted ticket thread sent for a draft is emptied 30 days after the draft is finished; the draft and its outcome stay for quality reporting.
- Logs
- Connector call logs are kept for 90 days; processing records for 30. Retention runs daily, in small batches.
Visibility
- Conversations
- Admins can read the widget conversations for each project, with the citations each answer used.
- Feedback
- Thumbs up and down on every answer, so a wrong one is seen and fixed at the source.
- Credits
- Every AI operation is recorded in a credit ledger, with usage by operation and by day.
- Sources
- Feeds record each run - items seen, fetched, unchanged and failed - and a run that saw too little of a source never deletes anything.
Where we are, and where we are not
Claiming a certification you do not hold is the fastest way to fail a procurement review. Here is the current position.
Data processing agreement
A DPA covering processor obligations and sub-processor disclosure is available on request.
Security architecture summary
A written description of isolation, encryption, access control and AI data handling, suitable for a vendor review.
SOC 2 Type II
Not started. We will publish a date when an observation window begins, and will not claim it before the report exists.
ISO/IEC 27001
Not started. We will not claim it before a certificate is issued.
We do not offer a choice of hosting region today. Ask us where your workspace would be hosted.
Reporting a vulnerability
Email info@greatdevelopers.com with reproduction steps. We acknowledge within two working days, keep you updated while we fix it, and credit researchers who ask to be named. Please do not test against another customer's workspace.
Questions people ask before they start
Need answers for a security review?
We will send the architecture summary, sub-processor list and DPA, and go through your questionnaire with you - usually within two working days.
Questions first? Email info@greatdevelopers.com or call +91 8585953085.
ChatGPT
Claude
Perplexity
Grok