What you can verify yourself.

Kastel is one product, hosted in three possible ways. The answer to "where is my data" depends on the mode you choose, never on the plan you pay for.

• Said plainly: in managed mode, the account, billing and console run on a conventional multi-tenant control plane, as with most hosted providers. Only your engine instance and your company memory are isolated and never shared with another customer.
• Engine telemetry is off by default, across all three modes: no byte leaves toward Kastel infrastructure until you explicitly turn it on.

Access control is structural: it runs in the free core, across all three hosting modes, not only on a paid plan.

• Every person and every connected AI receives a scoped, revocable access token. The effective perimeter is the intersection of what the connector allows and what the person the AI is acting on behalf of is themselves allowed to see.
• This rule applies on every read path, including those an AI agent takes: it is enforced in the database, never applied afterward by an application-level filter that could be bypassed.
• A denied access returns a response identical, byte for byte, to one for a resource that doesn't exist: there is no way to infer by elimination what is hidden behind the refusal.
• Each employee's personal memory is protected at the database row level itself, including against a misconfigured application access path. In managed mode, that database runs on infrastructure we operate: see the note on administrators in section 04.
• Steering these rights from a web console - roles, teams, an approval inbox for sensitive actions - is available from the Team plan. Single sign-on (SSO, OIDC or SAML) is available from the SME plan, with roles re-read on every request: a revocation takes effect immediately.

What an IT security team checks first when it inspects a vendor.

• Your AI provider keys and the instance's other secrets are encrypted at rest; the engine refuses to start if a secret appears in plaintext in its configuration file.
• Encryption in transit is mandatory, not optional: as soon as a Kastel server is exposed beyond the local machine, it refuses to start without a TLS certificate.
• In self-host, the application role that connects to your database is not a superuser by default, at install time: that is what makes the protection of personal memory impassable by the application itself, as long as that separation is kept.
• Disk and backup encryption remains the responsibility of the operator of the underlying infrastructure - yours in self-host, ours in managed.

The audit trail you can hold us to is this chain, never the log of its internal git repository. That repository versions your company memory, but it is neither cloned nor exposed: every access goes through the MCP protocol or the console, behind the same permission filter as any other read.

• Every governance event is sealed into a hash chain, and the entire chain is re-verified on every read, not only on write.
• A break in the chain is disclosed with its exact point, never hidden.
• Every governed AI request traces an identifier, the fingerprint of the content sent and the model used - replayable afterward by you or by your auditor.
• Optionally, off by default, these events can be relayed to your SIEM: identifiers and fingerprints only, never the content.
• An honest reservation: nothing is tamper-proof against the instance's administrator. In self-host, that administrator is yours: the chain makes their action visible and dated, it does not claim to make it impossible. In managed mode, it is a Kastel administrator, held to that by contract rather than by technical impossibility - and because we then operate both the instance and the mechanism that attests to it, an anchor for the chain independent of us is not yet delivered.

You decide what each AI is allowed to see. That's the product's principle, stated plainly: the content your Kastel judges relevant to answer does reach the AI provider you connected, under that provider's own keys and its own policy.

• Your own AI provider keys (BYOK) are mandatory, including in managed hosting: Kastel never resells inference and takes no margin on it.
• A declarative registry references what each provider publishes about the retention of your data - never a Kastel guarantee standing in for the provider's own. To verify contractually with your chosen provider before any sensitive content.
• A destination policy denies by default: content classified confidential is only sent to a provider under a contractual zero-retention commitment, or to a local model. Every refusal is itself sealed into the audit chain, never silent.
• You can also connect a model that runs entirely on your own infrastructure. In that specific configuration, no inference call goes out to an external provider. That is a configuration choice you make, not a Kastel commercial offering.

The GDPR right to erasure isn't just a written procedure: your data protection officer can replay it themselves, on your own instance.

• The proof consists of ingesting a known test item, triggering erasure, then verifying that item has become unfindable - in indexed text, search vectors and the embedding cache.
• Each erasure seals its own event into the audit chain, with an attestation verifiable independently of Kastel.

Disclosed systematically: erasure is never presented without its reservations.

• The versioned history of your company memory, whose purge is a deliberate act, never automatic.
• Backups kept by the infrastructure operator, outside Kastel's perimeter.
• The source system of the original content - the mailbox or tool it was imported from.
• The BYOK AI provider that already received that content before erasure, under its own retention policy.

The perimeter is the same for every customer, with no exception and no case-by-case negotiation.

• They receive the complete specification dossier for every mechanism that touches your data: access control, destination policy, encryption, erasure, audit chain.
• Several invariants are already verifiable today, with no Kastel account and no proprietary tooling: each attestation's signature - erasure, export - verifies offline with your organization's public key; the release manifest and the deployed image verify with standard tools (openssl or libsodium); the absence of any network call to Kastel infrastructure in self-host is an invariant continuously tested in our CI, on top of being directly observable on your own traffic.
• What's still being assembled: a ready-to-run harness to replay black-box, on your own instance, the isolation and access invariants (personal memory, AOR denial, destination policy), and a turnkey script for the erasure proof - the procedure exists and is documented, only the ready-to-execute script is still missing.
• We commit to giving their mandated auditor or pentester the right to black-box test their own instance: the access surface, the audit chain, the erasure path - without having to take Kastel's word for it. That commitment is being integrated into our contract.
• They never receive the engine's source code - for no one, not even under a non-disclosure agreement. That is a deliberate choice, not an oversight: the complete specification of the behavior, and the right to verify it black-box on their own instance, is the trade-off.
• For a regulated dossier, a proof dossier structured around Article 12 (record-keeping), Article 14 (human oversight) and Article 10 (data governance) of the EU AI Act is available on the Enterprise plan. Every line points to a command your auditor runs themselves; this is neither legal advice nor a determination of compliance. A DORA annex reuses these same proofs for the financial sector; the full kit - exit plan, audit clause, subprocessor register - is not yet assembled.

Kastel holds itself to the same requirement it places on your other vendors: proof your data can leave, a commitment we keep for the rest.

• Total export of your company memory is available at any time, in an open format published under the Apache-2.0 license - readable and replayable without any Kastel tool.
• The free core stays free forever: your self-host instance depends on no license to renew, nor on any network call to Kastel to keep working - a continuously tested invariant in our CI, also verifiable on your side by simply observing your own network traffic.
• An escrow program for the engine's source code is being put in place, to cover the scenario where Pharos EURL could no longer operate.