Security & Trust

Last updated: May 2026

[DRAFT — Not yet legally reviewed.] This page summarizes Avatar Animator's current security posture for buyers, integrators, and security researchers. Fields marked [PENDING — operator input required] below are sentinels awaiting decisions tracked in the platform's "Pending Your Input" admin queue.

This page is the canonical "trust center" referenced by our /.well-known/security.txt Policy: field. It is intentionally maintained as plain text + HTML — no JavaScript required — so security tooling, procurement reviewers, and bots can read it unconditionally.

Responsible Disclosure

We welcome reports of security vulnerabilities in Avatar Animator and the public Avatar Animator services. We will respond and remediate in good faith.

How to report

• Email: darryl@inspirationdancecompany.ai (also serves as our published Contact: in /.well-known/security.txt)
• Web form: /security-report (in flight — until live, please email)
• Encrypted reports: PGP key not currently published. If you need an encrypted channel, email us first and we will arrange one.

What to include

A clear technical description, steps to reproduce, the impact you observed, and your preferred contact for follow-up. Please do NOT include real personal information, real student data, or production user credentials in your report — synthesize a minimal reproducer instead.

Response window

• Acknowledgment: within 2 business days of receipt.
• Triage decision: within 5 business days.
• Critical-severity remediation target: within 30 days for issues we

can fix directly; longer if a fix requires coordination with an upstream subprocessor.

Scope

In scope:

