Information Security Policy

1. Scope and purpose

This Information Security Policy applies to all systems, data, and personnel of Custom AI Apps LLC ("the Company"), operator of Concierge Pilot, Texicurean OS, Arpejo, Jigger, and Kitchen Cost Tracker (collectively, the "Services"). It covers data we collect from end users (restaurant owners, fans, artists, and venue staff), data we receive from third-party APIs (Plaid, Stripe, Google, Spotify, Ticketmaster), and data created by users inside the Services.

The purpose of this policy is to (a) protect the confidentiality, integrity, and availability of customer data, (b) comply with applicable privacy laws (including the CCPA / CPRA), (c) meet contractual obligations with subprocessors such as Plaid and Stripe, and (d) maintain a posture proportionate to the size and risk profile of the business.

2. Roles and responsibilities

The Company is a small business with a single technical lead.

• Information Security Lead: Todd Lichtenwalter, CEO. Owns all information-security functions: access controls, secrets management, encryption, vulnerability management, incident response, subprocessor review, and policy maintenance. Contact: [email protected].
• Engineering: The Information Security Lead is also the sole engineer with access to production systems. No other personnel have read or write access to production data.
• Subprocessors: See Section 11. Each subprocessor is responsible for its own infrastructure security under its own audited compliance program (typically SOC 2 Type II).

3. Data classification

Class	Examples	Handling
Restricted	Plaid bank tokens, Stripe secret keys, Supabase service role keys, customer payment card last-4 + tokens, bank routing/account numbers	Stored only in encrypted secret stores (Supabase Vault, Stripe-tokenized references, Plaid-managed access tokens). Never logged, never transmitted in plain text, never shared with humans by email or chat.
Sensitive	End-user names, emails, phone numbers, business addresses, transaction history, employee schedule data, fan profile data, photo uploads	Stored encrypted at rest. Read access scoped to the owning business via row-level security. CSV export available only to authenticated business administrators.
Internal	Aggregate metrics, AI prompt logs (without personal data), system telemetry	Stored in standard Postgres tables, retained per Section 13.
Public	Marketing site copy, public llms.txt and agents.html, published Arpejo events	No restriction.

4. Access control

Access to production systems and data follows the principle of least privilege.

• Multi-factor authentication (MFA) is required and enforced for the Information Security Lead's access to every critical system: Supabase, Netlify, Stripe, GitHub, Google Cloud, OpenAI, Anthropic, Twilio, Vapi, Resend, Plaid, and the company password manager.
• Customer-facing MFA. Every customer-facing administrator login (CommandHub at admin.conciergepilot.co) requires TOTP-based multi-factor authentication via Supabase Auth. New users are forced to enroll a TOTP factor (compatible with 1Password, Authy, Google Authenticator, Microsoft Authenticator, or any RFC 6238 client) before they can access any tenant data. Application routes verify Authenticator Assurance Level 2 (AAL2) on entry; sessions at AAL1 are returned to the login screen to complete the MFA challenge.
• Row-level security (RLS) is enabled on every Postgres table that holds tenant-scoped data. Policies enforce that authenticated users can only read or write rows belonging to their own business (matched on company_id via auth.uid()).
• Edge function authentication. Every edge function that accesses sensitive data verifies the caller's JWT (verify_jwt: true) or a shared secret header for cron-style endpoints. Functions that perform privileged actions (refunds, payroll exports, shift closes, bill auto-pay) additionally check that the caller is in the relevant role table (cp_artist_users, company_users) before proceeding.
• Webhook verification. All inbound webhooks (Stripe, inbound email, Plaid) are verified using HMAC-SHA256 signature checks with constant-time comparison and a 5-minute replay-tolerance window.
• Idempotency tables dedupe retried webhooks and payment confirmations to prevent double-processing.
• Service-account credentials are stored in Supabase Vault. Personal SSH keys, API tokens, and OAuth secrets are stored in 1Password (or equivalent), never committed to source control. Source-controlled .env.example files contain placeholders only.
• Audit columns are added to every sensitive operation: refunds (refund_note, refunded_at, refund_id), shift closes (signed_off_at, manager_employee_id), payroll exports (locked_at, locked_by), bill auto-pays (auto_pay_last_amount_cents, payment_method_id).

5. Encryption

• In transit: All client-to-server and server-to-server traffic uses TLS 1.2 or higher. Netlify, Supabase, Stripe, and all subprocessors enforce HTTPS-only on their endpoints. HTTP requests to our public domains are 301-redirected to HTTPS.
• At rest: Production Postgres data is stored in Supabase, which provides AES-256 encryption at rest by default on its managed database service. File uploads (photos, invoices, gallery images) are stored in Supabase Storage with the same encryption. Backups are encrypted in transit and at rest.
• Application secrets (API keys, database credentials, webhook signing secrets) are stored encrypted in Supabase Vault and accessed via the platform's encrypted secret-fetching API.
• Plaid access tokens received during bank connection are stored in the bank_connections.plaid_access_token column. The column is protected by RLS; only edge functions running with the Supabase service role key can read it. Tokens are deleted within 30 days of account disconnection.

