Security Policy

This Security Policy outlines how Cortexvia, operated by Shaik Afrid, trading as Cortexvia Technologies ("Company," "we," "us," or "our") protects your data and maintains security across our platform and Services. Cortexvia is committed to implementing industry-standard security measures to protect user data while delivering high-performance AI services. This policy should be read in conjunction with our Privacy Policy, Data Usage Policy, Terms of Service, Cookie Policy, API Policy, Compliance Policy, Developer Policy, and Refund Policy (collectively, the "Agreement"). The Company reserves the right to modify this policy at any time, and your continued use of the Services constitutes acceptance of any modifications.

1. Security Compliance and Certifications

1.1. Infrastructure Controls. Cortexvia hosts data on managed cloud infrastructure operated by contracted providers with established security controls and operational safeguards. 1.2. Encryption Standards. Sensitive user data, including passwords, authentication cookies, and API keys, is encrypted using industry-standard protocols. Passwords are hashed using bcrypt or equivalent algorithms with appropriate salt values. API keys are encrypted at rest and transmitted only over secure channels. 1.3. Access Controls. User data is logically isolated to prevent unauthorized access between accounts. Access to production systems is restricted to authorized personnel only and is subject to multi-factor authentication, audit logging, and regular access reviews. We implement the principle of least privilege for all system access. 1.4. Network Security. All communications between users and the Services are secured using HTTPS with TLS 1.2 or higher. Internal service-to-service communication within our infrastructure uses mutual TLS authentication. We implement network segmentation and firewall rules to restrict traffic to authorized paths only.

2. Security Incident Handling

2.1. Incident Detection. We maintain security monitoring systems to detect potential security incidents, including intrusion detection systems, log analysis, and anomaly detection algorithms. 2.2. Incident Response. In the event of a confirmed security breach affecting user data, affected users will be notified within a reasonable time as required by applicable law. The notification timeline depends on the nature and scope of the incident and applicable legal requirements. 2.3. Containment and Remediation. Immediate containment and remediation actions will be taken to limit the impact of any security incident. This may include isolating affected systems, revoking compromised credentials, and implementing additional security controls. 2.4. Post-Incident Review. Following any significant security incident, we conduct a thorough post-incident review to identify root causes and implement measures to prevent recurrence.

3. Infrastructure and Data Sovereignty

3.1. Cloud Platform. All data is securely stored on managed cloud infrastructure operated by contracted providers with established physical, network, and operational safeguards. 3.2. Data Center Security. Underlying data centers implement physical security measures such as restricted access, monitoring, and environmental controls managed by the infrastructure provider. 3.3. Geographic Distribution. Server regions may vary based on performance optimization, load balancing, and operational requirements. 3.4. Infrastructure Provider Security. Our infrastructure providers maintain their own security controls and practices for the systems they operate. Users should consult our published policies for additional details on how Cortexvia manages application-level security on top of provider infrastructure.

4. Cryptographic Protocols

4.1. Encryption at Rest. User data is encrypted at rest using industry-standard encryption controls. Encryption keys are managed through secure key storage systems or equivalent controlled mechanisms. 4.2. Encryption in Transit. All data transmitted between users and the Services is encrypted using TLS 1.2 or higher. We support modern cipher suites and disable legacy protocols known to have vulnerabilities. 4.3. Key Management. Encryption keys are rotated regularly according to security best practices. Access to encryption keys is strictly controlled and audited. 4.4. Cryptographic Limitations. Despite these security measures, no cryptographic system provides absolute security. The security of encryption depends on the continued integrity of the underlying algorithms and the security of key management systems.

5. Multi-Tier Processing Environment

5.1. Architecture Overview. The Services utilize a multi-tier architecture with distinct layers for web serving, application logic, data storage, and specialized processing. Each tier implements appropriate security controls. 5.2. Internal Processing. Core application logic, including user authentication, data storage, and basic processing, occurs within our secure cloud environment with full security controls. 5.3. Specialized Processing Resources. For specialized processing tasks requiring high-performance computing resources, data may be transmitted to external computational and infrastructure providers. These transmissions are encrypted in transit using TLS 1.2 or higher. 5.4. External Provider Security. External computational and infrastructure providers implement their own security measures and operate under their own security policies. These providers are selected based on their technical capabilities and security practices. However, Cortexvia does not control and cannot guarantee the security measures, internal access controls, employee vetting procedures, or incident response capabilities implemented by external service providers. 5.5. Security Responsibility. By using the Services, you acknowledge that the security posture of the overall system depends in part on the security measures implemented by external providers. Cortexvia is not responsible or liable for any security incidents, data breaches, or unauthorized access occurring within the systems of external service providers. 5.6. Sensitive Data Warning. Users should not submit highly sensitive, regulated, or classified information through the Services unless they have fully assessed and accepted the security risks associated with external processing. This includes protected health information, financial credentials, government classified information, and trade secrets.

