Security Statement
Nexture AI LLC
Effective Date: October 1, 2026
This document was last reviewed and updated on the effective date above.
Brand notice. This service is offered publicly under the name MiaSure. "MiaSure" is a trade name of Nexture AI LLC, the Wyoming limited liability company that operates the Service and is your contracting party under this document. Any reference herein to "Nexture AI," "Nexture AI LLC," "the Company," "we," "us," or "our" means Nexture AI LLC operating as MiaSure.
At Nexture AI LLC ("Nexture AI," "we," "us," or "our"), we understand that the security and confidentiality of your data, particularly Nonpublic Personal Information (NPI) and sensitive insurance documents, are paramount. This Security Statement outlines the robust technical and organizational measures we implement to protect your information and ensure the integrity, confidentiality, and availability of our Service.
Our security program is designed to meet or exceed industry best practices and to comply with relevant regulations, including the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule for the protection of financial consumer information.
1. Our Commitment to Security
We are committed to maintaining a secure environment for all data processed through the MiaSure platform. Our comprehensive security program is continuously evaluated and updated to address evolving threats and new technologies.
Our security program is overseen by a designated qualified individual responsible for implementing and enforcing our information security policies, as required under the GLBA Safeguards Rule. This individual reports directly to executive leadership on the status of our security program and any identified risks.
2. AWS Shared Responsibility Model
Nexture AI leverages Amazon Web Services (AWS), a leading cloud computing platform, for our infrastructure. We operate under a shared responsibility model:
- AWS's Responsibility (Security of the Cloud): AWS is responsible for the security of its global infrastructure, compute, storage, networking, and the physical facilities where data resides. AWS adheres to numerous compliance standards (e.g., SOC 2, ISO 27001, PCI DSS Level 1, GLBA-readiness, HIPAA-eligibility).
- Nexture AI's Responsibility (Security in the Cloud): We are responsible for security in the AWS cloud, which includes the secure configuration of our application, data, operating systems, network settings, and user access management. Our primary AWS region for data storage is us-east-1 (N. Virginia).
3. Technical Security Measures
We implement a multi-layered approach to protect your data across its lifecycle:
3.1. Data Encryption:
- Encryption in Transit: All data transmitted between your device and our Service, and between our internal services, is encrypted using industry-standard Transport Layer Security (TLS/SSL) protocols (HTTPS) to prevent eavesdropping and tampering.
- Encryption at Rest: Your uploaded insurance documents and the structured policy data we extract from them are encrypted at rest by our application using AES-256-GCM, under per-account keys that are themselves protected by a key held in AWS Key Management Service (KMS). The following are all stored as ciphertext at rest:
- Uploaded PDFs and OCR transcripts in S3 (encrypted by our application with AES-256-GCM under per-account keys before upload; the bucket also applies S3 server-side encryption by default, SSE-S3 with AES-256)
- The named insured, carrier name, policy number, and document filename on each policy, and your clients' names
- The full structured extraction payload for every policy (coverage limits, deductibles, premiums, exclusions, schedules, endorsements)
- Agent reasoning, validation findings, and field-edit audit trail
- Deliverable content (Coverage Reviews, SOI HTML, edit-request history, review-session snapshots)
- Communications content (chat bodies, email bodies, meeting notes and transcripts, quoted text)
- Client contact details (emails, phone numbers, addresses, named contacts)
- Your account email address, name, and company (under a separate server-held key, with a keyed one-way index so that sign-in by email still works)
- Cross-tenant audit log payloads
- What Is Not Encrypted by Our Application: A limited set of information is stored without application-level encryption: your firm's business name; internal identifiers, timestamps, status values, and categories used to route and scope records; numerical search representations (embeddings) derived from document text; and the platform-wide reference library of standard insurance forms, which contains no customer identifiers. This information is protected by our database provider's storage encryption, mandatory per-account access scoping, multi-factor employee authentication, audit logging, and TLS encryption in transit. Search over encrypted fields is performed by decrypting within your own account's scope, or through keyed one-way indexes.
- Key Management: Each account's data is encrypted under that account's own key. Account keys are stored only in wrapped (encrypted) form, and the key that unwraps them is protected by a customer master key in AWS KMS, which never leaves KMS in cleartext. Unwrapped key material is held in application memory only while it is needed.
3.1.1. Roadmap — Customer-Controlled Key Revocation: We are developing an enhanced encryption mode in which every customer-identifying field (including searchable identifiers) is encrypted with a per-brokerage AWS KMS key under your control. Under that mode, you will be able to revoke our access to your data on demand; once you destroy the wrap-key, no data — including data in our backups — will be recoverable, even by Nexture AI. This capability is targeted for a future enterprise release. While we develop it, your existing rights to deletion under Section 4.5 of this Statement and Section 8 of our Privacy Policy remain in effect.
3.1.2. What We Can and Cannot See: We want to be honest about the realistic limits of encryption-at-rest for an AI-powered platform. While your account is active, our extraction and AI agent systems necessarily process your documents in plaintext form (OCR, language-model extraction, SOIFA conversational responses, deliverable generation all require it). Employees with production code-deploy access therefore have the technical capability to access in-flight data while you are an active customer. We mitigate this with: (i) the access controls and audit logging described in Section 3.2; (ii) the terms we use our AI providers under, which, as stated provider by provider on our Sub-processors page, do not permit them to train their models on your data; (iii) a documented incident-response process; and (iv) the roadmap commitment in Section 3.1.1 above. We do not claim that our employees cannot read your data; we claim that they are contractually, technically, and operationally constrained from doing so without authorization, and that their access is logged and auditable.
3.2. Access Controls & Identity Management:
- Least Privilege: Access to systems and sensitive data is granted strictly on a "need-to-know" and "least privilege" basis. This ensures that only authorized personnel have access to the resources essential for their roles.
- Support Access Controls: Direct access to an individual customer account — including read-only "access as the account" support sessions — is restricted to authorized administrators, is disabled by default and available only when the account owner has explicitly enabled it, and every such session is time-limited and recorded in an audit log.
- Multi-Factor Authentication (MFA): Multi-factor authentication is mandatory for all Nexture AI employees accessing internal systems, administrative tools, and production environments. We also offer and highly recommend MFA for user accounts on our Platform to enhance your account security.
- Strong Password Policies: We enforce robust password policies for both internal systems and user accounts, requiring minimum length, complexity, and discouraging common or easily guessable passwords.
- Session Management: Secure session management techniques are employed to prevent unauthorized session hijacking.
3.3. Network Security:
- Managed Hosting: Our application runs on Render's managed hosting platform and uses AWS and MongoDB Atlas services in the United States. Our databases and caches accept only authenticated, encrypted connections.
- Edge Protection: Traffic to the Service passes through Cloudflare's network, which provides a web application firewall, rate limiting, bot protection, and the rules that restrict production access to the United States at the network edge.
- Application Controls: Our application enforces rate limits, validates requests at a single trusted server boundary, and restricts outbound requests to prevent server-side request forgery.
- Detection: We use automated monitoring and alerting designed to detect unauthorized access and malicious activity.
3.4. Secure Development Lifecycle (SDL):
Our development processes integrate security best practices from the outset. This includes:
- Secure Coding: Developers follow secure coding guidelines.
- Input Validation: All user inputs are rigorously validated to prevent injection attacks and other vulnerabilities.
- Regular Code Reviews: Security is a key aspect of our code review process.
- Dependency Management: Third-party libraries and frameworks are regularly updated and scanned for known vulnerabilities.
3.5. Security Monitoring & Logging:
- Our systems are monitored with automated error tracking, pipeline-health monitoring, and alerts, and AWS API activity is logged with AWS CloudTrail. Alerts on critical conditions are routed to our team for response.
- Detailed audit logs are maintained to enable rapid detection, investigation, and response to potential security incidents.
3.6. Data Backups & Disaster Recovery:
- We perform automated, regular, and redundant backups of all critical data to ensure data availability and recoverability. Backups are encrypted and stored in geographically diverse locations within AWS.
- We have a documented disaster recovery plan that outlines procedures for rapid data restoration and business continuity in the event of a major outage or data loss incident.
3.7. Penetration Testing & Vulnerability Assessments:
- We conduct regular vulnerability assessments and penetration testing of our application and infrastructure to identify and remediate potential security weaknesses.
- Testing is performed by qualified internal personnel. We intend to engage independent third-party security firms periodically as our program matures.
- Identified vulnerabilities are prioritized and addressed based on severity, with critical issues remediated promptly.
4. Organizational Security Measures
4.1. Data Breach Response Plan:
- Nexture AI has a comprehensive, documented data breach response plan. This plan outlines clear procedures for incident detection, containment, eradication, recovery, and post-incident analysis.
- Compliance with State Laws: In the unlikely event of a security incident involving personal information, we are committed to complying with all applicable federal and state data breach notification laws, including timely notification to affected individuals and relevant regulatory bodies.
4.2. Vendor Security Management:
- We conduct thorough due diligence on all third-party service providers (our sub-processors) who handle your data, including our hosting providers, OCR providers, AI language-model and voice providers, and our payment processor. The current list is on our Sub-processors page.
- We enter into robust contractual agreements (e.g., Data Processing Addenda) with these providers, obligating them to adhere to high security and privacy standards, consistent with GLBA and our own policies, and prohibiting them from using your data for unauthorized purposes.
4.3. Employee Security Awareness Training:
All Nexture AI team members undergo mandatory and regular training on data privacy, security best practices, and our internal security policies and procedures. This ensures our team is equipped to protect your data effectively.
4.4. Internal Security Policies:
We maintain comprehensive internal security policies and procedures governing data handling, access management, incident response, and acceptable use of company resources to ensure consistent application of our security program.
4.5. Data Disposal & Secure Deletion:
Two-stage deletion model:
- Trash (soft delete): Moving a document to Trash marks it as hidden from your active library. The document is filtered out of every list, search, deliverable, calendar event, and notification that references it, but the underlying record and its extracted data remain in our database until you take the next step. Trash has no automatic expiry — trashed items remain available for restore indefinitely unless you choose to permanently delete them.
- Permanent deletion (Delete Forever): When you choose to permanently delete a trashed document, our cascade-deletion routine removes the corresponding records from all active systems within minutes of the request, including:
- The Document record and all extraction collections (coverage, limits, schedules, claims, audit trail)
- The canonical policy record and locked snapshots
- The encrypted PDF and extraction reports in S3
- Page images, page indexes, and any rendered artifacts
- The transcript file
- Indexed chunks in our semantic-search index
- Shares, share-conversation history, and review-session snapshots tied to the policy
- Workspace and view memberships referencing the policy
- Calendar events, notifications, and deliverable edit-requests tied to the policy
- Draft deliverables made from the policy, with their files and edit history
Published or sent documents are kept as business records. A deliverable you published or sent is not removed when the policy it was made from is permanently deleted: it keeps its own record and files, is marked as made from a deleted policy, and is removed when you permanently delete it individually or close your account. Each permanent deletion records which published deliverables were kept.
Backups: MongoDB Atlas point-in-time backups and S3 versioned copies are governed by their respective retention policies. MongoDB Atlas backups age out on the next rotation cycle (typically 30–90 days). Our S3 storage has versioning enabled: when a stored file is deleted, the deleted object becomes a noncurrent version that a bucket lifecycle rule removes within 90 days. We do not separately purge backups on demand today; once the customer-controlled key revocation feature described in Section 3.1.1 ships, revoking your wrap-key will render all ciphertext — including in backups — mathematically unrecoverable, even by Nexture AI.
Account-level deletion: If you close your account entirely, we retain limited account metadata (email, account creation/closure timestamps) for up to three (3) years as described in our Privacy Policy § 7. All your uploaded documents, extracted data and deliverables, published ones included, are permanently deleted.
5. User's Role in Security
While we implement extensive security measures, your role as a user is vital in maintaining the security of your account:
- Use strong, unique passwords for your Nexture AI account.
- Enable Multi-Factor Authentication (MFA) if offered.
- Keep your login credentials confidential.
- Monitor your account for any suspicious activity.
- Report any suspected security vulnerabilities or incidents to us immediately at [email protected].
6. Compliance & Certifications
Nexture AI is committed to complying with all applicable data protection laws and regulations in the United States, including the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule. Our security program is designed with these requirements in mind.
Our infrastructure provider, Amazon Web Services (AWS), maintains numerous industry certifications including SOC 2 Type II, ISO 27001, PCI DSS Level 1, and HIPAA eligibility. Nexture AI leverages these certified services as the foundation of our security posture. We are actively working toward obtaining our own SOC 2 Type II certification and will update this Security Statement as our compliance program evolves.
7. Responsible Disclosure
We value the security research community and encourage responsible disclosure of any security vulnerabilities discovered in our Service. If you believe you have found a security vulnerability, please report it to us at [email protected].
When reporting, please include:
- A description of the vulnerability and its potential impact.
- Steps to reproduce the issue.
- Any supporting evidence (screenshots, logs, proof-of-concept code).
We commit to acknowledging receipt of your report within two (2) business days and will work to validate and address confirmed vulnerabilities promptly. We ask that you give us a reasonable period to remediate before any public disclosure.
8. Changes to This Security Statement
We may update this Security Statement from time to time to reflect changes in our security practices or for other operational, legal, or regulatory reasons. We will notify you of any material changes by posting the new Security Statement on this page and updating the "Effective Date" at the top. We encourage you to review this Security Statement periodically.
9. Contact Information
If you have any questions or concerns about our security practices, please contact us at: