Security controls, stated plainly.
For security teams conducting vendor assessments. Everything Kandryn holds, touches, and refuses to do — with honest status on what is live, what is in progress, and what is not yet built.
Last reviewed: September 2026
Green = live and verifiable · Amber = in progress with target date · Grey = planned. We update this table when status changes.
What it will not do, and why you can check.
The controls above say what is in place. These say what Kandryn is architecturally unable to do — each one observable from your own repository and tracker rather than taken on trust.
Every key is stored against your user record in an isolated config table. There is no shared pool, no fallback to an environment variable in production, and no key is ever written to a log line. Each value is encrypted with AES-256-GCM — a fresh random IV and an authentication tag per value — before it is written, under a key held as an environment variable rather than in the database. A copy of the database on its own does not yield a usable credential: the key is not in it.
Projects, work items, runs and suggestions are all filtered by user on every read and write. There is no global collection a bug could expose.
Kandryn creates branches, commits and pull requests, all on task/<id>. It never merges and never writes to your default branch. The one thing it does overwrite is its own branch: re-committing a work item moves task/<id> to the new commit.
Items and test cases are pushed only when you ask. The single automatic write-back is a status change when an item closes.
Only the files the change planner selects as relevant to the work item, plus the detected stack profile, are passed to the agent pipeline. The planner additionally sees the directory listing — file names only, capped — so it can target paths that exist.
A run that fails records the error and stops. Nothing half-written reaches your repository, and stuck runs are swept after twenty minutes. A blocked Aegis gate records every finding and stops without writing anything to main.
Run Aegis on a committed run and it posts a kandryn/security check — a commit status on GitHub, a pull request status on Azure Repos. Require that check in a branch rule and the platform blocks the merge until a High or Critical finding is resolved. Until you do, the check reports but does not block. Kandryn never merges anything itself.
What Kandryn processes on your behalf.
- What
- Work item titles, descriptions, acceptance criteria
- Source
- Jira / Azure DevOps
- Stored by Kandryn
- Metadata only (title, status, AC count)
- Sent to AI
- Yes — included in the case file per run
- What
- The files the change planner selects as relevant to the work item, capped at ten per run. Without a plan, retrieval falls back to five files by keyword, or eight via the Graphify knowledge graph. The planner is also shown the directory listing — file names only, capped at 600.
- Source
- GitHub / Azure Repos
- Stored by Kandryn
- Not stored. Read at run time, sent to agents, discarded.
- Sent to AI
- Yes — the file sections selected for the run
- What
- Run status, timestamps, agent scores, PR URLs, commit hashes, Synthesia scores, Aegis findings (structured, not raw code)
- Source
- Generated by Kandryn
- Stored by Kandryn
- Yes — in Supabase PostgreSQL
- Sent to AI
- No
- What
- API tokens for Jira, GitHub, Azure DevOps, Confluence, Notion
- Source
- User-provided
- Stored by Kandryn
- Yes — per-user, in Supabase. TLS in transit.
- Sent to AI
- Never. Credentials are never included in any AI prompt.
- Logged
- Never. Credential values are never written to any log.
- What
- Email address, name, OAuth identity
- Source
- Sign-up
- Stored by Kandryn
- Via Clerk (authentication provider)
- Sent to AI
- No
- What
- Action names, timestamps, IP addresses, entity IDs
- Source
- Generated by Kandryn
- Stored by Kandryn
- Yes — 30–365 days depending on plan
- Sent to AI
- No
Kandryn does not process end-user PII, financial records, healthcare data, production database contents, or any data outside the software development workflow. It has no access to your environment variables or your GitHub Actions secrets — those are not repository contents and no token Kandryn holds can read them. A secret committed into the repository itself is a file like any other, and could be selected as context like any other; Aegis flags hardcoded credentials when it scans a change.
Within 30 days of contract termination, customer data — work items, change plans, generated code, and run history — is deleted from Kandryn systems. Audit-log records are deleted on the same schedule unless a longer retention period has been contractually agreed. Selected source-code file sections are read at run time and discarded, not retained (see Data handling above).
Which models run. What they see. What they never touch.
Kandryn is an AI orchestration layer, not an AI model. We use established model providers via their enterprise APIs. Here is exactly what runs and why.
| Agent | Model | Provider | Purpose | What it receives |
|---|---|---|---|---|
| Raptia | claude-sonnet-4-5 | Anthropic | Code generation | Work item + selected code files + stack profile |
| Fovea | gpt-4o | OpenAI | Code generation | Same case file as Raptia — run in parallel |
| Synthesia | claude-sonnet-4-5 | Anthropic | Ranking | Both suggestions + AC + stack profile |
| Veria | claude-sonnet-4-5 | Anthropic | Code review | Committed code + acceptance criteria |
| Aegis | claude-fable-5 · claude-opus-5 under zero data retention | Anthropic | Security scanning | One changed file per request — no other repo context |
Kandryn does not train any AI model, and holds no model-provider contract on your behalf — every call uses the keys you saved, so the terms, the retention settings and the usage all sit on your own Anthropic and OpenAI accounts. One consequence is worth stating plainly: the default security model requires 30-day retention and is unavailable to organisations configured for zero data retention, so Aegis falls back to a model that is not retention-gated.
Every API call is made using the customer’s own Anthropic and OpenAI API keys, stored per-user and never shared. You see the usage in your own Anthropic/OpenAI dashboards. Kandryn does not proxy or aggregate model costs.
If Kandryn changes the model used for any agent that affects code-generation output, customers receive 30 days’ written notice before the change takes effect. The model that produced a result is recorded on every suggestion and on every security scan.
By default, no code is committed to your repository without explicit developer action. Kandryn presents two competing suggestions and a ranked recommendation; the developer chooses which to commit, then clicks. An optional per-run auto-commit setting — off by default — commits the top-ranked suggestion automatically only when you enable it. Kandryn never merges, and never writes to your default branch. Re-committing a work item does move its own task/<id> branch to the new commit, so treat that branch as Kandryn’s.
Who can reach what, and how it is enforced.
Email / password or OAuth via Clerk. MFA available (TOTP). MFA enforcement for the Enterprise plan: Q4 2026. Session management: Clerk-managed, with token expiry and refresh.
SSO / SAML 2.0 — Okta, Azure AD, Google Workspace. Target: Q4 2026.
Every API endpoint requires authentication. Every database query is scoped to the authenticated user’s ID. Team admins see team data; members see their own runs. No endpoint accepts a userId parameter from the request body — it is always derived server-side from the authenticated session.
// Every run query — representative example where: and( eq(runs.userId, req.userId), // always server-set eq(runs.projectId, projectId) )
Two named individuals (co-founders) have Supabase database access, protected by MFA. No other staff have database access. There is no Kandryn admin UI for viewing customer data. Supabase infrastructure access logs are maintained by Supabase (SOC 2 Type II certified).
Where every byte lives.
All primary storage and processing is in the United States. No data is transferred to or stored in EU regions.
| Component | Provider | Region | Certification | Data category |
|---|---|---|---|---|
| Application hosting | Vercel | US East (AWS/CF) | SOC 2 Type II | All application traffic |
| Database | Supabase | AWS us-east-1 | SOC 2 Type II | All stored data |
| Authentication | Clerk | US | SOC 2 Type II | User accounts + sessions |
| Resend | US | SOC 2 Type II | Run notifications | |
| Graphify microservice | Railway | US | — | Repository clone at index time (discarded) |
| AI inference (primary) | Anthropic | US | — | Code + work item content |
| AI inference (secondary) | OpenAI | US | SOC 2 Type II | Code + work item content |
The Graphify microservice clones the repository to a temporary directory, extracts the knowledge graph, and discards the checkout — it has no persistent storage. Kandryn stores only the resulting graph (file paths and symbol names), never file contents, and no code content is stored outside Supabase.
EU customers (future): EU data residency is on our roadmap for 2027. Customers requiring EU storage should contact us to discuss timeline.
Every significant action, recorded. Admin-only.
The audit log records all of the following with timestamp, user ID, IP address, and relevant metadata:
- Who can access
- Team admins only
- Where
- Settings → Audit log
- Formats
- In-app filterable view + CSV export
- Filters
- Action type, team member, date range
Credential values are never logged — only key names. Audit rows are immutable. There is no delete or update endpoint for audit log entries.
Every third party that touches your data.
Kandryn does not sell data to any third party. Sub-processors are used only to deliver the product.
| Name | Purpose | Data received | Location | Their certification |
|---|---|---|---|---|
| Supabase (PostgreSQL) | Database | Work items, runs, scores, and integration credentials — the credentials as AES-256-GCM ciphertext, not readable values | US East | SOC 2 Type II |
| Clerk | Authentication | Email, name, OAuth identity, session tokens | US | SOC 2 Type II |
| Anthropic | AI inference | Work item content + selected code file sections | US | Your own account terms — Kandryn calls with your key |
| OpenAI | AI inference | Work item content + selected code file sections | US | SOC 2 Type II · your own account terms |
| Vercel | Application hosting | All application traffic (no persistent storage) | US | SOC 2 Type II |
| Resend | Email address + run outcome summary | US | SOC 2 Type II | |
| Railway | Graphify service | Repository clone at index time (no persistent storage) | US | — |
| Atlassian (Jira / Confluence) | PLM sync · docs — when connected | Work item titles/descriptions; runbooks, if published to Confluence | Per customer instance | SOC 2 · ISO 27001 |
| Microsoft (Azure DevOps / Repos) | PLM · source — when connected | Work items, and repository code when Azure is the connected Git provider | Per customer tenant | SOC 2 · ISO 27001 |
| Notion | Docs — when connected | Runbooks, if published to Notion | US | SOC 2 Type II |
Credentials (Jira tokens, GitHub PATs, Azure DevOps tokens) are stored in Supabase only. They are never sent to Anthropic, OpenAI, Resend, Railway, or any other sub-processor.
Last updated: August 2026. We notify customers of material sub-processor changes with 30 days’ notice.
Questions about sub-processors or to request a copy of our DPA: security@kandryn.com
Where we are. Where we are going.
We do not claim certifications we do not have. Here is the honest status of each compliance programme.
We have engaged a compliance automation platform and begun the readiness assessment. The observation period for Type II certification begins Q4 2026. Expected completion: mid-2027. Enterprise customers can request our current security controls documentation as a bridge.
An external penetration test of the Kandryn web application and API is scheduled for Q4 2026. We will publish the test scope, date, and findings summary upon completion.
Kandryn does not process California consumer personal data (end-user PII). Developer accounts are covered under our privacy policy. Kandryn operates as a service provider under CCPA — data is processed on your behalf, not for our own commercial purposes.
ISO 27001 certification is planned as part of our EU expansion programme. We will begin this process after SOC 2 Type II is complete.
Security questions, vulnerability reports, or to request our security controls documentation:
security@kandryn.comWe respond to security questions within 1 business day.
Found a vulnerability? Please disclose responsibly. We do not currently have a formal bug bounty programme, but we acknowledge and credit responsible disclosures.
To report a security vulnerability, email security@kandryn.com with details. Please do not disclose publicly until we have had 90 days to investigate and remediate.