Trust and security

Building a secure foundation for your business.

Corenth Technologies uses layered application, database, authentication, infrastructure, and operational safeguards to help protect customer accounts and business data during soft launch. Security assessment, penetration testing, remediation, and verification are currently underway as part of the platform's ongoing security-hardening process. This page distinguishes current protections, provider-backed controls, work still in progress, and longer-term security objectives.

Security principles

Clear principles for building and operating a responsible AI platform.

Security is an ongoing operational responsibility. Controls, monitoring, documentation, testing, access rules, and recovery procedures must continue evolving as the product and customer base grow.

01

Security by design

Security requirements should be considered at the beginning of product and feature planning rather than added only after implementation.

02

Privacy first

Corenth Technologies intends to collect only the information needed to provide, protect, and improve the platform.

03

Continuous awareness

System activity, availability, authentication events, and potential security signals are reviewed through available platform, application, and provider-level monitoring, with additional monitoring capabilities continuing to mature.

04

Least privilege

People and systems should receive only the access required to perform their authorized responsibilities.

05

Responsible AI

AI features should operate within defined boundaries governing the information they can access, process, retain, and return.

06

Transparency

Material changes affecting customer information, platform security, or data handling should be communicated clearly and responsibly.

Security priorities and ongoing verification

Core protections remain a continuing production priority.

Corenth Technologies is currently undergoing security assessment, penetration testing, remediation, and verification while continuing to review authentication, authorization, customer-data isolation, secrets handling, logging, monitoring, backup, and incident-response controls as the platform matures.

01

Database and organization isolation

Enable, verify, and continuously test Row Level Security, organization membership controls, and server-side authorization for customer information.

02

Authentication protections

Verify secure session handling, customer multi-factor authentication, password policies, login rate limits, abuse controls, email verification, and account recovery.

03

Secrets and environment security

Keep service-role keys, Stripe secrets, AI credentials, email credentials, and internal secrets outside public source code.

04

Audit logging and monitoring

Record important authentication, administrative, account, billing, and security events and create appropriate alerts.

05

Penetration testing and remediation

Continue active security testing, address identified findings, and verify remediation as fixes are completed.

06

Backups and recovery

Configure production backups, document recovery procedures, and verify that restoration works before relying on the system.

07

Incident-response process

Document ownership, investigation, containment, communication, recovery, and legal-notification procedures.

Security program

How Corenth Technologies protects the platform and customer data.

The descriptions below explain the current security approach, provider-backed safeguards, active testing and remediation, and controls that continue to mature. They should not be interpreted as an independent certification, completed audit report, service-level commitment, or guarantee.

01

Data encryption

Protecting information during transmission and storage

  • Encryption in transit — Production traffic between browsers, applications, infrastructure providers, and Corenth Technologies uses HTTPS/TLS where supported and configured by the production services.
  • Encryption at rest — Stored customer information relies on encryption-at-rest capabilities provided and configured through approved database, storage, and infrastructure providers.
  • Secure API communication — Protected production API requests use authenticated server-side controls and encrypted transport where applicable.
  • Backup encryption — Production backups should use encryption and storage safeguards appropriate to the selected infrastructure provider.
02

Authentication and account security

Safeguarding customer and administrative access

  • Secure password handling — Passwords should be handled through the authentication provider and must never be stored by Corenth Technologies in readable plain text.
  • Session management — Authentication sessions should support expiration, revocation, and invalidation based on account activity and security requirements.
  • Login protection — Authentication abuse protections rely on the configured identity provider and application controls. Rate limiting and additional abuse-prevention measures remain subject to ongoing production review.
  • Customer multi-factor authentication — Customers can enable authenticator-app multi-factor authentication from account settings. Accounts with a verified TOTP factor must complete the second-factor challenge before accessing the customer dashboard.
03

Customer-data isolation

Preventing one organization from accessing another

  • Row Level Security — Customer-facing production data uses organization-scoped access controls and Row Level Security policies where applicable. These policies should continue to be reviewed as schemas and features change.
  • Organization boundaries — Authenticated users are scoped to organizations they are authorized to use, with customer data access enforced through server-side and database controls.
  • Server-side authorization — Sensitive actions use server-side authorization rather than relying only on frontend visibility or hidden controls.
  • Isolation testing — Customer and organization isolation is a production requirement and should be regression-tested whenever authorization logic or customer-data schemas change.
