Access Control Policy

This policy sets who may access Greymill systems and data, how that access is granted, proven and removed, and how it is reviewed. It supports section 3 of the Greymill Information Security Policy.

1. Purpose, scope and ownership

• Scope: every system that stores or processes Greymill or customer data: hosting (Vercel), database and storage (Supabase), source code (GitHub), billing (FastSpring), email (Resend), AI model providers, accounting and banking integrations (Xero, Plaid), the Greymill admin console, and company email and identity (Google Workspace). It covers employees, contractors, partners and automated agents.
• Owner: the founder, as Information Security Owner, approves access to Restricted systems and owns this policy.
• Customers: customer sign-in to the Greymill app is covered in section 4.

2. Principles

• Least privilege: each person or agent gets the lowest access their role needs, for no longer than they need it.
• Need to know: Restricted data, including bank data from Plaid, is accessed only to deliver the service or to resolve a specific support or security issue.
• Zero trust: being on a network gives no trust. Every request to production or administrative systems is authenticated and authorised on its own.
• Named accounts only: no shared or generic logins. Each action can be traced to one person or one service.
• Separation of duties: every code change reaches production through a pull request, and a human approves every change written by an automated agent. Production secrets are separate from development and test.

3. Roles and access

Access follows role. Anything not listed is denied by default.

4. Authentication

Staff and contractors

• MFA is required on every system in scope: Vercel, Supabase, GitHub, Plaid Dashboard, FastSpring, Resend, Google Workspace and the domain registrar. An authenticator app or passkey is preferred to SMS.
• The Greymill admin console requires the admin secret plus TOTP two-factor authentication or a passkey. Recovery codes are shown once and stored offline.
• Passwords are at least 12 characters, unique to each system, and held in a password manager. A password is changed at once if compromise is suspected.
• Screens lock after 5 minutes or less. Sessions on administrative consoles expire, and admin sessions can be revoked.

Customers and partners

• Customers sign in with a verified email and password, or with Google Sign-In, in which case their Google account's own two-step verification applies.
• Passwords are hashed with bcrypt. Session tokens are random, stored only as hashes, and expire.
• Sign-in is rate limited. An account locks for 30 minutes after 5 failed attempts in 15 minutes; an IP address locks for 30 minutes after 30 failed attempts in 15 minutes.
• MFA is not mandatory for customers. Partners sign in to the partner dashboard with the same password, hashing and lockout controls.

5. Provisioning: joiners, movers and leavers

1. Request: access is requested in writing (email or ticket), naming the person, the systems, the role and the reason.
2. Approve: the owner approves before access is granted. Production secrets and the Plaid Dashboard need a named task.
3. Grant: a named account is created with MFA turned on before first use. Default access is the role in section 3, nothing more.
4. Record: the grant goes in the access register: who, what, when, approved by, and expiry for temporary access.
5. Change of role: access no longer needed is removed the same day, and new access goes through steps 1 to 4.
6. Leavers: all accounts are disabled within 24 hours of departure, or at once for a dismissal. Every shared secret they could have seen is rotated, including Plaid keys, the admin secret and the encryption key when in scope. Devices are returned or wiped.
7. Temporary access expires on its recorded date and is checked at the next access review.

6. Privileged, service and automated access

• Admin console: needs the admin secret plus a valid 2FA session. Admin endpoints are rate limited with brute-force lockout, and the admin secret is rotated at least once a year.
• Service keys: the Supabase service key, Plaid client secret, encryption key and other API keys are held only in Vercel environment variables and used only by server-side code. They never appear in source code, the browser, logs or chat. Production and sandbox keys are kept apart.
• Scheduled jobs are called only with a dedicated cron secret.
• Webhooks are accepted only with a valid provider signature.
• Automated coding agents work on branches, run tests offline with dummy credentials, hold no production secrets, and cannot deploy. A human approves every merge to production.
• Break-glass: in an emergency the owner may grant time-limited elevated access. It is recorded with its reason, removed within 24 hours, and any secrets used are rotated.

7. Customer data, access reviews and logging

Customer and Plaid data

• The app scopes every query on customer data to the signed-in customer, so no customer can reach another's data.
• Plaid access tokens are encrypted at the field level, are used only by server-side code, and never reach the browser or staff screens.
• Staff view a customer's data only to resolve that customer's request or a security issue. Bank account and transaction data are not exported, copied to personal devices, or shared outside Greymill and its contracted subprocessors.

Access reviews

• Every quarter, the owner reviews every account on every system in scope against the access register and section 3. They remove access that is no longer needed, check MFA is on for every account, and record the date, the findings and what was removed.
• Service keys and secrets are reviewed at the same time, and unused keys are revoked.

Logging

• Sign-ins, failed sign-ins, lockouts and admin sessions are logged and watched on the security operations dashboard.
• Logs never contain passwords, tokens or bank data. They are kept for at least 90 days.
• Unexpected access is handled as a security incident under the Information Security Policy.

8. Exceptions, enforcement and review

• Exceptions are written, approved by the owner, time-limited, and logged in the risk register.
• Enforcement: breaking this policy may lead to access being removed, and to disciplinary action or termination of contract.
• Review: at least once a year, and after any change to systems in scope or any access-related incident.

9. Contact

To report a vulnerability or security concern, email support@greymill.ai. Next scheduled review: October 2027.

Greymill Limited · Registered in England and Wales · Company number 17144930 · ICO registration ZC120843 · 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