6. Backup and Disaster Recovery

6.1. Backup Security. All backups are encrypted using the same encryption standards as primary data and are access-restricted to authorized personnel only. Backups are stored in geographically separate locations for redundancy. 6.2. Backup Frequency. We perform frequent backups and store them across multiple isolated cloud environments for redundancy. Backup schedules are designed to minimize potential data loss. 6.3. Failover Capabilities. If one server experiences issues, another isolated environment takes over to reduce service disruption. Our architecture is designed for automatic failover in most failure scenarios. 6.4. Recovery Limitations. In the rare event that both primary and backup servers fail simultaneously, data recovery may not be possible. Such catastrophic failures are extremely unlikely but cannot be completely eliminated. 6.5. Architecture Evolution. Backup architecture may evolve without prior notice to enhance security, reliability, and service continuity. We continuously evaluate and improve our disaster recovery capabilities. 6.6. Force Majeure Limitation. We commit to restoring the application service as quickly as possible following any incident, but we are not liable for lost user content in force majeure events or circumstances beyond our reasonable control.

7. Scalability and Redundancy

7.1. Horizontal Scalability. Cortexvia is designed with horizontal scalability in mind. We may add additional servers, storage nodes, and inference capacity without notice to handle growth and load spikes. 7.2. Modular Architecture. Services are architected to support modular expansion, allowing individual components to scale independently based on demand. 7.3. Redundancy Measures. While we maintain redundancy at critical layers including storage, networking, and power, we do not guarantee zero-downtime. Planned maintenance and unexpected issues may cause temporary service interruptions. 7.4. Architecture Evolution. Redundancy architecture may evolve over time to improve resilience, security, and performance without prior notice to users.

8. API Key Security

8.1. Secure Storage. Cortexvia stores API keys securely using encryption. API keys are never stored in plaintext and are protected by multiple layers of security controls. 8.2. User Responsibility. Once an API key is copied from the portal, it is entirely the user's responsibility to keep it safe. We are not responsible for compromised keys after they leave our dashboard. 8.3. Security Best Practices. Users should never share API keys publicly or commit them to version control systems. Store keys in environment variables, not in source code. Never expose API keys in frontend or client-side code where they can be extracted. 8.4. Key Rotation. Users should regularly rotate API keys and immediately revoke any keys that may have been compromised. New keys can be generated through the dashboard at any time. 8.5. Compromised Key Response. If you believe your API key has been compromised, immediately revoke it through the dashboard and generate a new key. Monitor your account for any unauthorized usage.

9. User Security Responsibilities

9.1. Account Security. Users are responsible for maintaining the confidentiality of their account credentials, including usernames, passwords, and API keys. Users should use strong, unique passwords and enable all available security features. 9.2. Authorized Access. Users should immediately notify Cortexvia of any unauthorized access to their account or any other security concerns. Prompt notification allows us to take protective measures. 9.3. Content Security. Users are responsible for the security and appropriateness of content they upload to the Services. Users should not upload content containing credentials, secrets, or other sensitive information that could be compromised if exposed. 9.4. Integration Security. When integrating the Services with third-party applications, users are responsible for ensuring those integrations are implemented securely.

10. Security Monitoring and Auditing

10.1. Continuous Monitoring. We implement continuous security monitoring to detect potential threats and anomalies. This includes monitoring of system logs, network traffic, and user activity patterns. 10.2. Security Auditing. We conduct regular security reviews and may engage third-party security firms for independent assessments. Findings from these reviews are used to improve our security posture. 10.3. Vulnerability Management. We maintain a vulnerability management program to identify and address security vulnerabilities in our systems. Critical vulnerabilities are prioritized for immediate remediation.

11. Contact Information

If you have any questions about this Security Policy or need to report a security concern, please contact us at:

Cortexvia
General Support: [email protected]
Legal Inquiries: [email protected]
Security Issues: [email protected]

By using the Cortexvia Services, you acknowledge that you have read and understood this Security Policy and agree to be bound by its terms.