Security posture

This page describes TalkIDE’s approach to isolation, data handling, and access control. It is a design explanation, not a compliance checklist. Where we do not have a verifiable fact to give you, we say so rather than fill the space.

Project isolation

Each project on TalkIDE runs in its own database schema, with its own credentials, on infrastructure that is logically separated from every other project. One tenant’s data is not reachable from another tenant’s application. This is not a policy boundary enforced by access controls alone. The schema-per-project model means the data literally does not share a namespace.

The same principle applies at the Kubernetes level. Each deployed application runs in its own namespace, and network policies restrict lateral movement between namespaces.

Who can see your code

The AI agents work with your code. That is the product. The question worth being precise about is: what happens to that code beyond the agents acting on it?

The agents process your code within the context window of the model API calls they make. Code is not stored separately from your project’s working tree. When you delete a project, its files and database are removed.

The TalkIDE team has operational access to the platform infrastructure in order to run the service. This is standard for any hosted platform. Human access to individual project data (code, database contents, uploaded files) requires explicit escalation, which is logged. Routine operations do not involve reading customer code.

Data residency

Projects are currently deployed to infrastructure in the us-east region by default. If your project has specific residency requirements (EU data protection regulations, for instance), this is a question worth raising directly before you start building. Region selection affects where your application’s database and file storage land, not just where the container runs.

The platform’s own control-plane infrastructure is US-based.

Credentials and secrets

Secrets your application needs (API keys, third-party credentials) are stored as Kubernetes secrets in your project’s namespace and injected as environment variables at runtime. They are not committed to source code and not visible in the workspace UI by default.

The platform provisioner that creates and rotates per-project database credentials uses SCRAM-SHA-256 authentication. Database passwords are never stored in plaintext; the provisioner holds a verifier, not the raw password.

What TalkIDE does not provide

A few things that some projects require, and that TalkIDE does not currently offer, are worth naming:

• SOC 2 or ISO 27001 certification. These audits take time and are on the roadmap, but are not complete.
• A signed Data Processing Agreement (DPA) for GDPR purposes as a standard offering.
• On-premises or VPC deployment. The platform is cloud-hosted. There is no self-hosted option currently.

If these are blocking requirements for your use case, the honest answer is that TalkIDE may not be the right fit yet. That may change, but not by the time you finish reading this page.