Information Security Policy

01 Purpose & scope

This policy describes the security controls Reis Media LLC ("Reis Media", "we") applies to Mythox — a web and desktop application that helps creators and entrepreneurs see their finances, time, energy, goals and work in one place. It covers the application, its database, the connections it makes to third-party services (including a user's bank, via Plaid), and the systems and accounts used to operate it.

Mythox is currently operated by a single founder. This policy is written honestly for that reality: it states the controls that are in place today and clearly separates them from the controls we are committed to adding as the user base grows (see Section 11).

02 Governance & responsibility

Philipe Reis (Founder) is the accountable owner for information security and the single point of contact for any security or privacy matter, reachable at admin@philipereis.com.

• This policy is reviewed and, if needed, updated at least once a year and whenever there is a material change to the product, the data we handle, or the systems we use.
• Security is treated as a release requirement, not an afterthought: every release goes through a security review gate before it ships (Section 7).
• If contractors or employees are added in future, they will be granted the least access needed for their role and will be required to follow this policy.

03 Access control

Access to production systems and user data is restricted on a least-privilege basis — people and components get only the access they need, and nothing more.

Per-user data isolation (enforced by the database)

User data is stored in a PostgreSQL database (Supabase) with Row-Level Security (RLS) turned on. RLS means the database itself only lets an account read or write its own rows — one user literally cannot see or change another user's data, even if the application code had a bug. This is enforced at the data layer, not just in the app.

Application & API keys

• The app uses restricted, least-privilege API keys. The public (browser) key can only act through the per-user RLS rules above. The powerful service-role key is never placed in client code or shipped to the browser.
• Server-side secrets (including the Plaid secret and any bank access tokens) are held only on the server and are never exposed to the browser.

Administrative access

• Administrative consoles (the database/hosting provider, the payment provider, the code repository) are accessible only to the founder.
• Logout clears in-browser data and cached state so a shared device never exposes the previous session.

04 Encryption

• In transit: all connections to Mythox and its database use HTTPS with TLS 1.2 or higher. Plain, unencrypted connections are not used.
• At rest: user data stored in the database and file storage is encrypted at rest using AES-256, provided by our managed database platform (Supabase).
• Bank data from Plaid (account and transaction information, and the access token that represents a user's connection) will be handled server-side and stored encrypted at rest, alongside the same per-user isolation as the rest of the data. The bank-connect feature is in development and is being built to this standard on the already-encrypted platform above.

05 Secrets handling

• API keys, tokens and other secrets live in environment variables and managed secret stores — never hard-coded in source files and never committed to the code repository.
• Secrets are never printed, logged, or echoed into application output or build logs.
• Keys are scoped to the minimum permissions required for their job (restricted keys).
• If a secret is suspected to be exposed, it is rotated (replaced) promptly and the exposure is investigated.

06 Vulnerability management

• Pre-release security review: every meaningful code change is reviewed for bugs, security issues, and broken behavior by an automated AI code-review gate before it is deployed. Findings are fixed and re-verified before release.
• Managed-platform patching: the underlying database, hosting and serverless platform (Supabase) is patched and maintained by the provider, so infrastructure-level fixes are applied without us managing servers directly.
• Dependencies are kept reasonably current and reduced to what is necessary.

07 Secure development

• Code is kept in version control (git) with a clear change history.
• Builds are additive — existing protections are not removed to ship a feature.
• Changes are tested locally before any deploy, and pass the security-review gate described above.
• The data model was designed multi-user and access-controlled from the start, so security is structural rather than bolted on.

08 Agent & API access (locked scopes)

Mythox lets a user connect their own AI assistants (e.g. via a command-line tool or an MCP connector) to act on their data. This access runs through a frozen, least-privilege scope policy that is enforced in code and cannot be weakened at runtime:

• Read-only on financial data and credentials, and credential-like values are redacted before they are ever returned.
• Write only to a small allow-list (a user's next-actions, journal entries, and systems). It can never delete data, never change transactions, never run raw database commands, and never expose bank/connection tokens.
• The agent signs in as the user, so the same per-user isolation that protects the app protects the agent path too — it never uses an administrator key.

09 Incident response

If a security incident or data breach is suspected, we follow a defined process:

1. Detect & contain — stop the issue spreading (e.g. rotate keys, disable an affected path).
2. Assess — determine what data and which users were affected.
3. Notify — inform affected users and relevant parties (including Plaid where bank-related data is involved, and regulators where the law requires) without undue delay.
4. Remediate & document — fix the root cause, record what happened, and improve controls to prevent recurrence.

Report a suspected issue to admin@philipereis.com.

10 Third-party providers (sub-processors)

We rely on a small set of established providers, chosen for their security posture, and share with them only what is needed to run the service:

• Supabase — database, authentication & hosting
• Plaid — secure bank connections
• Stripe — subscription payments
• AI model providers — only when a user uses the AI features

The current list and what each one handles is kept up to date in our Privacy Policy.

11 Current status & commitments (no over-attestation)

So this policy is trustworthy, here is the honest state of each control as of the effective date:

In place today

• Per-user Row-Level Security (data isolation enforced by the database).
• TLS 1.2+ in transit; AES-256 at rest.
• Restricted, least-privilege API keys; secrets in env / secret store, never in code.
• Frozen least-privilege agent scope policy with credential redaction.
• Automated security-review gate before every release.

Committed, not yet fully in place

• Multi-factor authentication (MFA) for end users and on all administrative consoles — to be enabled/enforced (the auth platform supports it).
• Continuous vulnerability scanning of endpoints and production assets, plus automated dependency scanning and periodic external testing.
• Formal logging/audit-trail review and a written, signed-off incident-response runbook as the team grows.

We would rather under-promise and deliver than over-state our controls. This section will be updated as each committed item is completed.