Security isn't optional, it isn't a premium add-on, and it isn't bolted on. Every safeguard on this page is built deep into the platform by design and included for every customer.
Aidealy measures your most sensitive asset - the work your engineers and AI agents ship every day. We built the platform so that data stays isolated, encrypted, and under your control, and so that what we do collect is always less than what people assume - we don't keep a copy of your repositories.
This page explains how. If your security team needs anything more, email our security team at security@aidealy.ai.
Tenant isolation
Every customer is isolated at every layer that matters: storage, encryption, AI credentials, and execution.
Separate per-tenant storage. Each customer's data lives in its own dedicated stores - separate object storage, separate tables, and separate analytics collections per tenant. Your data isn't pooled into a shared table with everyone else's.
Single-tenant execution. Every workload runs for one tenant at a time, scoped by a per-tenant identity (IAM) that can reach only that tenant's data and keys. No job mixes two customers' data.
A separate, dedicated AI-provider key. Your prompts are sent to whichever of our AI providers handles the request, under an AI credential dedicated to your tenant, not a single shared platform key pooled across customers.
Row-level security on relational data. Your core records are protected by database-enforced row-level security (RLS) keyed to your tenant - the database itself refuses to return another tenant's rows.
Encrypted in transit and at rest, with a key unique to your tenant. Your data travels over encrypted connections (TLS 1.2+) and is encrypted at rest under an encryption key provisioned just for your tenant. That key can never decrypt another customer's data, and it's rotated automatically. Keys are managed by Aidealy on your behalf via a cloud key-management service; Aidealy doesn't offer customer-supplied keys today.
AI security
Prompt injection is unsolved industry-wide. So we made the model the least-privileged part of the system - boxed in by deterministic controls that hold even when it's fooled.
Every chat request passes the same checks, top to bottom:
Verified identity at the door. Every request's token is cryptographically verified at the edge - or rejected before any backend code runs.
Bound to your own tenant. The backend re-verifies you and derives your tenant from that identity, never from what the client sends.
Screened before the model. Input is checked by machine-learning models for prompt-injection and jailbreak attacks before any model sees a word.
The model drafts the query, but it doesn't run it. The draft has to fit a fixed form, and the model has no tools of its own to call.
Vetted by plain code, not AI. Deterministic checks decide whether the drafted query runs: read-only and scoped to your tenant, or our platform blocks it.
We open the connection, not the AI. That happens in our backend before the model is involved, and the AI only ever gets results back, not access.
Off-limits by design. Your source code and secrets are never reachable by the model.
A question is the only thing a user controls. The query it produces is checked before anything runs, and it's our platform that runs it, not the model.
Data residency
Pick your data region when you onboard, and your stored data stays there. Aidealy keeps strict regional separation with no cross-region replication of your stored data - the region follows your tenant's choice, not the user's location. When you ask the analytics assistant a question, the analysis code it writes runs inside a locked-down sandbox that we open in your own region, and it is thrown away afterwards.
AI processing. Our two AI providers are Anthropic, PBC and OpenAI OpCo, LLC, both United States companies. Either of them may handle any AI step, and we may change which one handles what at any time, including as a fallback - that is not a change of sub-processor. Anthropic stores its API data in the United States and offers no European option; OpenAI's European option is supported in our software but is not switched on. Both work under strict no-training terms, with EU transfers safeguarded by the EU Standard Contractual Clauses. Only the prompt for that one request leaves your region; the data we store stays in it. The full detail is in our Privacy Notice.
Privacy
Aidealy reads your Git history through short-lived, ephemeral access - we don't retain a copy of your repository source. We measure what changed and how it moved over time, not a stored mirror of your codebase.
The Aidealy editor extension sends the prompts and responses your team writes with AI, and we turn them into the signals we measure. What you see in Aidealy is the analytics: the metrics, counts and labels.
When your team writes to the assistant, we label the message four ways: which part of the system it is about, what kind of work is being asked for, whether it raises a quality concern, and how it reads in tone. That is done on the text alone, and it is never used to infer anything about a person's health.
What this means in plain terms:
If you stop using Aidealy, you can export your work data before we permanently delete it. We don't hold it hostage, and we don't keep it indefinitely.
For exactly what we collect, how long each kind of data is kept, what happens to it when you leave, and your rights, see our Product Privacy Notice.
If you're an EU customer, the switching and exit information required by the EU Data Act, including the register of the data you can export, is published on our EU Data Act Information page.
Access
Aidealy is built for engineering leadership, with access controls and an audit trail to match.
Connect your own identity provider through SAML single sign-on (SSO), and your team signs in with the corporate login they already use.
Access is governed by roles - owner, admin, and member. Aidealy runs on named seats and is built for engineering leadership: only seat-holders can query Aidealy or view the data. Engineers don't have access, and there's no engineer-facing view. If a leader wants to share a specific insight, they do it directly, in a conversation - the product doesn't broadcast individual signals.
Aidealy records an audit trail of authentication and access events, administrative actions, and tenant-lifecycle operations - onboarding, offboarding, and SSO changes - each captured with the actor and a timestamp.
Aidealy fits into the tools your developers already use - Cursor and Claude Code - and it's governed by controls you set:
No separate login. Your developers keep using Cursor and Claude Code as they do today - there's no extra Aidealy password or license key to roll out.
Limited to your own people. Aidealy only accepts activity from people on an email domain your organization has verified, or from someone an admin has added and approved - so only people you've let in contribute to your workspace.
Enrollment on your terms. Add developers automatically, or require an admin to approve each one before any of their activity is collected.
One-way by design. The Cursor extension is designed only to send data to Aidealy. It doesn't read anything back - not your workspace, and not anyone else's.
How Claude Code connects. Claude Code is measured by a small background program, not by an editor extension, so it connects differently. It builds an identity from what is already on the machine, and our backend treats that as a claim to be checked, not as proof - it is accepted only for a verified company domain, a confirmed cloud-organisation identifier, or an address an administrator has approved. The Git email is only ever used to match an existing person, never to create one. Data flows one way. If part of it fails, it sends a failure report to our error-monitoring provider in the region it's configured for, carrying none of the developer's work and no name, email address or computer name (the provider records the approximate location of the IP address a report comes from), and you can turn that reporting off. It installs under the developer's own account, with files only that account can read, and it ships with a checksum manifest so you can verify what you downloaded.
Operations
The day-to-day practices behind the platform: how we ship changes, protect against data loss, and respond when something goes wrong.
Every code change is reviewed and must pass automated security scanning before it can merge and ship - including AI-assisted code review and automated dependency and code scanning. These checks are enforced on our production branches, not left to discipline. Our infrastructure is defined as version-controlled code, so every change is reviewable and traceable.
Critical data is backed up daily, and backups are kept immutable for 30 days, so they can't be silently altered or deleted - removing one early takes an audited emergency procedure. Restoring from them is part of our recovery planning.
We maintain a documented incident-response plan. As your data processor, we commit to notifying you of a personal-data breach affecting your data without undue delay - within 72 hours of becoming aware - as set out in our Data Processing Agreement.
Found a vulnerability? Email security@aidealy.ai.
Compliance
Aidealy's security, privacy and AI-governance program is designed to meet the requirements of SOC 2, ISO 27001, ISO 42001, and GDPR. We're early-stage and honest about it: we're not certified yet - and we won't show a badge we haven't earned. What we can show you today is the program - the controls, the data-handling practices, and the sub-processors behind them.
GDPR. We act as your data processor for the engineering data you connect, under our data-processing terms. We don't use your data for our own purposes or to train AI models.
Sub-processors. The third parties that help us run Aidealy (cloud hosting, AI providers, and supporting services) are disclosed in our sub-processor list, and we give customers advance notice before we add or replace a sub-processor, except where we must replace one urgently, in which case we tell you without undue delay and you keep your right to object. We assess our sub-processors' security and require data-protection terms in our agreements with them.
SOC 2 / ISO 27001 / ISO 42001. Designed to meet their requirements; certification is on our roadmap, not a claim we make today.
Security updates for our client software (EU Cyber Resilience Act). The Claude Code program we ask your developers to install is client software under the EU Cyber Resilience Act. From the day we first make it available to customers in the EU, the Act's reporting duties apply to it, and we will meet them.
Need a security questionnaire completed, or a countersigned copy of our DPA? Email us at security@aidealy.ai - we'll turn these around for your review.
Legal
What personal data we collect on this website, how long we keep it, and your rights.
The terms that govern your use of this website.
The cookies this website uses and the choices you have.
Our accessibility commitment and how to report an issue.
The third-party providers that process personal data for us, what each does, and where.
How to report a security issue to us.
How we process personal data on behalf of customers, including sub-processors and data transfers.
Terms for Aidealy's AI features, including the AI providers we use and our commitment not to train models on customer data.
How we handle personal data for the people who sign in to the Aidealy product.
What the Aidealy IDE extension collects from the developers who use it, and how it is handled.
Next step
Talk to us and we'll walk your team through how Aidealy isolates, encrypts, and handles your R&D data - and answer the hard questions.