Security
The model is never the thing keeping you safe
Prompts can be argued with. A server cannot. Every action passes the same check, on every call, whatever the model intended and whatever a tool result tried to talk it into.
Your data
We are not in the business of using your data
Insighter makes money from the thinking, not from what it reads. Everything below is a property of how the system is built, not a policy someone could quietly change.
Never trained on. Never sold.
Your data is read to answer your question and for nothing else. Not to train our models, not anyone else's, and never to improve the service for another customer. There is no version of this where your data is the product.
AES-256, under your own key
Every sealed value is AES-256-GCM under a key derived from your organization id. No other tenant's key opens your data, and a record moved out of your organization does not quietly decrypt into something else. It fails.
Encrypted in transit and at rest
Conversations, connector credentials and any model key you bring are sealed before they are written. A stolen backup, database credentials or console access read ciphertext. Secrets appearing inside your own data are redacted before the model ever sees them.
Nobody at Insighter browses your data
There is no standing internal access. Support access is time-boxed, needs your approval, and is written into the same audit log you can read. The question is not whether we would look. It is whether you can check.
And what we do not claim
Insighter decrypts your content to answer your question, so this is not end-to-end encryption and we will not describe it as such. What encryption at rest buys you is that a stolen backup, database credentials or console access read ciphertext. Customer-managed keys and a private deployment, where the boundary moves onto your own infrastructure, are an enterprise conversation. Ask us and we will tell you exactly where the line is today.
Watch one call get judged
Four calls arrive at the gate. Reading passes. Anything that changes a live system stops and waits for a person. A class you have ruled out is refused, with no consent path for anyone.
Controls
Six things the server does, on every run
Tiered actions
Every tool call is classified before it runs. Read is allowed, side effects ask, and a prohibited class is refused with no consent path at all.
Single-use consent
Approving an action approves that action, once. Nothing inherits permission from a previous yes.
Injection detection
Every tool result is scanned for instruction-like text. A hit is surfaced to you and taints the turn, which blocks confirmation-tier actions for the rest of it.
Workspace boundaries
Sources, dashboards and alerts belong to a workspace. People see only what they have been given, and a watch shares its status, never its data.
A visible kill switch
One control drops every source in a workspace to read-only. Automations keep running and can only read and report; queued approvals cannot be approved until you resume.
Complete activity record
Every run, every tool call, every approval and every refusal is written down with who, what and when, exportable.
Data handling
The short answers, without the legal padding
- Do you train on our data?
- No. Never, not for our models and not for anyone else's. Every model call runs under zero-retention terms, and the subprocessor list names each provider that touches your data.
- Where does it live?
- In the region attached to your organization, in isolated per-run working directories that are encrypted at rest whenever the conversation is not in use. Everything you reach us over is TLS. The hop from us to your own database is TLS too, and how strictly its certificate is checked is a per-source setting you control: new sources verify the certificate fully, and any source set to something weaker says so on its own screen rather than leaving you to assume. We will name every subprocessor that touches your data, and tell you before any of them changes.
- How long do you keep it?
- Detail behind an event is swept on the retention window your organization sets, and you can shorten it. The record that an event happened is never purged, because removing it would defeat the trail it exists to provide.
- Who inside Insighter can see it?
- Nobody, by default. There is no standing internal access. The root secret lives in a managed key store rather than on disk or in a repository, and support access is time-boxed, needs your approval, and is written into the same audit log you can read.
- Where does the model sit?
- At the end of the chain. It is a stateless reasoning step that sees schema and query results inside your workspace boundary. It never holds credentials, never reaches your systems directly, and secrets appearing in source data are redacted before it reads them.
- What happens if we leave?
- You export everything and we delete the organization. Export, memory erasure and account deletion are self-service, in line with India's DPDP Act and GDPR, see the privacy policy for retention details.
Where we are on certification
We would rather tell you the truth than show you a badge wall. Here is the actual position today.
- DPDP Act and GDPRSelf-service rights today
- Per-organization encryptionIn force today
- SOC 2 Type IIPlanned
- ISO 27001Planned
Ask us for the current security overview and our subprocessor list. We will send both, and tell you what is not covered yet.
Put it under review
Send it to whoever says no in your organisation. We will answer a security questionnaire, walk your team through the guardrail engine, and run a live test where we try to make the agent do something it should not.
Report a vulnerability at contact. We acknowledge within two working days and will not pursue researchers acting in good faith under our acceptable use policy.