• *.fyper.cc (staging.fyper.cc, app.fyper.cc) — Avatar Animator application
• codecandance.com — Marketing front-end (Vercel)
• /api/* endpoints documented in our public surfaces (Privacy Policy, DPA, Sub-Processors)

Out of scope:

• Denial-of-service or volumetric attacks
• Social engineering of Avatar Animator staff, customers, students, or families
• Issues exclusively present in subprocessors (please report directly to AWS, OpenAI, Resend, etc., per their disclosure policies)
• Self-XSS or content-spoofing issues that require attacker-controlled local environment

Legal safe harbor

We will not pursue legal action against, or ask law enforcement to investigate, researchers who:

1. Make a good-faith effort to comply with this policy. 2. Avoid privacy violations, data destruction, and service degradation. 3. Avoid accessing or exfiltrating data beyond the minimum necessary to demonstrate the issue. 4. Give us reasonable time to remediate before public disclosure (we request 90 days).

If you are unsure whether a specific test method is in scope, ask first at darryl@inspirationdancecompany.ai.

Encryption

At-rest

• Application secrets — sensitive credentials stored in our PostgreSQL

database (notably SSO client secrets and historical OAuth refresh tokens) are encrypted with AES-256-GCM using the APP_ENCRYPTION_KEY environment value. The key is provisioned via AWS Secrets Manager and is never logged or returned to clients. See server/lib/encryption.ts for the implementation and threat model.

• Database — Amazon RDS PostgreSQL volumes are encrypted at rest by AWS

managed keys (KMS).

• Object storage — Asset files (avatars, audio, generated images) live

in Amazon S3 with bucket-default SSE-S3 encryption at rest.

In-transit

• All Avatar Animator endpoints terminate TLS 1.2 or higher at the AWS

Lightsail load balancer. We do not accept plaintext HTTP for any authenticated route; the marketing front-end on Vercel uses Vercel's TLS-managed certificates.

• Internal AWS service-to-service traffic (RDS, S3, Cognito, SES) traverses

AWS-private networking with TLS.

Key rotation

• APP_ENCRYPTION_KEY rotation policy: [PENDING — operator input required].

Current production key is the original generated value; no rotation has yet occurred. Once a rotation cadence is approved, we will document it here.

• LTI 1.3 RSA signing keys for /.well-known/jwks.json are managed via

database-backed key rotation (see lti_keys schema).

Authentication

• Identity provider: Amazon Cognito user pools for all

password-and-email authentication.

• Federated SSO: Available for districts via Clever, ClassLink, and

Google OAuth (configured per-org).

• LTI 1.3: Canvas and other LMS launches are supported via signed JWT

exchange; JWKS published at /.well-known/jwks.json.

• Multi-factor authentication (MFA): [PENDING — operator input required].

Cognito user pools support TOTP/SMS MFA; we have not yet enforced MFA for admin / district-admin accounts platform-wide. The user-facing toggle is in flight under a separate workstream.

• Session storage: Short-lived JWT access tokens delivered as

Secure-flagged HTTP-only cookies; refresh handled via Cognito.

Audit logging

Avatar Animator records an append-only audit log of FERPA-relevant and security-relevant actions in the audit_log database table. The action class identifiers are defined in server/lib/audit-shape.ts and currently include:

• SSO configuration changes (sso.configured, access_scope.updated)
• FERPA data deletions (ferpa.deleted_user, ferpa.bulk_deleted)
• Roster operations (roster.uploaded, roster.sync_started, roster.sync_completed, roster.sync_failed)
• Assignment lifecycle (assignment.created, assignment.updated, assignment.deleted)
• Grade overrides and LMS push events (grade.overridden, grade.lms_pushed)
• DPA acceptance (dpa.accepted)
• License threshold events (license.threshold_crossed)
• Billing webhook events from Stripe

District administrators can browse audit events for their own org through the District Dashboard's Compliance tab. Cross-org access is blocked by middleware; the integration tests under tests/security/ enforce this.

Hardware pairing — iLumaCap (LED Cap / Vest)

Avatar Animator supports an optional connected hardware accessory — the LED Cap and Vest products — through iLumaCap, the Operator's own internal hardware backend. iLumaCap is Operator infrastructure (per the Sub-Processors registry's note on Connected Hardware and Privacy Policy §15), not a third-party Sub-Processor; hardware-pairing data does not leave Operator-controlled systems.

This section documents the data flow, encryption posture, and retention window for the pairing pathway so security reviewers can evaluate it independently of the Privacy Policy's user-facing summary.

Data flow

• Transport. The browser does not speak Bluetooth Low Energy

(BLE) directly to the hardware. The Avatar Animator client posts Pixelblaze pattern source to the Operator's server (/api/ilumacap/push, /api/ilumacap/compile, /api/ilumacap/devices — see server/ilumacap-routes.ts), which in turn proxies to the iLumaCap cloud service over HTTPS. The iLumaCap cloud service is the party that opens the persistent socket to each physical Pixelblaze controller; the BLE / Wi-Fi link is iLumaCap-to-device, never browser-to-device.

• Authentication to iLumaCap. Server-to-iLumaCap calls carry an

x-app-user / x-app-key credential pair issued to the Operator. These credentials are provisioned via AWS Secrets Manager (ILUMACAP_APP_USER, ILUMACAP_APP_KEY) and are never exposed to the browser.

• Pairing model. A pairing is the assertion by a Student User or

Authorized User that a given Avatar Animator session should drive a specific physical device. The user enters a device number (e.g., "Cap #28" or "Vest #22"); the server resolves that to the iLumaCap-side device record by locator-string match (getDeviceByNumber in server/ilumacap-service.ts).

What data is captured

• From iLumaCap, into the Operator's request/response cycle: device

id (iLumaCap internal UUID), pbId (Pixelblaze controller identifier), locator (human-readable e.g. "Cap #28"), online status, version, location label, lastSeenAt timestamp, and current allocation (iLumaCap-side reservation including userId / userName / sectionId / expiresAt).

• From the user's session, sent to iLumaCap: Pixelblaze pattern

source code authored in the Avatar Animator editor and an optional human-readable pattern name. No Educational Records and no Personal Information about the Student User are forwarded to iLumaCap as part of a pattern push.

• Not captured at any tier: raw BLE MAC addresses are not exposed

to the Avatar Animator server or stored in our database. We see only the iLumaCap-side identifiers listed above.

Where the data is stored

• iLumaCap-side: device registry, online status, allocation, and

push history are stored within the iLumaCap backend (Operator infrastructure). That system's own retention controls govern its records.

• Avatar Animator server-side: **no PostgreSQL table persists

iLumaCap pairing state.** The relationship between a user session and a device is held only for the duration of the HTTP request that resolves it, and (for the lifetime of a browser tab) in the React client's in-memory connection cache. There is no device_pairings-style table; there are no pairing rows in audit_log today.

• Avatar Animator client-side: connection state lives in a

module-scoped JavaScript variable (persistentConnections in client/src/lib/ilumacap/useVestConnection.ts). It is not written to localStorage, sessionStorage, or IndexedDB and does not survive a tab close, hard refresh, or navigation that unmounts the React root.

Encryption posture

• In-transit (browser ↔ Operator server): TLS 1.2+, terminated at

the AWS Lightsail load balancer (same posture as every other Avatar Animator endpoint — see "Encryption / In-transit" above).

• In-transit (Operator server ↔ iLumaCap cloud): HTTPS, with the

x-app-user / x-app-key credential pair carried in request headers. The iLumaCap service publishes a TLS-terminated endpoint; the Operator does not accept plaintext from it.

• In-transit (iLumaCap cloud ↔ physical Pixelblaze controller):

Governed by iLumaCap's own link-layer security to the device. This hop is outside the Avatar Animator server boundary; the iLumaCap backend is the responsible system.

• At-rest (Operator server): Because the Avatar Animator

PostgreSQL database does not persist pairing records (see "Where the data is stored" above), there is no Operator-side at-rest store to encrypt for this data category. If a future feature persists pairing history into our database, those rows will inherit the same AWS-RDS KMS (AES-256) at-rest encryption that every other application row receives, and this section will be updated to name the new table.

• At-rest (iLumaCap backend): [PENDING — operator input required].

The iLumaCap backend is Operator-internal; the at-rest encryption posture for its device-registry and allocation tables is tracked for documentation under AA-336 and will be filled in here once confirmed against the iLumaCap infrastructure inventory. The Privacy Policy §15 statement that "Hardware-pairing data at rest is encrypted with the same AWS-KMS-backed AES-256 standard as other Operator infrastructure" is the current operating presumption and will be made specific here.

Retention

• Avatar Animator server-side: No persistent retention. State

exists only for the lifetime of an HTTP request.

• Avatar Animator client-side: Pairing state survives only the

active browser tab. Closing the tab, navigating away from the Pixelblaze editor in a way that unmounts the React root, or performing a hard refresh clears the in-memory cache. The useVestConnection hook's disconnect() action also clears it immediately.

• iLumaCap-side allocation: Each iLumaCap allocation carries an

expiresAt timestamp set by the iLumaCap backend; the Operator's proxy treats an expired allocation as released (isDeviceAvailable in server/ilumacap-service.ts).

• iLumaCap-side device records and push history: [PENDING — operator input required].

Retention windows on the iLumaCap backend are tracked under AA-336 and will be stated explicitly here once confirmed. For the Educational-Record-touching dimensions of this data, the Operator commits to honoring the same FERPA / SOPIPA deletion obligations documented in the Privacy Policy §11 and §15: a Customer's FERPA deletion request reaches the iLumaCap-side records via the Operator's internal deletion procedure.

Compliance posture

• Hardware-pairing data is treated as Customer Data when generated by

a Student User under a Customer contract, and as individual-account data when generated by a Free-tier Authorized User without a Customer contract. FERPA "school official" obligations apply in the former case.

• Pattern source code authored by a Student User is part of that

student's project content (Educational Record); it is governed by the same retention, export, and deletion rules as other project content (see Privacy Policy §9 and the DPA).

• No third-party Sub-Processor is involved in the hardware-pairing

data flow; the Sub-Processors registry describes iLumaCap as Operator-internal infrastructure under the "Connected Hardware" category for transparency rather than as a vendor relationship requiring 30-day change notice.

Compliance frameworks

We align our practices with the following frameworks; current status is listed honestly per framework. Where a third-party certification is named, we either hold it ourselves or rely on a subprocessor's certification (in which case the subprocessor is named).

• FERPA (Family Educational Rights and Privacy Act) — We treat

Avatar Animator as a "school official" under FERPA per our standard DPA template (see /dpa). FERPA-grade access controls, data deletion on request, and audit logging are documented in our Privacy Policy and DPA.

• COPPA (Children's Online Privacy Protection Act) — Enforced via the

age-gate and parental-consent flow shipped under AA-179. Schools may act as parents' agents for in-school accounts; the parent-consent path applies for out-of-school account creation by users under 13.

• State Student Privacy Pledge — [PENDING — operator input required].

Not yet a signatory.

• SOC 2 Type II — Not currently audited. Target audit window:

[DRAFT — pending operator approval of engagement date]. We rely on the SOC 2 Type II certifications of our subprocessors (AWS, OpenAI, Resend, Stripe) for the layers of the stack they operate. Our own SOC 2 engagement has not been initiated; see "Pending Your Input" item "Initiate SOC 2 Type II engagement".

• ISO 27001 — Not currently certified.
• VPAT 2.4 Rev (WCAG) — Not currently authored. We publish a public

axe-core scan report at /compliance/accessibility-report as the candid current-state artifact; a professional VPAT will require a paid accessibility audit (pending).

• Common Sense Privacy badge / iKeepSafe — Not currently certified.

Subprocessors

The complete, current list of subprocessors processing Avatar Animator data is maintained on a dedicated public page: /sub-processors. District administrators evaluating procurement should consult that page rather than rely on summaries here.

Subprocessor-change notification: districts under contract are notified by email when a subprocessor is added or removed; the public list is updated within 30 days of any change.

Breach response

In the event of a confirmed security incident affecting customer or student data, we follow this timeline:

1. Containment — Immediate action to stop unauthorized access (within hours of detection). 2. Initial customer notification — We commit to notifying affected district administrators within 72 hours of confirming an incident that affects their data, consistent with FERPA "school official" obligations and the DPA we sign with districts. 3. Detailed post-incident report — Within 30 days of the incident, we provide affected districts with: a description of what happened, data categories affected, mitigations applied, and follow-up steps. 4. Regulatory notification — When required by state student-privacy law or by district request, we coordinate with the district to support any further required disclosures. 5. Public summary — For incidents with broad customer impact, we publish an anonymized post-incident summary at this page.

Infrastructure

• Hosting: Amazon Web Services — Lightsail container service for the

application tier (US East 1); Amazon RDS PostgreSQL for the operational database; Amazon S3 for asset storage; Amazon SES for transactional email; Amazon Cognito for identity.

• Marketing front-end: Vercel (codecandance.com).
• CI/CD: GitHub Actions; deploys are tag-driven (see project

documentation for the tag pattern).

• Logging & monitoring: CloudWatch logs for application output;

audit-log table for security-relevant business events.

Contact

• Security disclosure: darryl@inspirationdancecompany.ai
• Privacy / FERPA / DPA: darryl@inspirationdancecompany.ai
• Accessibility: darryl@inspirationdancecompany.ai
• General support: [PENDING — canonical support email pending operator decision]

Last revision tracked in: shared/legal/security.md. This page is rendered server-side via the same SSR pipeline as our other public legal pages, so search-engine bots and procurement-review tools see the same content a human visitor sees.