Information Security Policy
Premmisus Inc.
| Document version | 1.0 |
| Effective date | 2026-05-10 |
| Next review | 2027-05-10 |
| Owner | Elliott Cuthbert, Founder & Director |
| Contact | elliott@premmisus.com |
1. Purpose & scope
This policy establishes the information-security controls that govern the Mafia application (the “Application”) operated by Premmisus Inc. (“Premmisus”). It applies to all data collected, processed, transmitted, or stored by the Application, including financial data retrieved from third-party providers (Plaid Inc., Stripe Inc.) and operational data entered by the authorized user.
2. Roles & responsibilities
Premmisus is a single-founder company. The founder, Elliott Cuthbert, is the sole party responsible for information security. The founder is the data controller, system administrator, software developer, incident responder, and policy approver. There are no employees, contractors, or third-party developers with system access.
3. Data classification
- Restricted: Plaid bank-access tokens, Stripe API keys, OAuth refresh tokens, the Banker Kill Switch bearer.
- Confidential: Bank account balances, transaction history, customer financial data.
- Internal: Operational notes, scheduled reflections, agent reports, audit log entries.
- Public: Privacy Policy, Terms of Service, this document.
4. Identity & access management
- Authentication: NextAuth v5 with Google OAuth and GitHub OAuth providers. No password authentication.
- Authorization:A hard-coded email allowlist gates sign-in. Only the founder’s pre-authorized email addresses can authenticate. There is no public sign-up flow.
- Bearer tokens: Voice/Siri shortcuts and the Banker Kill Switch endpoint use rotating secret-bearer tokens stored only in environment configuration. Bearer comparison is timing-safe.
- Session management: 7-day session window; sessions invalidate on sign-out.
- Least privilege: Single-user system; the founder is the only principal. No service accounts or shared credentials.
5. Encryption
The Application enforces a defense-in-depth encryption posture: all data is encrypted at rest at the storage layer, with an additional application-layer encryption envelope on the highest-sensitivity fields (third-party access tokens). All data in transit uses TLS 1.2 or higher.
- Data at rest — storage layer (covers all consumer data):All consumer financial data retrieved from third-party APIs (Plaid, Stripe) and persisted to the production database is encrypted at rest by the database provider, Neon, using AES-256block-cipher encryption on the underlying NVMe instance storage. This applies without exception to every row in every table — account metadata, balances, transaction history, account-holder names, audit-log entries, all Plaid-derived data — and is enforced by the storage subsystem independent of the Application’s own logic.
- Data at rest — application layer (Plaid access tokens):Plaid access tokens receive an additional encryption envelope in application code: AES-256-GCM with a unique, randomly-generated 12-byte initialization vector and 16-byte authentication tag per token, performed before any database write. The plaintext token is never persisted; only the ciphertext, IV, and auth tag are stored. The 256-bit envelope key is held only in encrypted environment configuration on Vercel and is never persisted in source code, logs, or backups.
- Environment configuration:All secrets — third-party API keys, OAuth client secrets, bearer tokens, the application-layer encryption key, the NextAuth signing secret — are stored as Vercel environment variables, encrypted at rest by Vercel and decrypted only into the production runtime at deploy time. Secrets are never committed to source control.
- Data in transit:All HTTP traffic between the Application and clients is encrypted with TLS 1.2 or higher, terminated at Vercel’s edge. The database connection from the Vercel runtime to Neon is TLS-only (
sslmode=require) via the Prisma Postgres adapter. All outbound calls to Plaid, Stripe, Twilio, Anthropic, Google, and other providers use TLS. - Key management: Cryptographic keys are rotated by adding a new value to environment configuration, redeploying, and decommissioning the prior key. The application-layer envelope key for Plaid tokens supports re-keying by re-encrypting tokens under the new key on the next sync window.
6. Network & infrastructure security
- Hosting: Vercel Inc. (SOC 2 Type II certified). HTTPS-only enforcement.
- Database: Neon (Postgres) — TLS-only, IP allowlisting available.
- Routing & auth gate: A Next.js proxy/middleware layer (
src/proxy.ts) gates every route except an explicit short list of public surfaces (auth callbacks, third-party webhooks with signature verification, this and related public legal pages). - Webhooks: Inbound webhooks from Plaid, Stripe, and Twilio verify cryptographic signatures or HMAC tokens before processing.
7. Application security, SDLC & vulnerability management
7.1 Secure development
- Source control: All code is version-controlled in private GitHub repositories under the Premmisus organization. Repositories are not public.
- Code review: All commits authored by the founder. Risky operations (schema migrations, auth changes, real-money paths) are gated by self-review against a documented standing-corrections checklist before deployment.
- Type safety: Strict TypeScript across the codebase (
npx tsc --noEmitrequired clean before deploy). - CI/CD: Vercel auto-deploys from the main branch. Failed builds do not propagate to production.
- Real-money guard: A bearer-protected
/api/banker/killswitchendpoint, when activated, causes every guarded code path to refuse to execute. Activation requires an explicit reason and fires a Telegram alarm; deactivation requires a confirmation phrase to prevent accidental clearing.
7.2 Vulnerability scanning
Premmisus operates an active vulnerability-detection program covering both production assets and the founder’s endpoint device:
- Dependency vulnerability scanning: GitHub Dependabot is enabled on every Premmisus repository. Dependabot continuously evaluates the dependency graph against the GitHub Advisory Database and opens pull requests with patched versions when a vulnerable package is identified.
- Source-code scanning:GitHub Secret Scanning is enabled on all private repositories — scans every push for inadvertently committed credentials and notifies the founder.
- Production-asset scanning:The Application runs on Vercel’s managed runtime; Vercel performs platform-level vulnerability management on the underlying infrastructure (Node.js runtime, container image, edge network) as part of its SOC 2 Type II program. The Application has no self-managed VMs, containers, or long-lived hosts to scan independently.
- Endpoint vulnerability scanning:The founder’s endpoint device runs current macOS with automatic security updates enabled and the Apple-native XProtect / Gatekeeper / MRT malware-scanning controls active. Full-disk encryption (FileVault) is enabled.
- Build-time validation: Strict TypeScript and Next.js production build checks run on every deploy; any regression that surfaces a security-relevant compile error blocks the release.
7.3 Patching SLA
Identified vulnerabilities are patched within the following service-level commitments, measured from the time the vulnerability is identified by Dependabot, by a vendor advisory, or by independent observation:
| Severity | Examples | Patching commitment |
|---|---|---|
| Critical | RCE, auth bypass, encryption-key disclosure, payment-path compromise | Same business day |
| High | Privilege escalation, sensitive-data exposure, exploitable XSS / SSRF | Within 7 calendar days |
| Medium | DoS in non-critical paths, information disclosure with limited impact | Within 30 calendar days |
| Low | Theoretical findings, defense-in-depth improvements | Best-effort, bundled with the next planned release |
Patches are applied by upgrading the affected dependency or configuration, validating against the Application’s TypeScript/Next.js build, and deploying via the standard CI/CD path. The Kill Switch (§7.1) is available as a containment control for any vulnerability that materially threatens real-money paths while a permanent patch is in flight.
7.4 End-of-life (EOL) software monitoring
- Runtime:Node.js is held at the current LTS release supported by Vercel; Premmisus tracks Vercel’s published runtime-support window and migrates off any runtime version before its EOL date.
- Framework: Next.js is tracked on a current major release; deprecated APIs are migrated within one release cycle of deprecation warnings appearing in production builds.
- Dependencies: npm packages are reviewed for EOL / unmaintained status as part of routine Dependabot triage. Packages whose upstream maintenance has ceased are replaced or removed within the next planned upgrade window.
- Operating system:The founder’s endpoint device is held on a current macOS major version with automatic security updates enabled.
- Provider runtimes: Plaid SDK, Stripe SDK, Twilio SDK, and other third-party SDKs are upgraded on each advisory cycle; any SDK with announced EOL is replaced before the EOL date.
8. Logging, monitoring & audit
- Audit log: An append-only
Executiontable records every consequential action — financial reconciliation, bank linking, receivable updates, kill-switch state changes, agent dispatches — with timestamp, role, action, input, output, and any error. - Error monitoring: Sentry (sentry.io) is wired across all production surfaces (Mafia, Sales Portal, Command Center). Uncaught exceptions, unhandled promise rejections, and framework-level errors are reported in real time with stack traces.
- Webhook delivery telemetry: Stripe and Plaid webhook events are logged via the Execution audit row + Sentry error tracking on handler failure.
- Log retention: Application logs are retained for 30 days at Vercel. Sentry events retained per Sentry plan (default 30 days). Audit log rows retained for 7 years to satisfy Canadian financial-record obligations.
9. Vendor & third-party management
Premmisus relies on the following third-party processors. Each is evaluated for security posture before adoption and is governed by its own contractual terms:
- Plaid Inc. — bank linkage (Auth, Balance, Transactions read-only).
- Stripe Inc. — invoice + payment processing (PCI DSS Level 1).
- Vercel Inc. — hosting (SOC 2 Type II).
- Neon — Postgres database (SOC 2 Type II).
- Sentry — error monitoring (SOC 2 Type II, ISO 27001).
- Twilio Inc. — SMS + voice (SOC 2 Type II).
- Anthropic + Google — AI inference (Claude, Gemini APIs).
10. Data retention & deletion
- Plaid-sourced data: Retained while the bank link is active. Within 30 days of link revocation, the associated
LinkedInstitution,Account, andTransactionrows are permanently deleted. - User-entered operational data: Retained until the user requests deletion via elliott@premmisus.com.
- Audit log: Retained for 7 years per Canadian financial-record obligations, then permanently deleted.
- Deletion procedure:On user deletion request, all rows scoped by the user’s email are removed in a single Prisma transaction; encrypted access tokens are zeroed before row delete.
11. Incident response
- Detection: Sentry surfaces uncaught exceptions and anomalies immediately. The Banker Kill Switch is the manual "stop everything" lever.
- Containment: On any suspected breach involving real-money paths, the Kill Switch is activated immediately (
POST /api/banker/killswitch); this halts all guarded code paths globally within seconds. - Eradication & recovery: Affected credentials are rotated by replacing the relevant Vercel environment variable and redeploying; affected rows are quarantined and reviewed.
- Notification: Affected users (if any beyond the founder ever exist) and relevant data-protection authorities are notified within 72 hours of confirmed incident, per GDPR Article 33 timeline.
- Post-incident review: A written post-mortem is recorded in the project repository, with corrective controls added to this policy on the next review cycle.
12. Backup & disaster recovery
- Database backups: Neon performs continuous point-in-time recovery snapshots; restore window is 7 days on the current Neon plan.
- Recovery time objective (RTO): 24 hours.
- Recovery point objective (RPO):<= 1 hour (Neon’s WAL-based recovery granularity).
13. Personnel security
Premmisus is a single-founder company. The founder is the only individual with system access. There are no employees, contractors, or third-party developers requiring background checks, access provisioning, or off-boarding.
14. Compliance & certifications
- Canadian PIPEDA: the Application is operated by a Canadian-incorporated entity and complies with the Personal Information Protection and Electronic Documents Act for the collection, use, and disclosure of personal information.
- GDPR & UK GDPR: users in the EEA / UK are granted the rights of access, correction, deletion, portability, and complaint as detailed in the public Privacy Policy.
- CCPA: California users are granted the equivalent rights under the California Consumer Privacy Act.
- Certifications NOT currently held: SOC 2 Type II, ISO 27001, PCI DSS. The Application does not directly handle payment-card data; all card processing is delegated to Stripe (PCI DSS Level 1). Certification of the Application itself is evaluated annually as a function of business need.
15. Policy review & approval
This policy is reviewed at least annually by the policy owner and updated as new controls are introduced or risk posture changes. Material changes are logged in the document version history below. The current version is approved and signed by:
Elliott Cuthbert, Founder & Director
Effective: 2026-05-10
Next review: 2027-05-10
16. Contact
Questions about this policy or about Premmisus’s security practices should be directed to elliott@premmisus.com.