Security

Starlight AI Inc. · Version 1.4 Owner: Avash Adhikary, Founder, Starlight AI Inc. Contact: avash@starlightaiinc.com Review: quarterly, and after any incident or material change to the system.

This is the same document provided to our partners, published here in full rather than summarised.

Why this document is short

Starlight AI Inc. is one person. A policy modelled on a hundred-person company would be a policy that is never followed, and a policy that is not followed is worse than none — it is a written record of the gap between what we claim and what we do.

So this describes what actually happens. Where a control is absent, it says so and says what compensates. Every statement here is meant to be verifiable against the running system by someone willing to look.

1. Scope

Everything that stores, transmits, or processes user financial data:

• the ATLAS web application and its API (Vercel)
• the ATLAS mobile application
• the production database (Neon Postgres)
• the encryption keyring
• the accounts that control the above: Vercel, Neon, GitHub, Plaid, Anthropic, Expo, AWS, and the domain registrar
• the founder's workstation, the only device that can reach production
• the founder's phone, which runs the mobile client against production and holds a device credential for it — inventoried in Access Control Policy §5

2. Roles and responsibilities

One person holds every role: development, deployment, security, and incident response. There is no separation of duties and cannot be at this size. This is recorded as a known limitation rather than described as a control.

Security ownership is nonetheless explicit rather than assumed: the founder named in the header is the owner of the security program, holds the authority to act without escalation, and does not delegate it.

Nobody else — no employee, contractor, or third party — has access to production systems or user data.

3. Data classification

Three levels, because more would not be used.

The keyring is the one asset whose loss is as serious as its disclosure: losing it makes every stored bank token permanently unreadable. It is backed up outside Vercel.

4. Controls

Access. Governed in full by the separate Access Control Policy, which carries the account inventory, the grant, change and revoke procedure, and the quarterly access review with its recorded log. In summary: multi-factor authentication is required on every account listed in §1. Production secrets exist only in Vercel's encrypted environment store and in an offline backup of the keyring. There is no administrative interface to the application and no impersonation capability, so there is no privileged in-app path to user data for anyone, including the founder.

Encryption. Plaid access tokens are sealed with AES-256-GCM at the application layer before storage, bound by AEAD additional data to the record they belong to, and tagged with the key that sealed them so keys rotate without a table rewrite. The keyring may be wrapped by AWS KMS, in which case the application holds no key material that decrypts anything on its own. All other user data is protected by provider volume encryption at rest and by user-scoped access control. All traffic is HTTPS with HSTS.

Authentication. Two factors are required before any financial data is reachable: a WebAuthn passkey or device-bound Secure Enclave credential, plus a six-digit PIN stored as an scrypt hash with a per-user salt and a five-attempt lockout. ATLAS never receives a banking credential; those are entered on the bank's own page inside Plaid Link.

Change management. All changes go through git. TypeScript runs in strict mode. A test suite of 32 files covers the security-critical paths — encryption, device authentication, account deletion, disconnection, and the assistant's refusal behaviour. The production build fails outright if a published legal document still contains an unfilled placeholder. No change is made by editing the production database or console directly.

Supply chain. Dependencies are reviewed on update and kept to what is needed. Since 23 August 2026 this runs on a schedule rather than on memory: Dependabot opens update pull requests weekly across both projects, and npm audit --audit-level=high runs in continuous integration as a blocking check on every change to the web application. The mobile audit reports without blocking, because every advisory there is currently in the Expo and Metro build toolchain rather than in anything that ships to a phone — gating on those would produce a red pipeline we would learn to ignore.

Static analysis. Semgrep runs on every push against the OWASP Top Ten, TypeScript and secrets rule sets. Errors fail the run.

Vulnerability remediation. Anything found — by a scanner, by static analysis, or by a report to security@ — is fixed within the timeframes in §5 of the Security Risk Management Policy: seven days for critical, thirty for high, ninety for medium.

End of life. Support horizons for the runtime and the frameworks are checked at every quarterly access review by npm run access-review, which flags any component within 180 days of its end of life. The Expo SDK 54 pin is the one known case; it is deliberate, and it is recorded with the condition that lifts it.

Devices. The single workstation uses full-disk encryption and a screen lock. Production credentials are not stored on it outside the ignored environment file, which is excluded by the repository ignore rules at two levels.

5. Monitoring and logging

What we record today:

• every inbound Plaid webhook — type, code, item, payload, receipt and processing time, and any error
• background job execution and failures
• rate-limit counters across the authentication surface
• platform request and function logs (Vercel) and database logs (Neon), at provider default retention

Since 23 August 2026, an application audit log and alerting. Every authentication outcome and every event that changes what an account is — sign-in and its failures, PIN accepted, rejected or locked, a passkey added, a pairing code that matched nothing, a bank disconnected, an account deleted — is recorded with its outcome, the claimed source address, and nothing else. No payloads: a row says a PIN was rejected, never what was typed, because an audit log that accumulates the data it protects becomes the most valuable table in the database. Recording never blocks a request; a write that fails is reported and the request continues.

