Security at every layer

AYAN LABS FRONTIER SOFTWARE - FZCO (“AYAN”) is a Dubai-domiciled company building the AYAN platform for AI Brand Intelligence. We process brand assets, prompts, perception telemetry, and the audit outputs derived from them on behalf of our customers. This document describes the security controls AYAN is responsible for, and the controls our customers retain.

AYAN is responsible for:

• Physical and platform security of the hosting environment.
• Encryption of data in transit and at rest.
• Application security, secure SDLC, and vulnerability management.
• Logging, monitoring, and incident response on the platform.
• Vendor and sub-processor due diligence.

The customer is responsible for:

• User lifecycle on their side (joiners, movers, leavers, SSO configuration).
• Custody of API keys issued to their organisation.
• Classification of the data they upload and the lawful basis for processing it.
• Configuring per-organisation settings (model allowlists, retention, integrations).

Customer data travels through a small, well-defined pipeline. Inbound: HTTPS upload to the application API. Storage: a managed Postgres database in an EU region, with encrypted object storage for media and document artefacts. Processing: ephemeral workers handle LLM inference calls and write structured outputs back to the database. Audit: every read and mutation against customer data is recorded in a tamper-evident log.

Production data is stored in the EU. LLM inference may route to providers in the EU or US, depending on the model the customer has selected. Customers can configure a per-organisation regional allowlist that restricts inference to specific provider regions.

Cross-border transfers rely on the European Commission’s Standard Contractual Clauses, the UK addendum where applicable, and the UAE PDPL transfer mechanisms for the reverse leg. Sub-processors with US data flows operate under the relevant data-transfer frameworks.

Controls in summary:

• TLS 1.3 for all in-transit traffic, with HSTS preloaded on the public marketing surface.
• AES-256-GCM for data at rest, database, backups, object storage.
• Envelope encryption: tenant-scoped data encryption keys (DEKs) wrapped by key-encryption keys (KEKs) held in the hosting provider’s KMS.
• Key rotation: KEKs rotated annually; DEK rotation on demand and on tenant offboarding.
• No customer-managed keys today. Bring-your-own-key (BYOK) is on the 12-month roadmap.

Workforce access:

• Single sign-on with hardware-key two-factor authentication enforced for all engineering and admin roles.
• Production access is role-based and time-boxed: privileged operations require just-in-time elevation and are logged immutably.
• Principle of least privilege applied at every layer. Quarterly access review.

Customer-side access:

• SAML / OIDC SSO available on enterprise tier.
• Per-organisation API keys with scoped permissions and rotation support.
• Audit log of administrative actions exported on request.

AYAN is built around LLM inference. The way we handle the data sent to and from those models is the single most important control on this page.

• Customer brand data is never used to train AYAN models or any third-party model.
• All LLM providers we route inference to operate under their enterprise no-train terms.
• Prompt and response payloads are encrypted in transit and stored only within the customer’s tenant in our database.
• Where feasible, personally identifying fields are redacted or referenced by stable handle before being sent to a provider.
• Customers can configure a per-organisation model allowlist (which providers and regions are eligible).
• Provider-side retention is configured to the shortest available window. We can supply each provider’s data-processing addendum on request.

Every change to production goes through a documented secure development lifecycle:

• Pull-request review by at least one engineer who did not author the change.
• Automated CI: linting, type-checking, unit and integration tests on every PR.
• Static analysis (security-focused lint rules, semgrep) and dependency scanning on every PR.
• Secrets never live in source, they are held in the hosting provider’s secret manager and injected at runtime.
• Branch protection on the main branch. Force-pushes are blocked. Releases are tagged and signed.

Production runs on managed services from SOC 2 Type II-certified providers, in EU and UAE regions. Specific provider names are listed in the sub-processors table below or available on request.

• Edge network and web application firewall in front of every public endpoint.
• Application, data, and administrative planes are segmented; the database has no public endpoint.
• Hardened container images, immutable infrastructure, infrastructure-as-code for every production change.
• Secrets and configuration managed through the provider’s vault, no shared service accounts.

Application logs and audit trails are centralised in a tamper-evident store with twelve-month retention. Security-relevant events, failed admin logins, scoped-token misuse, anomalous egress, configuration changes on production, trigger alerts routed to on-call. Detection coverage is reviewed quarterly against the OWASP Top 10 and the MITRE ATT&CK techniques most relevant to SaaS platforms.

Our vulnerability management programme runs continuously:

• Dependency scanning on every push, with automated pull requests for known-vulnerable packages.
• SLA-driven patching: critical fixes within 72 hours, high within 7 days, medium within 30 days.
• Annual third-party penetration test once the platform reaches GA; an internal red-team rotation operates in the meantime.
• Bug-bounty and responsible-disclosure inbox at [email protected], see the contact section below.

AYAN maintains a documented incident-response runbook with a named on-call rotation and a severity matrix (Sev 1 through Sev 4). Targets:

• Sev 1: acknowledge within 30 minutes, customer-facing update within 2 hours.
• Sev 2: acknowledge within 2 business hours.
• Sev 3–4: acknowledge within 1 business day.

For incidents confirmed to affect customer data, AYAN notifies the affected customer within 72 hours of confirmation, with a timeline, scope, and remediation plan, in line with GDPR Article 33 and the UAE PDPL. A written post-mortem is shared with the affected customer once the incident is closed.

Customer data is protected by layered backups and a tested recovery plan:

• Database point-in-time recovery plus daily encrypted snapshots.
• Object storage is versioned, with cross-region replication for critical objects.
• Target Recovery Point Objective (RPO): 24 hours. Target Recovery Time Objective (RTO): 8 hours for the production environment.
• Backups are tested through restore drills at least annually. Disaster-recovery drills are run at least annually.
• Vendor concentration risk is reviewed at each architecture milestone.

Every sub-processor goes through a documented assessment that captures their security posture, certifications, location, and the data-processing agreement we hold with them. Material additions or changes to our sub-processors are announced at least thirty days before they go live, via the customer-admin email channel. The categories of sub-processor currently in use are listed in the sub-processors table on this page; a current, named list with regions and DPAs is available on request at [email protected].

Detailed privacy commitments are in the Privacy Policy at /privacy. AYAN provides a pre-signed Data Processing Agreement on request and can execute the customer’s DPA where the substantive terms match. Data-subject requests (access, rectification, erasure, portability, restriction, objection) are routed via [email protected] and are handled within the timelines required by GDPR and the UAE PDPL.

People controls:

• Background checks where lawful in the employee’s jurisdiction.
• Mandatory security training at onboarding and annual refresher.
• Signed confidentiality and acceptable-use agreements.
• Endpoint management with full-disk encryption, screen-lock enforcement, and EDR.
• SSO with mandatory two-factor authentication enforced on workforce identities.
• Offboarding revokes access within one business day.

Responsible disclosure:

• Reach [email protected] to report a vulnerability.
• We acknowledge reports within one business day.
• Safe harbor for good-faith security research within scope: we will not pursue legal action against researchers acting in good faith and within the disclosure policy.