04

Infrastructure security

Reducing exposure across hosted systems and services

  • Established infrastructure providers — Corenth Technologies uses established hosting, database, payment, email, and service providers to support production operations.
  • Restricted access — Production resources should deny unnecessary access by default and expose only the services required for platform operation.
  • Environment separation — Development, testing, and production information, credentials, databases, and integrations should remain appropriately separated.
  • Stripe payment processing — Stripe handles production checkout and subscription billing. Corenth Technologies does not directly store complete raw payment-card numbers in its application database.
05

AI security

Applying appropriate controls to AI-powered features

  • Organization separation — Customer prompts, conversations, outputs, files, and related information are intended to remain scoped according to organization and account permissions.
  • No cross-customer exposure — Information belonging to one customer must not be intentionally exposed to another customer.
  • Encrypted processing — Requests sent to approved AI providers use encrypted network connections provided by the applicable services.
  • Model-training position — Corenth Technologies does not use customer business information to train third-party foundation models on Corenth’s behalf without customer authorization. Provider-specific data handling remains subject to the applicable provider terms and Corenth disclosures.
06

Data privacy and ownership

Keeping customers in control of their information

  • Customer ownership — Customers retain their rights in the content and records they provide to the platform.
  • Account controls — Customers should be able to review and update appropriate account, profile, and business information.
  • Deletion requests — Customers may request deletion of account information, subject to contractual, legal, tax, accounting, security, and retention obligations.
  • Data export — Data export may initially be handled by request while self-service export capabilities are developed.
07

Access control

Restricting sensitive functions and administrative activity

  • Role-based access — Customer and administrative capabilities are restricted according to roles, organization membership, and server-side authorization rules where applicable.
  • Least privilege — Internal access should be granted only when necessary for approved responsibilities.
  • Administrative records — Administrative and security-relevant activity is logged where supported by the application and service providers. Audit coverage will continue to expand as the platform matures.
  • Team permissions — Customers should be able to manage access for users within their own organization according to available plan features.
08

Monitoring and logging

Improving visibility into availability and security events

  • Application error monitoring — Corenth Technologies uses Sentry for application error monitoring and observability to help identify production errors and operational failures. Sentry monitoring is separate from penetration testing and should not be interpreted as comprehensive security threat detection.
  • Audit and security events — Key authentication, billing, administrative, account, and security events are logged where supported by Corenth and its providers, with additional event coverage planned.
  • Threat signals — Monitoring rules should be implemented to identify suspicious access, abuse, unusual activity, and repeated authentication failures.
  • Operational alerts — High-impact production events should generate alerts for investigation where monitoring and provider alerting are configured.
09

Secure development

Building security into the engineering process

  • Code review — Production changes are maintained through source control and should be reviewed and tested before release.
  • Dependency management — Third-party packages should be reviewed, scanned, and updated to address known security issues.
  • Security testing — A cybersecurity contractor completed a penetration test of the Corenth Technologies website, and the findings were reviewed. Some identified findings still require remediation, and the website has not yet been retested. The assessment does not constitute security certification or a guarantee that all vulnerabilities have been eliminated.
  • Ongoing patching — Frameworks, dependencies, infrastructure, and service configurations should be maintained and updated over time.
10

Incident response

Preparing to investigate, contain, and recover

  • Detection — Monitoring alerts, service-provider notifications, customer reports, and responsible disclosures may initiate an investigation.
  • Investigation — The response process should assess the event’s scope, cause, affected systems, and potential impact.
  • Customer notification — Affected customers should be notified as required by applicable law and contractual commitments.
  • Recovery and improvement — Corrective action should restore safe operation and reduce the likelihood of recurrence.
11

Backup and disaster recovery

Supporting service restoration and business continuity

  • Automated backups — Production data relies on backup and recovery capabilities provided by the applicable infrastructure services; backup configuration and restoration procedures should be reviewed periodically.
  • Reduced single points of failure — Infrastructure design should use provider capabilities that reduce unnecessary dependency on a single component.
  • Recovery procedures — Corenth Technologies should continue documenting procedures for restoring critical services after a major disruption.
  • Recovery testing — Backup restoration and recovery procedures should be tested periodically as the production recovery process matures.