The log is read on the same fifteen-minute schedule as the job queue. Four rules cover authentication and possession — repeated PIN rejection, lockout, a new passkey, repeated failed pairing — and alert the account holder directly, because the person who can say "that was not me" is the account holder rather than an operations desk we do not have. One address failing against several accounts is invisible from any single account's history, so it is computed across the whole window and written to the platform log. Alerts are deduplicated to one per rule per account per hour.

What this is and is not. Detection is near real time — bounded by the fifteen-minute cadence, not streaming. Retention on the audit log is ninety days. There is still no immutable or write-once log store, and no monitoring of data reads as distinct from authentication. Those remain on the treatment roadmap in the Security Risk Management Policy rather than being described as solved.

How the alert reaches someone. Two ways, and the second exists because the first was for a while the only one. A push notification; and an inbox on the app's home screen, added 25 August 2026, which does not depend on notifications being permitted, on a registration token still being valid, or on the push having been delivered at all.

The inbox came out of noticing that the push was the sole delivery path. The rules fired, the row was written, the API returned it — and no client rendered it, so an alert reached nobody at all. It is worth recording how that happened, because nothing was broken: every part worked, and the last one was missing. Detection that stops short of a person is a log entry.

Unread security alerts appear above everything else on the home screen, ahead of ordinary reminders whatever their age, and an alert the push could not deliver stays in the inbox rather than being lost at the point delivery already failed.

Both paths are now in the mobile application. The browser client was retired on 2 September 2026 and atlas.starlightaiinc.com is an informational site: it holds no session, renders no account data, and is not a place an alert could be shown. This paragraph previously said the inbox did not require the app, which was true when it was written and is not now — recorded rather than quietly edited, because a security document that revises its own history is worth less than one that shows its working.

6. Vendors and subprocessors

Governed by the Third Party Risk Management Policy: the inventory and what each party receives, the three tiers, selection, the concentration risk in depending on parties that are not independent of one another, quarterly review, and termination.

Each subprocessor is listed by name in the privacy policy. Before any new one is added it must be necessary, must be told the minimum required, and must be disclosed publicly before it receives data.

Current: Plaid (bank connectivity), Anthropic (assistant — receives computed figures only, never a name, email, phone, account number, or credential), Vercel (hosting), Neon (database), Expo (push delivery — carries only a notification's own title and text).

7. Users' rights over their data

Deleting an account calls Plaid /item/remove for every linked institution before local rows are removed, so consent is revoked rather than merely forgotten. Every personal table cascades from the user row. A single bank can be disconnected on its own without affecting the rest of the account.

8. Risk management

How security risks are identified, rated, treated and accepted is governed by a separate document: the Security Risk Management Policy. That document carries the risk register, the rating method, the record of accepted risks, and the treatment roadmap.

The two policies are reviewed on the same schedule and versioned together. This one states what we do; that one states what could go wrong with it and what we are doing about each thing.

9. Incident response

Governed by the Incident Response Plan: what counts as an incident, who responds, a first-hour sequence that revokes before it investigates, a 72-hour user notification commitment, and explicit notification of Plaid where their data or tokens are involved.

10. What this policy does not claim

• No SOC 2 or ISO 27001 certification.
• No third-party penetration test has been performed.
• No separation of duties, and no peer review of code, because there is one person.
• No formal security training programme, for the same reason.
• No network or host intrusion detection beyond hosting-provider defaults. Application-level detection does exist — §5 describes the audit log and its alerting rules — but it watches authentication and account change, not traffic, and it is near real time rather than streaming. There is still no immutable log store and no monitoring of data reads.

These are consequences of company size, not oversights, and each appears on the treatment roadmap in the Security Risk Management Policy. They are written here so that nobody has to discover them later.

11. Document control

A security policy for a company of one, written once and filed, would be worthless within a quarter. This one is maintained the same way the code is.

It is version-controlled. The policy lives in the same repository as the system it describes, so every change to it carries an author, a timestamp, and a diff. The commit history is the audit trail for the policy itself, and it is the evidence behind any claim that this document is maintained rather than merely written.

It changes on a trigger, not only on a calendar. A review is required:

• quarterly, on the schedule in the header
• after any incident, whether or not the incident revealed a policy gap
• whenever a new subprocessor is added, a new category of data is collected, or a new endpoint exposes financial data
• whenever a control listed in §10 as absent becomes present — the point of that section is to be shortened over time

Each review asks four questions, and the answers are recorded below even when nothing changed, because "reviewed, no change" is itself a finding worth being able to prove:

1. Has anything in §1 changed — new systems, new accounts, new devices?
2. Have the risks in the register changed in order or in kind?
3. Is every control in §4 still actually in force, verified rather than assumed?
4. Which item in §10 is closest to being closed, and what would close it?

Revision history