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.
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 or design references |
Only when attached by the developer |
Sent to the Neptune DXP Portal
| Data | Description | Contains source code? |
|---|---|---|
Anonymized user ID |
Hashed identifier used for licence and usage tracking |
No |
Task metadata |
Question summary, token count, estimated cost |
No |
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
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.
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.