Access Control Policy

This Access Control Policy defines the principles and requirements that govern access to ShipReady Metrics information systems, applications, infrastructure, and customer data operated by Persoon.ai Inc. Its purpose is to ensure that access is granted on a least-privilege, need-to-know basis and is consistently provisioned, reviewed, and revoked across the platform.

This policy applies to all personnel (employees, contractors, and authorized third parties), all production and non-production environments, and all components of the ShipReady Metrics platform, including the Next.js application, the Supabase Postgres database and authentication layer, Vercel hosting, and connected integrations such as GitHub and cloud connectors.

• In scope: production and staging environments, the customer-facing application, administrative tooling, source code repositories, CI/CD pipelines, and third-party services that process customer data.
• Out of scope: customer-side identity systems and end-user devices not managed by Persoon.ai Inc., except where they interface with platform single sign-on (SSO).

• Least privilege: users and services receive only the access required to perform their function, and no more.
• Need to know: access to customer data is limited to personnel with a legitimate business reason.
• Separation of duties: sensitive operations (e.g., production deploys, key management) are split across roles where practical to reduce the risk of unilateral abuse or error.
• Default deny: access is denied unless explicitly granted; tenant data is isolated by default.
• Accountability: access and privileged actions are attributable to an individual identity and logged.

ShipReady Metrics enforces role-based access control within the application. Each user belongs to one or more tenant organizations and is assigned an application role that determines the actions and data they may access. Authorization is evaluated both in the application layer and at the database layer through Postgres Row-Level Security (RLS) policies, so that a request is rejected if either layer denies it.

Roles are assigned by an organization Admin. The role definitions above are representative of the current implementation and must be confirmed against the live authorization model by the platform owner before this policy is finalized.

User authentication is handled through Supabase Auth. Credentials are never stored in plaintext, and sessions are issued as signed, expiring tokens transmitted only over TLS.

• Multi-factor authentication (MFA) is supported and is recommended for all users and required for privileged (Admin) accounts where enforced.
• Enterprise single sign-on (SSO) via SAML/OIDC and automated user lifecycle via SCIM provisioning are offered for eligible plans; availability and configuration must be confirmed by the platform owner.
• Service-to-service and integration credentials (e.g., connector tokens, API keys) are scoped to the minimum required permissions and stored as managed secrets rather than in source code.
• Passwords and authentication tokens are subject to expiry and rotation requirements appropriate to their sensitivity.

ShipReady Metrics is a multi-tenant platform. Tenant data is logically isolated within a shared Postgres database using Row-Level Security policies keyed to the requesting user’s organization. Application queries execute under the authenticated user’s context, so a user cannot read or modify data belonging to another tenant even in the event of an application-layer bug.

Changes to RLS policies are treated as security-sensitive, are reviewed before deployment, and are validated against tenant-isolation test scenarios. Formal third-party validation of isolation controls (e.g., penetration testing) is in progress / not yet obtained — see the Trust Center for current status.

• Provisioning: access is granted only after authorization by an appropriate approver and is mapped to a defined role rather than ad hoc permissions.
• Changes: role changes and elevated-access grants are recorded and attributable to the approving party.
• Deprovisioning: access for departing personnel or expired contractors is revoked promptly upon role change or offboarding, including application accounts, infrastructure access, and integration credentials.
• Within-tenant offboarding: organization Admins are responsible for removing members who no longer require access to their organization.

Access to production infrastructure — including the Supabase project, Vercel hosting and environment configuration, secret stores, and the Anthropic and Resend integrations — is restricted to authorized personnel with an operational need. Privileged access follows least-privilege and is granted through the underlying providers’ own access controls.

• Production secrets and API keys are stored in managed environment/secret stores and are never committed to source control.
• Privileged actions (deploys, migrations, configuration changes) are logged and attributable.
• Direct, standing access to production data is minimized; access for support or debugging is limited to what is necessary and is logged.

Authentication events and privileged actions are logged to support an audit trail and incident investigation. Access rights are reviewed periodically to confirm they remain appropriate, and discrepancies are remediated.

• Periodic access reviews (recertification) confirm that user roles and privileged grants are still warranted.
• Anomalous authentication activity is monitored and investigated.
• Audit logs are retained for a defined period appropriate to operational and compliance needs (to be confirmed by the platform owner).

Violations of this policy may result in revocation of access and, for personnel, disciplinary action up to and including termination, as well as potential legal action. This policy is reviewed at least annually and updated as the platform and applicable obligations evolve.

Questions about this policy or requests related to access should be directed to security@persooninc.com. This document is an AI-generated draft and is not legal advice or a binding commitment until reviewed and approved by Persoon.ai Inc. and counsel.