Access Control Policy

Access is granted to one identity, on the minimum scope that does the job, with a second factor required everywhere. Where a credential can be read-only, it is read-only.

There is one operational identity: Christopher Foley, managing partner of PXLPOD Media LLC, who is the only person who signs in to any system in scope. No employee, contractor, or third party holds credentials to any of them.

The company has a second owner, a silent minority shareholder, who holds no account on any system and performs no operational function. She holds the administration workstation credential as a continuity measure only — recovery on the death or incapacity of the managing partner. Because that workstation can reach the application’s secrets, this is real access and is stated as such rather than described as none.

What matters is the number of readers, not the shape of the address. A role address used as a platform username is acceptable as the primary account for a system in scope provided one person can read it. An address several people can read is not, whatever it is called: anyone who can open that inbox can complete a password reset and take the account.

Accordingly, the company operates two role addresses with different rules. The platform address holds the subscriptions and credentials for systems in scope and is readable by the owner alone; it exists so that vendor notifications do not compete with correspondence in a personal inbox. A separate address exists for shared access by external development partners to resources outside this scope, and is never used as the sign-in or recovery address for any system holding confidential data.

This control is a rule rather than a structural guarantee: the platform address is secure because one person reads it, and granting a second person access to that inbox would silently make every account behind it a shared account. The quarterly review in §9 therefore checks reader count, not just account count.

Multi-factor authentication is required on every system that stores or processes data in scope, and is currently enabled on:

Time-based one-time codes are not phishing-resistant — a code can be relayed to a fraudulent page in real time. Where a system supports passkeys or hardware security keys, those are preferred and are adopted as each system offers them. This limitation is stated rather than glossed, because describing one-time codes as “strong” would misrepresent what they defend against.

A system that cannot enforce multi-factor authentication does not receive confidential data.

Keys are granted the narrowest permission set that works, and permissions are not widened to make a task convenient. Where a task fails for want of a permission, the decision to widen is deliberate and recorded.

Row-level security is enabled on every table, with no permissive policies defined. The database is deny-all by default: no anonymous or publishable key can read any row. All access is through the application’s server-side service credential.

This is verified after every migration. A migration that adds a table without row-level security is a defect, not a style issue.

• The repository is private.
• Deployment is by version-control push to the main branch only. Deploying from a local command line is prohibited.
• A pre-push hook runs the production build and the projection fixtures.
• Preview deployments are gated by platform single sign-on and are not publicly reachable.
• Preview environments read and write the live database. A branch is therefore not a sandbox, and any change that writes data is treated as a production change regardless of which branch it is on.

• One macOS workstation, used for administration and development.
• Full-disk encryption enabled.
• Current operating system release with automatic updates enabled.
• Screen lock required.
• Secrets held in a local environment file excluded from source control.

Because there is one identity, provisioning is not a workflow. What matters is revocation, and every credential in §4 can be rotated from its own dashboard without a redeployment.

Should a person ever be granted access — a contractor, an accountant, an auditor — the following applies without exception:

• a named individual account, never a shared login;
• multi-factor authentication enrolled before any data is reachable;
• read-only unless a write is specifically required;
• an end date set at the time access is granted;
• revoked on the end date or on conclusion of the engagement, whichever is sooner.

Reviewed quarterly. The review covers:

• every account on every system in scope — confirming one operational identity, no forgotten collaborators, no lingering invitations;
• the continuity arrangement (§2) — that it still reaches what it needs to and no more, and that it is still held by the intended person;
• every API key and token — confirming it is still needed, still scoped correctly, and still read-only where it should be;
• multi-factor authentication state on each system;
• the reader count on every address used for sign-in or account recovery (§2) — a second reader on the platform address converts every account behind it into a shared account;
• row-level security state on every table (§5).

Reviews are recorded in the repository. A review that finds nothing is still recorded, because the absence of a record is indistinguishable from the absence of a review.