NuePrism Security & Data Handling Overview
A current-state overview of how NuePrism accesses, processes, stores, protects, and uses customer data during a controlled pilot evaluation.
1. Purpose
This document gives prospective customers a transparent view of:
- What customer data NuePrism accesses
- How that data flows through the NuePrism architecture
- Where data is stored
- What information is provided to the AI reasoning layer
- How tenant access and network security are handled
- What is currently implemented, what is inherited from underlying infrastructure providers, and what is still being formalized or verified
2. Data Flow
Current flow:
The current application uses Jira as its production execution-data source. NuePrism processes Jira execution information to diagnose delivery conditions, identify supporting evidence, generate an execution verdict, and provide role-routed interventions.
The AI reasoning layer is used as part of this processing architecture. The underlying execution diagnosis is based on NuePrism's configured execution principles, deterministic signals, thresholds, team context, and supporting evidence.
3. Data Storage
Customer execution data is stored in NuePrism's application database for analysis and generation of execution verdicts, evidence, and recommendations.
- Backend hosting: AWS, region us-east-1 (North Virginia, USA)
- Database hosting: Supabase Pro, region ap-south-1 (Mumbai, India), PostgreSQL
- Retention period: For a pilot evaluation, retention and deletion terms are agreed with the customer before any customer data is onboarded
4. Data Protection
Data in transit is encrypted using HTTPS/TLS.
Data stored in Supabase is protected by Supabase-managed storage encryption, covering the underlying database storage/disk. Authorized admins and the backend application can read the data through the normal authorized database view — storage encryption is a disk-level control and is not a substitute for access control.
NuePrism does not store customer passwords — authentication is handled through Atlassian/Jira identity controls (see Section 6).
Network protection
- The AWS-hosted backend uses an AWS Security Group, which provides a stateful virtual firewall controlling permitted network traffic
Tenant isolation
Tenant isolation is implemented in the current NuePrism application architecture.
- Each customer/tenant is identified separately within the system
- API requests are validated against the applicable tenant context
- Database queries are restricted to data belonging to the requesting tenant
- A user associated with one tenant cannot access another tenant's Jira data, sprint data, or execution metrics
- Tenant-specific configuration and access are maintained separately
| Control | Status |
|---|---|
| Separate field-level encryption | Not currently used |
| Customer-managed encryption keys (BYOK) | Not currently used |
| Formal production access-review process | Being formalized |
| Defined cadence for periodic review of privileged/admin access | Being formalized |
5. AI / Model Handling
NuePrism uses AI reasoning together with structured execution evidence to generate analysis and recommendations.
Production AI provider
The current production AI reasoning flow uses the OpenAI Platform API. Based on the engineering team's current implementation, a smaller model is used for processing and a larger model for synthesis. Exact deployed model names are confirmed against the deployed environment configuration and provider usage records upon request.
Customer data sent to the AI layer includes
- Jira issue keys, titles, descriptions, type, status
- Story points, labels, priority
- Epic links / relationships
- Sprint metadata and sprint goals
- Changelog and transition history
- Assignee display names and change-author display names
- Numeric sprint and execution metrics
Not sent to the AI provider in the current production flow
- Jira comments
- Attachment contents
- Email addresses
- Authentication credentials
The data sent to the AI provider is not currently de-identified before processing. Therefore, assignee and change-author display names may be included in the AI-processing context.
Model training
According to OpenAI's published API policy, API data is not used for model training by default. The exact terms applicable to a given account remain subject to the production OpenAI account/project configuration and applicable provider agreement.
Provider data retention
Under OpenAI's standard API policy, API data may be retained for up to 30 days for abuse monitoring, unless different retention arrangements such as Zero Data Retention apply. Exact retention configuration is confirmed against the provider account and contractual terms.
Inference region
OpenAI processing is currently treated as US-based by default. Non-US data-residency options may be available through provider-level account/project or contractual configuration and would be reviewed separately if required.
Optional Gemini integration
NuePrism also contains an optional Google Gemini Developer API integration. This integration is currently disabled from the production NuePrism flow and is used only for internal evaluation. It would not be enabled for customer data without a separate review.
6. Access Control
NuePrism's current Jira experience uses Atlassian identity for end-user authentication. NuePrism does not maintain a separate customer password store for these users. MFA requirements therefore follow the authentication policies configured within the customer's Atlassian environment.
For the backend infrastructure itself:
- Production and database access is restricted to approved internal admins only — normal users have no direct access to the production server or database
- Backend API activity is logged with request ID and response time
- AWS and Supabase each provide their own administrative/audit logs, in addition to application-level logging
- Production and development environments are kept separate at both the database and repository level
The formal internal process for granting, reviewing, and revoking privileged production/database access is currently being formalized. The Atlassian Forge deployment and validation process is also currently in progress; this is separate from NuePrism's internal production-access governance.
7. Customer-Data Deletion
NuePrism currently supports partial cleanup when the Forge application is removed, including Jira issue snapshots, changelogs, Forge configuration, and Forge secrets.
A complete tenant-wide deletion mechanism covering all analysis records, user/admin records, logs, backups, and AI traces is still being completed. For a pilot evaluation, the exact deletion process and retention commitment is agreed with the customer before data is onboarded. NuePrism does not currently represent complete automated tenant deletion as fully available.
8. Backup and Recovery
NuePrism uses Supabase Pro's managed daily backup service.
- Backups are taken daily
- Retained for seven days
- Automatically removed after the seven-day retention window
If a restore is performed from a given backup point, the database returns to the state that existed at that backup time; transactions occurring after that point are not included in the restored data. A restore test was performed against an available daily backup point and confirmed successful. The same restore process applies to any available backup point within the seven-day retention window.
9. Compliance Status
NuePrism does not currently represent itself as SOC 2 or ISO 27001 certified. Enterprise security and compliance readiness is being formalized as the product progresses through enterprise evaluations.
Current areas being assessed or formalized include: SOC 2, ISO 27001, penetration testing, vulnerability scanning, incident-response process, data-retention policy, privacy/DPA/subprocessor documentation, backup/recovery procedures, and a formal privileged-access review process.
Where a control is provided by the underlying cloud, infrastructure, platform, or AI provider, it is identified separately as an inherited control rather than represented as a NuePrism certification. NuePrism's approach is to classify controls transparently as:
Implemented Inherited & verified In progress Not currently available
10. Pilot Approach
For a proposed pilot evaluation, NuePrism recommends:
- One Jira team
- Limited Jira scope
- A two-sprint evaluation period
- Agreed data-access permissions
- Agreed retention and deletion terms
- A security review before production customer data is connected
Before connection, the evaluating organization and NueArcus agree on: Jira access scope, Jira fields to be processed, data transmitted to the NuePrism environment and to the AI provider, applicable data-storage locations, provider retention terms, evaluation-period retention requirements, data-deletion expectations, and any additional security requirements from the evaluating organization.
The objective is to validate the product with the minimum necessary data exposure.
Want to discuss a pilot evaluation for your organization?
View the product tour or request a walkthrough with your team's own data.
Last updated: September 2026