Halcyra processes tenant contact details and appointment records on your firm's behalf. Here's how that's kept safe, minimal, and accountable.
The AI's role is limited to negotiating an appointment time in plain English. It doesn't make decisions about a tenancy, a survey outcome, or a person's data — and every opening text discloses it's automated.
Surveyors only ever see the jobs assigned to them. Admins see their own firm's data — never another firm's. Authentication is via JWT with a defined admin/surveyor separation.
All traffic to and from Halcyra — dashboard, API, and SMS webhooks — runs over HTTPS/TLS.
Halcyra stores what's needed to arrange and confirm a visit — contact details, address, appointment status — not more.
An admin can permanently delete a tenant's record from the job's detail panel at any time, fulfilling a right-to-erasure request without waiting on us.
Tenants see your firm's name, not Halcyra's. Your firm remains the data controller; Halcyra acts as processor under the terms of the DPA.
Halcyra has undergone a structured security review covering application code, authentication and authorisation controls, multi-tenant data isolation, security headers, logging, integrations, secrets handling and repository history. Findings were assessed individually, with applicable issues remediated and subsequently verified. Items determined not to represent meaningful vulnerabilities in Halcyra's current architecture were documented and closed.
Hosted in Germany using managed cloud infrastructure. The production environment uses a managed PostgreSQL database with point-in-time recovery and a separately configured production web service. Detailed infrastructure configuration and supplier information are held privately for authorised procurement and due diligence.
All production traffic runs over HTTPS. Session cookies are marked Secure in production, are httpOnly (never readable by page scripts), and use a SameSite=Lax policy. HTTP security headers are implemented using Helmet, including a Content Security Policy — implemented as a genuine browser-level control, configured for how this specific application actually loads its scripts and styles, rather than treated as an airtight guarantee — along with clickjacking protection and protection against MIME-type sniffing.
Passwords are hashed with bcrypt before storage — never stored in plain text. Sessions use JWT-based authentication. Login and password-reset requests are rate-limited to slow down repeated-guessing attempts. Password reset tokens are cryptographically random, stored only as a hash, and expire after a short window. Every access control is enforced at the level of your own firm's boundary.
Halcyra is built as a multi-tenant application from the ground up. Authorisation checks are in place specifically to prevent one firm's users from accessing or modifying another firm's data. Which firm a request belongs to is always derived from the authenticated session itself — never taken directly from a value the browser sends — so a user cannot simply supply a different firm's identifier to reach its data.
Inbound messaging requests and delivery-status updates are authenticated before being processed. Every database query uses parameterised SQL, reducing the risk of injection-style attacks. Credentials for external services are supplied through environment configuration, not hardcoded into the application's source code. Content submitted by a tenant or website visitor is appropriately escaped before it is used elsewhere, and values that reach an email subject line are sanitised against line-break-based injection.
Authentication failures, and repeated attempts that trigger rate limiting, are logged. Sensitive administrative actions — creating an account, resetting another user's password, deleting an account — are logged with enough context to identify who acted and when. Values written to these logs are sanitised against log-injection attempts. Halcyra uses application-level security-event logging appropriate to the current service, rather than a dedicated SIEM or 24/7 security operations service.
The 30-day retention period described in Halcyra's published Data Retention policy is enforced by an automated, scheduled process — not a manual step someone has to remember. This describes the technical mechanism in place; it isn't a claim of formal GDPR certification.
Production credentials are not hardcoded into the application's source code. Current repository files were directly scanned for credential-shaped patterns, with none found beyond clearly-marked placeholder values. The complete accessible repository history — 124 commits, full non-shallow history, on the main branch — was separately reviewed, and no genuine historical secret exposure was identified. This reflects what was actually checked; it isn't a claim that secret exposure is impossible.
| Security area | Status |
|---|---|
| Application security controls | Reviewed and verified |
| Authentication & access control | Implemented and verified |
| Multi-tenant isolation | Reviewed and verified |
| Security headers | Implemented and verified |
| Security-event logging | Implemented and verified |
| Secrets management | Reviewed and verified |
| Repository history | Reviewed — no historical secrets identified |
| Data retention | Implemented and verified |
The full legal and operational detail — controller/processor roles, subprocessors, retention periods, and what happens if something goes wrong — lives in the Trust Centre.