Security and data
This page describes how Naia Build handles data during a session: what is transmitted, where it goes, and what safeguards are in place. It is intended to support technical evaluation and organizational compliance assessment.
Infrastructure
Naia Build operates as a server-side service maintained and operated by Neptune Software. The developer’s browser client connects directly to Neptune’s WebSocket server, which acts as a secure intermediary between the client and the AI provider. No server-side installation or deployment is required on the customer’s side.
All processing occurs in volatile memory. Naia Build does not write to disk, database, or any external storage at any point during a session.
Session data lifecycle
Each session is fully isolated. When a session ends (whether through a deliberate close, a connection loss, or a Naia Build restart), all in-session data is discarded. This includes your developer prompts, the application context assembled for each request, any source code fragments retrieved during the session, and the full conversation history.
Application components generated during the session are saved within the Neptune DXP environment as part of the standard application. The session context that produced them is not retained.
There is no mechanism by which context from one session carries into another. Each session begins with no knowledge of previous sessions.
Request records retained for reporting are distinct from in-session context. The Naia Build Dashboard draws on per-request logs, for example, prompt summary, token counts, cost, and the generated response, retained in the Neptune DXP Portal. These records are scoped to the originating developer and are not visible to other users. In-session conversational context, by contrast, is discarded when the session ends.
Data classification
The following tables define precisely what data leaves a developer’s local Neptune DXP environment during a session, and where it goes.
Sent to the AI provider
| Data | Description | When transmitted |
|---|---|---|
Developer’s prompt |
The text of the task or instruction submitted |
Every request |
Application structure |
Component counts, page names, model names |
Every request |
API schema metadata |
Field names and data types only |
When APIs are connected |
Source code fragments |
Individual component or script content |
Only when explicitly requested by the AI to complete a specific task |
Attached files |
Screenshots, design references, or an uploaded spreadsheet used to generate the application |
Only when attached by the developer |
|
An uploaded spreadsheet is customer business logic. Its content is transmitted to the AI provider for generation, in the same way as other attached files. Upload only files appropriate for your organization’s data-handling policy. |
Sent to the Neptune DXP Portal
| Data | Description | Contains source code? |
|---|---|---|
Anonymized user ID |
Hashed identifier used for licence and usage tracking |
No |
User email address |
Identifies the developer for licensing, authorization, and per-user usage tracking |
No |
Application name and system URL |
Identifies the application and the system a request originates from |
No |
Task metadata |
Question summary, token count, estimated cost |
No |
Request and response logs |
Prompt summary and the generated Naia Build response, retained for the Naia Build Dashboard and visible only to the originating developer |
Generated output may include code |
Stored in the developer’s browser
| Data | Description |
|---|---|
AI provider preference |
The selected AI model |
Notification settings |
Display preferences for tab notifications |
Never collected, stored, or transmitted
The following categories of data are not sent to any external system under any circumstances:
-
Customer business data or end-user records
-
Personally identifiable information (PII) of end users
-
Database contents, connection strings, or query results
-
Credentials, API keys, or secrets from customer applications
-
Bulk application source code
|
Developer identity data, for example your user email address, is transmitted to the Neptune DXP Portal for licensing and usage tracking. This is distinct from end-user personally identifiable information (PII), which is never collected or transmitted. |
API schema handling
When an application has API operations configured in the Data tab, Naia Build shares a limited subset of that API’s definition with the AI model. The distinction between what is and is not transmitted is significant.
Transmitted to the AI model: API name, data source type, operation type, field names, field data types
Not transmitted to the AI model: API endpoint URLs, authentication credentials, API response data, connection details
The AI receives enough structural information to generate correctly typed and bound components. It does not receive the means to call the API directly, nor does it receive any data the API returns.
Source code exposure controls
Naia Build is designed to retrieve source code fragments on a targeted, on-demand basis, that is to say, only when the AI explicitly requires a specific component to complete a task. The following controls prevent iterative retrieval from reconstructing a full application codebase:
| Control | Detail |
|---|---|
System prompt constraints |
The AI is explicitly instructed to request only the specific components required for the current task |
Session scope |
Conversation history and retrieved context are cleared at session end |
Tool design |
Retrieval tools are scoped to individual components, not bulk export operations |
In-memory processing |
All retrieved code exists in volatile memory only and is discarded at session end |
BYOK key handling
When your organization uses the Bring Your Own Key model to enable Claude, the API key is stored at account level in the Neptune DXP Portal. Neptune proxies requests to the AI provider using this key but does not have visibility into the organization’s Anthropic billing account.
The key is stored in Azure Key Vault, not in Neptune application tables. After you save the key, only the Naia Build server can read it, and only while you are signed in. Neptune has no standing access to the key value and does not log it.
A configured key is available only to systems that belong to that account. A key set for one account cannot be used by systems under another account. Where an account holds multiple keys, each key is scoped to the team it is assigned to, and its usage is attributed to that team.
Key management, including rotation and revocation, is the customer’s responsibility, performed through the Neptune DXP Portal. Neptune does not store or have access to the key beyond its use as a pass-through credential for proxied requests.