How we protect your data

Tenant isolation and access control

CORESight is multi-tenant by design. Separation between organisations is enforced in the application layer on every request, not by convention.

• Every stored record, query, background job and saved artefact is scoped to an organisation identifier. There is no global default and no implicit fallback.
• Administrative endpoints re-check the caller's organisation against the organisation being acted on, so a valid token for one tenant cannot reach another tenant's data.
• Role-based access control governs what each user can see and do, and roles are resolved and enforced on the server for every request rather than trusted from the client.
• Access to specific databases, tables and columns can be restricted per user, so analysts only query what they are entitled to.

Data protection and encryption

Connection secrets are the most sensitive thing the platform holds. They are encrypted at rest and are never returned to a browser in full.

• Database credentials and connector secrets are encrypted at rest using authenticated encryption, which detects tampering as well as preventing disclosure.
• The service refuses to start without a properly configured encryption key. There is no generated fallback key, so credentials can never be silently written under a key that disappears on restart.
• Secrets are encrypted individually rather than as one blob, and are redacted from API responses. Editing a connection never requires re-entering, or re-transmitting, a secret you have already saved.
• User passwords are stored as bcrypt hashes. They are never stored, logged or transmitted in reversible form.
• All traffic to the platform is served over TLS, with HTTP Strict Transport Security enforced.

AI and language model data handling

CORESight is an AI product, so the boundary between your data and the model matters more here than anywhere else. These are the controls that govern it.

• Analysis runs next to your data. The language model writes Python; that code executes in a compute kernel holding a direct connection to your database. Query results come back to the platform rather than your underlying tables.
• Execution is isolated per session. Generated code runs in its own sandboxed kernel tied to a single user session, not on infrastructure shared between organisations, and the kernel is released when the session ends.
• Connection secrets are invisible to generated code. Credentials injected into the execution kernel are masked from the kernel's own introspection and command-history surfaces, so model-written code cannot read them back out.
• Diagnostic traces are PII-scrubbed before storage. Row-level payloads are replaced with a row count, console output is replaced with a length stub, and pattern-based PII redaction runs across recorded text.
• Trace scrubbing fails safe. The redaction layer is built so that any internal error results in data being stripped rather than recorded.
• Generated code is executed, never your raw question text. Query text is not concatenated into database commands.

Application and platform security

Controls that harden the surface an attacker actually reaches: the login, the API and the browser session.

• Authentication endpoints are rate limited per source address, and login carries an additional per-account escalating backoff. Login throttling cannot be switched off by configuration.
• Streaming connections authenticate with short-lived, opaque tickets rather than a token in the URL, keeping long-lived credentials out of browser history, proxy logs and access logs.
• Security headers are applied to every response, including a Content Security Policy, frame denial, MIME-type sniffing protection and a restrictive permissions policy.
• The application validates the Host header against an allow-list and restricts cross-origin access to configured origins.
• Sessions are token-based with server-side revocation, so signing out invalidates access rather than relying on the browser to discard the token.

Independent verification

Controls are only worth as much as the testing behind them. CORESight was assessed by Kratikal Tech Pvt. Ltd., a CERT-In empanelled security firm, under a grey box engagement covering the application and its API. Every finding raised during the engagement was remediated and confirmed closed by the assessor on re-test before the certificate was issued. Remediation was not self-certified.

Documentation

The full closure report and certificate are available to customers and prospective customers on request, under NDA. We do not publish the report or the individual findings it contains.

Reporting a security issue

If you believe you have found a vulnerability in CORESight, please contact us at support@coreops.ai. We investigate every report and will keep you updated on what we find. If you are evaluating CORESight and need to complete a security questionnaire, use the same address and we will work through it with you.