Security & Data Handling
This page exists to answer a client security review without a call. If something here does not cover your question, ask and we will answer specifically rather than generally.
1. Deployment model
Our default is that the system runs on your infrastructure — your servers or your cloud tenancy — not ours. Your data stays inside your control boundary. Where an engagement requires a Kamaan-hosted component, it is named in the SOW along with its region and its retention.
2. Access control
- Least privilege by default. Engineers get the narrowest access that permits the work, scoped to a single client.
- Access is time-bound and reviewed at every engagement milestone.
- Read-only access first. During Blueprint we connect read-only and automate nothing.
- Secrets are held in a managed secrets store, never in application code or configuration files.
- Access is revoked within one business day of an engineer leaving an engagement.
3. Model providers
Every LLM call routes through an internal abstraction layer, so a provider can be swapped by configuration. We use enterprise or zero-retention terms with providers where available, and we do not permit client data to be used for training general-purpose models. Where a client cannot send data to a commercial API at all, we deploy open-weight models on client infrastructure.
4. Agent governance
This is the part most security reviews are actually worried about, and it is a design property rather than a policy:
- Every agent action is logged with its inputs, its reasoning trace, its confidence and its outcome.
- Every action is attributable to a specific agent version and a specific approver.
- Every action is reversible, or it is gated behind human approval.
- Autonomy is earned against evidence, never granted by date. Three categories never open automatically: money movement, anything sent to a customer, and anything affecting a person's employment.
5. Observability
Every system we ship is instrumented from day one with self-hosted observability, so traces stay in your infrastructure. We do not deploy what we cannot measure, and you get the same visibility we have.
6. Data handling
| Question | Answer |
|---|---|
| Where does our data live? | Your infrastructure by default; any exception is named in the SOW |
| Is it encrypted? | In transit and at rest |
| Who at Kamaan can see it? | Only engineers assigned to your engagement, under least privilege |
| Is it used to train models? | No |
| Can we export everything? | Yes — prompts, eval benches, workflows and configuration, as JSON or Markdown, at any time |
| What happens at the end? | Deleted or returned per the MSA timeline, confirmed in writing |
7. Incident response
If we become aware of a security incident affecting your data, we notify you without undue delay, with what we know, what we do not yet know, and what we are doing. We do not wait for a complete picture before telling you there is a problem. Where a reportable breach occurs, we support your notification obligations and meet our own under the DPDP Act.
To report a vulnerability, write to admin@kamaan.ai. We will acknowledge within 2 business days. We do not currently run a paid bounty, and we will not pursue anyone who reports a genuine issue in good faith.
8. What we do not claim
We are a small company and we would rather be precise than impressive. We are not currently SOC 2 or ISO 27001 certified. We architect to those control families and can walk you through our position control by control, but we will not imply a certification we do not hold. If your procurement process requires one, tell us early so we can be honest about timelines.