12

Customer security practices

Steps customers can take to help protect their accounts

  • Use strong passwords — Use unique passwords that are not reused across other services.
  • Enable MFA — Customers can enable authenticator-app multi-factor authentication in account settings. Once enrolled, the account must complete the additional authenticator challenge before customer-dashboard access.
  • Review permissions — Regularly review which team members can access customer information, billing, integrations, and administrative tools.
  • Protect credentials — Treat API keys, access tokens, recovery codes, and credentials like passwords and never commit them to public code.

Future security and compliance roadmap

We do not claim protections or certifications that have not been implemented or earned.

Corenth Technologies intends to expand its security, compliance, privacy, testing, documentation, and assurance programs as the platform grows. These roadmap items are objectives, not current certifications or legal guarantees. Active penetration testing and remediation are not listed as future objectives because that work is currently underway.

01

Expanded vulnerability-management program

Expand recurring scanning, security testing, remediation tracking, verification, and security-review capabilities as the platform grows.

02

GDPR operational alignment

Privacy and data-handling procedures intended to support applicable GDPR requirements as the company expands.

03

CCPA operational alignment

California privacy-rights procedures planned as Corenth Technologies formalizes its privacy program.

04

SOC 2 Type II

A future objective as the company, operational controls, documentation, and customer requirements mature.

05

ISO 27001

A longer-term objective as the information-security management program develops.

Responsible vulnerability reporting

Help us investigate potential security weaknesses responsibly.

If you believe you discovered a vulnerability, provide enough information for the issue to be reproduced and investigated. Do not access information that does not belong to you, disrupt services, use destructive testing, or publish the issue before Corenth Technologies has had a reasonable opportunity to respond.

Security FAQ

Common questions about our current security approach and roadmap.

Security details may change as the production architecture, provider configuration, testing and remediation work, monitoring program, and compliance practices continue to mature.

Are all of the controls described on this page active?

No. Some controls are active in the current soft-launch platform, some are provided through infrastructure vendors, and others remain in progress or on the roadmap. Corenth Technologies is also undergoing active security assessment, penetration testing, remediation, and verification. This page does not represent a completed independent security audit or certification.

Is Corenth Technologies currently undergoing security testing?

Yes. A cybersecurity contractor completed a website penetration test and its findings were reviewed. Some findings remain open for remediation, and retesting has not yet occurred. The completed assessment is not a certification, final security clearance, or guarantee of complete security.

How will customer data be encrypted?

Production website and application traffic uses HTTPS/TLS. Stored information relies on encryption capabilities provided by approved database, storage, and infrastructure services. Backup protections depend on the applicable provider configuration.

Who owns customer data?

Customers retain their rights in the information and content they provide. Corenth Technologies acts as a service provider and custodian according to the applicable agreement and privacy policy.

Can customers delete their data?

Customers may request deletion of account information, subject to legal, tax, accounting, fraud-prevention, security, contractual, and retention requirements.

Where will data be stored?

Information is stored and processed through approved cloud and service providers. Current subprocessors and service providers should be documented and updated as the production architecture changes.

Will business data be used to train AI models?

Corenth Technologies does not intend to use customer business information to train third-party foundation models without consent. Any different treatment for a specific feature should be disclosed before it applies.

What will happen after a security incident?

Corenth Technologies will investigate, contain, remediate, and recover from reported or detected security events as appropriate. Affected customers will be notified when required by applicable law or contractual commitments.

How do I report a vulnerability?

Email cdean@corenthtech.com with a clear description, reproduction steps, affected pages or systems, and any supporting evidence. Please allow a reasonable opportunity to investigate before public disclosure.

Questions about our security approach?

Discuss a security questionnaire, vendor requirement, or specific concern with Corenth Technologies.

Contact security

This page describes Corenth Technologies’ current soft-launch security approach, active security-hardening work, and roadmap. It is not a certification, completed independent audit report, service-level agreement, warranty, legal guarantee, or substitute for the applicable customer agreement, privacy policy, data-processing terms, or legal advice.