Security Overview – iGlowly Assistant

Last updated: 30 March 2026

1. Security Approach

The iGlowly Assistant is designed according to privacy-by-design, data minimization, and least-privilege principles.
The system architecture is specifically designed to avoid storing personal data and Protected Health Information (PHI), and to reduce security risk by minimizing stored data.

Security measures include encryption, access control, data isolation, secure infrastructure providers, and abuse prevention mechanisms.

2. Infrastructure Security

The iGlowly Assistant is built using established cloud providers with industry-standard security practices:

• Supabase (AWS infrastructure – European Union)
• Microsoft Azure (European Union)
• OpenAI API
• Vercel (CDN delivery)

These providers maintain their own security certifications and infrastructure protections, including physical security, network security, and infrastructure monitoring.

iGlowly does not operate its own physical servers.

3. Encryption

Data in Transit

• All data transmitted between the user, the widget, and backend services is encrypted using HTTPS/TLS.

Data at Rest

• Anonymous analytics data stored in the database is encrypted at rest by the hosting provider.

4. Access Control and Authentication

Access to systems and data is restricted according to the principle of least privilege.

• Role-based access control is implemented.
• Clinics can access only their own analytics data.
• Administrative access is restricted to authorized iGlowly personnel only.
• Access to production systems is limited and protected by authentication and access controls.

5. Data Isolation

The system is designed to ensure logical isolation between clinics.

• Each clinic’s data is associated with a unique clinic identifier.
• Clinics cannot access data belonging to other clinics.
• Analytics and configuration data are scoped per clinic.

6. No Storage of Chat Messages

To reduce privacy and security risk, the iGlowly Assistant is designed so that chat messages are not stored.

• Messages are processed ephemerally in memory.
• Messages are not stored in databases.
• Messages are not written to logs.
• Messages are not included in backups.
• Messages are not accessible to clinics.
• Messages are not accessible to iGlowly staff.

This significantly reduces the risk associated with data breaches because conversation content is not stored.

7. Personal Data Protection and Sanitisation

If users enter personal data in chat messages, the system applies automated detection and redaction before AI processing.

Sanitisation includes:

• Detection of email addresses, phone numbers, and structured identifiers
• Detection of names and locations using AI-based entity recognition
• Replacement of detected personal data with anonymised placeholders

This process is designed to prevent personal data from being transmitted to AI providers.

8. Logging Policy

The system is designed to avoid logging sensitive content.

• Chat messages are not logged.
• Personal data is not logged.
• Application logs contain only technical and operational information.
• Security logs are used for abuse prevention and system protection only.

9. Backup Policy

Backups are performed for system and database integrity.

• Backups include anonymous analytics data and system configuration only.
• Backups do not include chat messages or conversation content.

10. Session Security

The Assistant uses temporary session tokens to maintain conversation state.

• Session tokens are stored in sessionStorage (browser session only).
• Session tokens are automatically deleted when the browser tab is closed.
• Sessions expire automatically after 15 minutes of inactivity.
• No persistent identifiers are stored in the browser.

11. Abuse Prevention and Rate Limiting

To protect the system from abuse and automated attacks:

• Rate limiting is implemented at session and system level.
• Automated abuse detection mechanisms are in place.
• Protections exist against spam, automated scraping, and injection attempts.
• The system is designed to prevent attempts to extract hidden system prompts or internal system data.

12. Subprocessors and Data Locations

iGlowly uses a limited number of subprocessors to operate the Assistant. These include infrastructure hosting, AI processing, and script delivery providers.

Data hosting and processing locations include:

• European Union (Germany) – database and analytics
• European Union (West Europe) – personal data sanitisation
• United States – AI processing (sanitised text only)
• Global CDN – frontend script delivery

See the Subprocessors page for the full and up-to-date list of subprocessors.

13. Incident Response

If a security incident is detected, iGlowly will:

• Investigate the incident and take appropriate containment measures;
• Assess the scope and impact of the incident;
• Notify affected customers where required by applicable law;
• Take corrective measures to prevent recurrence.

14. Summary

The security model of the iGlowly Assistant is based on the following principles:

• Minimize stored data
• Do not store chat messages
• Do not store personal data
• Encrypt data in transit
• Restrict access to authorized personnel only
• Isolate clinic data
• Use trusted infrastructure providers
• Apply rate limiting and abuse protection
• Sanitize personal data before AI processing

This approach reduces the risk associated with handling sensitive data and helps protect both clinics and users.

‍