6. Network and infrastructure security

• Production systems run on Supabase (managed Postgres, edge functions, storage) and Netlify (static hosting, edge redirects). Both providers maintain SOC 2 Type II compliance and operate hardened, multi-tenant infrastructure with their own physical and network security controls.
• The Company does not operate its own physical servers, datacenter, or office network. There is no on-premises infrastructure to secure.
• Edge functions execute in isolated Deno runtimes with no persistent file system. Outbound network access is permitted only to documented subprocessor endpoints.
• DNS is managed via Namecheap with DNSSEC enabled where the registrar supports it, and SPF/DKIM/DMARC records configured for transactional email domains.

7. Vulnerability management

• Dependency monitoring: The codebase uses pinned dependency versions in package.json and deno.json. GitHub Dependabot is enabled on the primary repositories and surfaces known CVEs in third-party packages. Critical and high-severity advisories are patched within 7 days.
• Platform-level patching: Supabase, Netlify, and other managed platforms apply OS, runtime, and database patches automatically as part of their managed-service responsibility. The Company is not responsible for patching base infrastructure.
• Endpoint security: The Information Security Lead's primary development machine runs current macOS with FileVault full-disk encryption enabled, automatic OS updates, and a hardware secure enclave for credential storage. Removable devices are not used for code or production data transfer.
• Code review: All changes to edge functions and authentication-sensitive routes are reviewed against a checklist that includes: input validation, RLS coverage, JWT verification, and logging hygiene (no PII or secrets in logs).

8. Secure software development lifecycle

• Source code is hosted in private GitHub repositories. Branch protection requires that all changes to main pass deploy preview checks before merge.
• Database schema changes are applied via Supabase migrations, reviewed before deploy, and version-controlled.
• Edge function deploys go through Supabase's managed deploy pipeline. Secrets are injected at runtime, not baked into the deployed artifact.
• Production and development environments use separate Supabase projects, separate Stripe accounts (test mode vs. live mode), and separate Plaid environments (sandbox, development, production).
• No customer data is ever copied from production into development or local environments. Demo data is synthetic.

9. Incident response

The Company maintains a documented incident response process tuned to its size:

• Detection: Supabase logs, Stripe webhook event-delivery dashboard, Netlify deploy alerts, and uptime monitoring on critical edge functions surface anomalies. Customers can report suspected security issues to [email protected] 24/7.
• Triage: The Information Security Lead acknowledges any reported incident within 4 business hours and begins investigation. Severity is classified as: P0 (active data exposure), P1 (exploit feasible, no confirmed exposure), P2 (defensive degradation), P3 (informational).
• Containment: The first action on any P0 or P1 is to revoke the affected credential or token, disable the affected endpoint, or roll back the affected deploy. Customer-facing functionality is degraded over allowing exposure to continue.
• Notification: If an incident affects customer or end-user data, the Company notifies affected parties within 72 hours of confirming impact, in accordance with applicable breach-notification laws (state and federal). For incidents affecting data received via Plaid, the Company notifies Plaid in accordance with the Plaid Master Services Agreement.
• Post-mortem: Every P0 and P1 incident produces a written post-mortem documenting root cause, timeline, customer impact, and remediation. Remediations are tracked to closure.
• Tabletop exercises: The Information Security Lead reviews and rehearses the incident response process at least annually.

10. Backup and disaster recovery

• Production Postgres data is backed up automatically by Supabase with point-in-time recovery (PITR) enabled. Recovery point objective: under 24 hours. Recovery time objective: under 4 hours.
• Code is hosted in GitHub with full distributed history; any developer machine has a complete copy.
• Static site assets are deployable from source in under 5 minutes via Netlify's CLI deploy.
• Disaster recovery is tested by performing a non-production restore at least annually.

11. Subprocessors

The Company uses the following subprocessors, each bound by their own security and privacy commitments:

Subprocessor	Purpose	Compliance
Stripe	Payment processing, Connect, refunds	PCI DSS Level 1, SOC 2 Type II
Plaid	Bank connectivity	SOC 2 Type II, ISO 27001
Supabase	Postgres, authentication, storage, edge functions	SOC 2 Type II, HIPAA-eligible
Netlify	Web hosting	SOC 2 Type II
OpenAI	AI inference	SOC 2 Type II
Anthropic	AI inference	SOC 2 Type II
Resend	Transactional email	SOC 2 Type II
Twilio / Vapi	SMS and voice	SOC 2 Type II, HIPAA-eligible
Google Cloud	Places API, Maps, Gemini	SOC 1/2/3, ISO 27001

The Information Security Lead reviews the list quarterly. Adding a new subprocessor requires verifying the provider has a published SOC 2 or equivalent attestation, a public privacy policy, and a documented data-processing agreement (DPA). Removing a subprocessor requires confirming all customer data is purged from their systems.

12. Training and personnel

The Company has one technical operator (the Information Security Lead). At onboarding, every new operator (none currently planned) would be required to:

