Security
Last updated: July 26, 2026
Enhanciar asks you to connect your codebase, your Slack, and sometimes your inbox. That is a lot of trust for a young company to ask for, so this page answers the questions a careful engineer would ask before clicking Connect — in plain English, without hiding behind a compliance badge we haven't earned yet.
Where we are on formal certification: Enhanciar does not hold SOC 2, ISO 27001, or any third-party audit today. We would rather tell you that than imply otherwise. What we can tell you precisely is what the software does with your data, which is the rest of this page.
1. What actually happens when you connect a source
Every source follows the same path:
- You authorise a connector. We store the resulting token, encrypted, against your workspace.
- An ingestion job reads from that source, extracts the text, and asks a language model to summarise and cross-link it into wiki pages and a knowledge graph.
- The wiki pages, the graph, and a copy of the extracted text are stored in your workspace so answers can cite their source.
- Answering a question reads from that store. We do not re-fetch from your source at question time except where you explicitly ask for live data.
The important consequence: the model call in step two happens under your own LLM account whenever you bring your own key. See section 4.
2. What each connector can read — and what it can never do
Connectors are read-only unless the table says otherwise. Where a scope grants write access, it is because a specific feature needs it, and that feature always proposes an action for you to approve before anything is created.
| Source | What we can read | What we cannot do |
|---|---|---|
| Code (GitHub & other Git remotes) | Clone the repository you point us at, and read its files and commit history. | We do not push commits, open pull requests, or modify your code. The GitHub App asks for Pull requests: read and write for one reason: with AI code review enabled it posts its review as comments on a pull request you asked it to review. |
| Gmail | gmail.readonly — read your mail. |
gmail.compose creates drafts only. It does not grant send. Nothing leaves your outbox unless you press send yourself, in Gmail. |
| Google Drive | drive.readonly and drive.metadata.readonly — read documents and their metadata. |
No create, edit, move, share, or delete. |
| Google Calendar | calendar.readonly plus calendar.events, which lets the scheduling assistant check free/busy and create an event. |
Event creation only ever happens from a proposal you approved. We do not delete or silently modify existing events. |
| Slack | channels:history (messages in public channels the bot is in) and users:read (display names). |
We do not request DM or private-group history. We do not read email addresses — the bot deliberately lacks users:read.email. |
| Notion, Confluence, Jira, Linear, Zendesk, GitHub Issues | Read pages, issues and tickets through each product's API using the token you supply. | Read-only ingestion. Jira and Linear can create an issue, but only through the action layer, from a proposal you approved. |
| Databases | The connection string you provide, used to read schema and run the queries you ask for. | We do not issue writes, schema changes, or destructive statements. |
| Uploaded files | Only what you upload. | No access to anything else on your machine. |
Anything that changes the outside world is proposed, not performed
Creating a Jira or Linear issue, drafting an email, or booking a calendar slot all run through the same three-step path: the assistant proposes the action with its full payload visible, you approve it, and only then is it executed. An approved action can be executed exactly once. If you never approve, nothing happens.
3. Who can see what, inside a workspace
Access is filtered at the moment a question is answered, not at the moment content is stored. Each ingested item carries the access-control information from its source — which Slack channel it came from, who a document was shared with — and a person only ever sees answers built from material they are already entitled to read. Workspaces are isolated from one another by account, and one customer's data is never used to answer another customer's question.
4. Your model, your key, your data
Enhanciar is bring-your-own-key. When you save an OpenAI, Anthropic, Google, or other provider key in Settings, your content is sent to your account with that provider, under your agreement with them — not resold or marked up by us. That matters for two reasons: the provider's data-handling terms that apply to you are the ones that govern your content, and your usage appears on your own bill where you can audit it.
Enhanciar does not train models on your content, and does not use it to improve any shared model. If you use a hosted model we provide instead of your own key, the content goes to that provider under our agreement with them; the no-training commitment is unchanged.
5. How secrets are stored
- API keys, OAuth tokens, and database connection strings are encrypted at the application layer with Fernet (AES-128-CBC with HMAC authentication) before they are written to storage, using a key held in the deployment environment and never in the database. They are decrypted only in memory, for the duration of a request or job.
- They are never logged, never returned by the API, and never shown back to you — Settings displays a masked placeholder, so a saved key can be replaced but not read back.
- Everything else at rest — wiki content, the graph, ingested text — sits on Google Cloud with Google's default encryption at rest.
- In transit, TLS 1.2 or better, everywhere.
6. Sign-in
Authentication is handled by Firebase Authentication; we never see or store your Google password. Session tokens are short-lived (about an hour) and rotate automatically. TOTP two-factor authentication is available in Settings → Security, and an audit log of security-relevant events on your account is visible on the same page.
7. Where your data lives, and who else touches it
Content is stored in Google Cloud's Mumbai, India (asia-south1) region — both Firestore and our storage bucket. Application compute runs on Google Cloud Run in Singapore (asia-southeast1), so data transits Singapore while it is being processed.
The third parties that process data on our behalf are:
- Google Cloud Platform — hosting, compute, database, storage, authentication.
- Razorpay — payment processing. We never see or store your full card number.
- The LLM provider you choose — under your own account when you bring your own key.
The complete and authoritative list, including retention periods and your rights over your data, is in the Privacy Policy.
8. Getting your data out, and deleting it
- Disconnect one source at any time from the Connections tab. Its token is deleted.
- Delete one API key at any time without touching anything else.
- Delete your account from Settings → Data & danger. This purges your encrypted keys and your wiki; personal data and content are removed within 30 days, except where law requires us to retain something.
9. Reporting a vulnerability
If you find a security problem, email support@enhanciar.in with enough detail to reproduce it. We will acknowledge within three business days and keep you updated until it is resolved. Please give us a reasonable window to fix an issue before disclosing it publicly. We will not pursue legal action against anyone acting in good faith under this policy.
For anything else — a security questionnaire, a DPA, a question this page didn't answer — write to support@enhanciar.in and a human will reply.