Practical security controls, current trust disclosures, and no trust theater.
This page summarizes the security practices and current public trust disclosures we can defend today for Corral. It focuses on infrastructure hardening, application protections, and the operational vendors supporting corral-ai.app.
For current public data-handling disclosures, see our privacy policy.
We would rather publish a narrower page that stays accurate than make broad claims we cannot defend. This page was last reviewed on March 23, 2026.
March 23, 2026
Last reviewed date for this version of the security summary.
Traffic is encrypted in transit, and the site is configured to prefer secure browser sessions.
Database and disk storage is encrypted at rest through infrastructure providers.
Production hosts use a hardened network posture with limited exposed services and locked-down access.
Each customer receives dedicated product infrastructure. Shared tooling may still support lead and support workflows.
Scope
This page applies to corral-ai.app and the Corral-operated workflows described on this site. It is a practical summary of security controls and current public trust disclosures.
We don't rely on obscurity. Corral's security posture is designed to hold up when fully visible — the same standard we apply to the outputs we ship.
It is not a certification page. If a control is still planned, it appears in the roadmap section instead of being presented as complete.
Section 1
Infrastructure Security
The production environment is hardened to keep the externally visible surface narrow and the transport layer secure.
Encrypted transport
Traffic to Corral is served over HTTPS with TLS, and HSTS is enabled so browsers continue to prefer secure connections after the first visit.
Encryption at rest
Database and disk storage are encrypted at rest by the hosting and database providers. Key management is handled at the infrastructure layer.
Default-deny perimeter
Production hosts use a default-deny firewall posture and expose only the network access required to operate the service.
Hardened administrative access
Interactive root SSH access is disabled, and repeated SSH abuse is blocked automatically to reduce the chance of successful credential guessing.
Minimal exposed surface
We keep the public surface area narrow by binding app services to loopback and stripping unnecessary service metadata at the proxy.
Section 2
Application Security
Corral combines browser-facing protections with targeted application-layer controls for the public workflows this site exposes today, including per-IP limits on the lead and contact endpoints.
Rate-limited form endpoints
The public lead and contact form endpoints enforce per-IP request limits in the application layer to make repeated submission abuse less productive.
Security headers
Responses include a content security policy, frame-denial headers, MIME sniffing protection, strict referrer controls, and a restrictive permissions policy.
Submission validation
Public forms use honeypot fields, required-field checks, and basic email validation before data is accepted.
Escaped notification rendering
Form content is HTML-escaped before it is rendered in notification emails, so submitted content is handled as data rather than rendered markup.
Low-fingerprint responses
We disable framework-identifying headers such as X-Powered-By, and the public lead and contact endpoints keep server error responses intentionally minimal.
Section 3
Data Security
We keep the public claims here focused on handling discipline, analytics routing, and the geographic posture we can verify today.
Structured operational records
Lead and contact workflows use structured database operations rather than ad hoc SQL in request handlers.
First-party analytics path
Browser-side analytics use a first-party /ingest path, while server-side events use PostHog's configured backend host.
Current geographic posture
Corral does not currently target EU users, and the current analytics configuration points at PostHog's US service.
Section 4
Access Control
Operator and application access follows least-privilege boundaries with no shared credentials.
Least-privilege operator access
Production server access is limited to a single named operator account. The application runs under a dedicated unprivileged user with no interactive login.
No shared credentials
Each operator authenticates with individual SSH keys. There are no shared passwords or group accounts for production access.
Restricted data access
Operator access to customer data is limited and restricted to operational or security needs.
Key-only authentication
Password-based SSH authentication is disabled. Access requires a pre-authorized key pair, and repeated failed attempts are blocked automatically.
Section 5
Customer Data Isolation
Each customer receives dedicated product infrastructure. We describe the current boundaries here.
Isolation is enforced at the application and data layer to prevent cross-customer access. Customer product data is not co-mingled with other customers' product data.
That isolation applies to the product environment itself. Corral may still use shared operational tooling for inbound leads and support workflows, which is distinct from the product-side separation principle described here.
Section 6
Incident Response
How we detect, respond to, and communicate about security events.
Detection
We monitor service health, error rates, and access patterns. Unexpected behavior triggers investigation.
Response
Confirmed incidents are triaged by severity. Affected systems are isolated and remediated before restoring service.
Notification
If a security incident affects customer data, we notify affected customers within 72 hours of confirmation.
Section 7
Document Handling
We keep this section focused on the current storage and retention posture for Hallucination Guard documents.
Customer documents are stored in secured application storage and database systems with encryption at rest. Access is restricted to the application layer and controlled through least-privilege boundaries.
Data is scoped to the customer environment and is not shared across accounts. Your data is retained until you delete it.
For broader public data-handling disclosures, see our privacy policy.
Section 8
Third-Party Processors
A small set of vendors helps us operate Corral. These processors support hosting, analytics, product data, and lead/contact workflows.
Neon
Product data database
US-East
Used as the database for product data, including Hallucination Guard documents and related records.
Convex
Lead/contact workflow persistence
US
Used for lead and contact workflow records through structured database operations.
Resend
Email delivery
US
Used to deliver operational email for lead and contact workflows initiated through Corral.
PostHog (United States)
Website analytics
US
Used to process analytics events so we can understand traffic, page usage, and the performance of site calls to action.
DigitalOcean
Infrastructure hosting
NYC
Used to host corral-ai.app and the supporting systems that keep the site available.
Section 9
Adversarial Testing
Internal misuse-oriented testing informs controls for the public-facing systems on this site. A more receipts-heavy public proof section remains pending.
We use internal exercises around injection-style inputs, jailbreak attempts, malformed submissions, and adversarial probing to inform how exposed workflows should fail and recover.
We are not presenting this section as independent proof. The goal is to improve failure modes, public responses, and abuse resistance while a more detailed public evidence section remains pending.
Section 10
What's on Our Roadmap
This is the line between the controls we run now and the assurances we plan to add as Corral takes on larger customer commitments.
SOC 2 Type II
Planned as the customer base and operational scope justify a formal assurance program. We do not claim SOC 2 certification today.
Third-party penetration testing
Planned as part of the next stage of external validation. Internal misuse-oriented testing informs controls today, but independent penetration testing is still on the roadmap.
Section 11
Contact
Security questions, customer diligence requests, and vulnerability reports should come directly to us.
Security contact
privacy@corral-ai.appUse this inbox for security questions, data-handling diligence, or to report a problem you think we should investigate. For privacy-specific handling details, the privacy policy remains the canonical reference.