• Sign a confidentiality agreement covering customer data.
• Complete a security-awareness review covering phishing, credential hygiene, and the principles in this policy.
• Set up MFA on every system before being granted any production access.
• Use a hardware-key second factor for any role with write access to production.

The Information Security Lead reviews this policy and the threat landscape at least quarterly.

13. Data retention and deletion

The Company retains customer data only as long as necessary to provide the Services or to comply with legal obligations.

• Active account data is retained for the lifetime of the account.
• On account closure, personally identifiable data is deleted or anonymized within 30 days.
• Financial records (invoices, refunds, payroll exports) are retained for 7 years to satisfy U.S. tax and audit obligations.
• Plaid access tokens are deleted immediately on bank disconnection.
• System logs and AI prompt traces are retained for 90 days then purged.
• Backup snapshots roll off according to Supabase's PITR retention window (typically 7 days for the operational tier in use).

Customers may request deletion of their data at any time by emailing [email protected]. See the Privacy Policy for the full deletion procedure and the rights of California residents under CCPA / CPRA.

14. Autopilot — agentic commerce safeguards

Concierge Pilot offers an optional add-on called Autopilot that automates routine vendor-replenishment for our customers. Because Autopilot moves money on the customer's behalf, it is governed by the following safeguards.

• User-authorized automation within bounded controls. Autopilot operates only inside rules the customer (account owner) has explicitly defined. The system cannot initiate any payment outside those rules. There is no autonomous spending; every transfer is either pre-authorized by an owner-set rule (e.g., "auto-approve restocks under $300/day from approved vendor X") or requires explicit per-transfer SMS approval from the owner before execution.
• Owner-defined rule set per tenant. Each Concierge Pilot tenant configures a private rule set including: pre-approved supplier whitelist, per-order spend cap, daily spend cap, monthly spend cap, approval threshold (above which manual SMS approval is required), and a kill switch that immediately halts all activity.
• SMS approval flow. When an Autopilot draft order requires approval, the system sends a one-time tokenized link via SMS to the registered owner's mobile number using the tenant's own Twilio sender. The customer responds YES/NO or clicks the tokenized approve/reject link. Tokens are single-use, expire after a customer-configured timeout (default 4 hours), and are validated server-side before any state change.
• Bank connection via Plaid Link. The customer connects their own business bank account through Plaid Link, which uses bank-grade authentication directly with the financial institution. Concierge Pilot never collects, stores, or sees the customer's bank login. Plaid access tokens are stored server-side as encrypted secrets in our Supabase project vault and are never exposed client-side. Customers may revoke the Plaid connection at any time through their bank, through Plaid, or through the Concierge Pilot dashboard.
• ACH payment execution via Plaid Transfer. Approved orders are executed as standard ACH debits using Plaid Transfer. The ACH class is auto-selected based on the connected account type (CCD for business accounts, PPD for personal). Each transfer call uses an idempotency key tied to the originating order to prevent duplicate debits in case of retries.
• Balance verification before execution. Where available, Autopilot performs a Plaid balance check on the connected account before initiating each transfer to reduce returns due to insufficient funds.
• Webhook signature verification. All inbound Plaid webhook events (transfer lifecycle, item updates) are validated using HMAC-SHA256 signature verification against the per-environment Plaid webhook signing secret. Unsigned or invalid-signature webhook payloads are rejected with HTTP 401.
• Audit log. Every Autopilot draft, budget check, approval request, approval response, transfer initiation, transfer status change, and webhook event is recorded immutably in the autopilot_audit_log table, scoped to the tenant. Customers can review the full timeline of any order from their dashboard.
• Pause and unwind. Customers can pause Autopilot for a defined window (e.g., during travel or seasonal closures) or unlink the bank connection entirely with one click. Pausing immediately blocks all new orders and SMS approval requests; unlinking immediately revokes the stored Plaid access token.
• Compliance posture. Concierge Pilot is not a money services business. We do not hold customer funds, we do not co-mingle funds, and we do not act as a payment processor or merchant of record. ACH transfers move directly between the customer's connected bank account and the customer's pre-approved vendor's bank account on the customer's authorization. Concierge Pilot is the technology platform that automates the customer's instructions within the customer's defined rules.

15. Policy review and version control

This policy is reviewed at least annually by the Information Security Lead, and reissued whenever there is a material change to the Services, the subprocessor list, the legal landscape, or a contractual obligation. Material changes are noted in the version history below.

• v1.0 — May 3, 2026. Initial policy. Replaces ad-hoc internal documentation.
• v1.1 — May 5, 2026. Added Section 14 (Autopilot — agentic commerce safeguards) covering user-authorized automation, owner rule sets, SMS approval, Plaid Link bank-connection, Plaid Transfer ACH execution, webhook signature verification, audit logging, and pause/unwind controls.

16. Contact

Questions about this policy, security disclosures, or compliance follow-ups:

Custom AI Apps LLC
Attn: Information Security
4814 Arc Bend Road
Midlothian, TX 76065
Email: [email protected]