Last updated:
Access Control Policy
Version: 1.0 · Status: Active · Effective: 2026-05-05
1. Purpose
This policy defines the access control framework for the Projan platform. It describes the controls governing authentication, authorisation, session management, and account lifecycle to ensure that access to the platform and its data is appropriately restricted and auditable.
This policy applies to Projan AI Ltd (company number 17196385).
2. Scope
This policy covers all access to the Projan platform, including:
- Interactive user access via web and mobile applications
- Programmatic access via API keys
- Real-time communication channels (subscriptions and notifications)
- Third-party integration access (Slack, Jira, Notion, and other connected services)
- Administrative operations performed by team administrators
3. Authentication
3.1 User Authentication
Projan authenticates users through a managed identity provider using industry-standard protocols. All authentication tokens are cryptographically signed and verified on every request.
- Access tokens are short-lived (1 hour) and must be refreshed using a separate refresh mechanism
- Refresh tokens are valid for up to 30 days and support revocation
- Authentication flows use industry-standard challenge-response protocols and OAuth 2.0 authorisation code grant; less secure flows such as implicit grant are disabled
- Token revocation is enabled, allowing immediate invalidation of compromised credentials
3.2 API Key Authentication
Projan issues API keys for service-to-service communication, including integrations and automated tooling.
- API keys are transmitted via a dedicated request header
- Only a cryptographic hash of each key is stored; the plaintext key is never persisted after initial generation
- Each key has a configurable expiration period
- Usage is tracked to support auditing and anomaly detection
- Revocation takes immediate effect
3.3 Authentication Priority
The platform evaluates credentials in the following order:
- Bearer token (user authentication)
- API key (service authentication)
- If no valid credentials are presented, the request is treated as unauthenticated and is denied access to all protected resources
3.4 Real-Time Connection Authentication
Real-time connections (such as subscriptions) are authenticated using the same credential verification as standard requests. No unauthenticated real-time connections are permitted.
4. Authorisation
4.1 Role Model
Projan implements a role-based access control model with three principal roles:
| Role | Description |
|---|---|
| Individual | Full access to personally owned resources. Operates independently of any team. |
| Team Member | Access to team-shared resources. May create content and view team projects. Editing is restricted to content the member originally authored, unless elevated by a Team Admin. |
| Team Admin | Full administrative access to all team resources. May create, edit, and delete any team content, manage team membership, and configure team-level integrations and billing. |
4.2 Principle of Least Privilege
Access controls are designed around the principle of least privilege:
- Resource ownership: Every resource has a defined owner (individual user or team). Access is granted only to the owner or authorised team members.
- Team-scoped access: Team resources are accessible only to verified members of that team. Membership is validated on every request.
- API key scoping: Each API key is issued with a defined set of permissions appropriate to its intended use. Keys are never granted broader access than required for their function.
- Subscription-level gating: Access to platform features requires an active account in good standing. Users whose subscriptions have lapsed or expired are transitioned to restricted or blocked states as described in the Account Lifecycle section.
4.3 Resource Access Controls
| Operation | Individual Resources | Team Resources |
|---|---|---|
| View | Owner only | Any team member |
| Edit | Owner only | Team Admin or original author |
| Delete | Owner only | Team Admin only |
4.4 Link-Based Access
Certain resources may be shared via authorised link-based access. Link-based sharing follows separate authorisation rules and grants access only to the specific resource identified by the link. Link-based access does not confer any broader platform permissions.
4.5 Suspended Account Restrictions
Projan enforces account suspension restrictions at the platform level, independent of individual feature access checks. Suspended accounts are restricted to read-only access until the suspension condition is resolved.
5. Session Management
5.1 Token Lifecycle
- Access tokens expire after 1 hour and must be refreshed
- Refresh tokens are valid for up to 30 days
- Token revocation is supported and takes immediate effect
- All tokens are validated on every request; expired or revoked tokens are rejected
5.2 Cross-Domain Coordination
A non-sensitive presence indicator is used to coordinate authentication state between the marketing site and the application. This indicator contains no authentication credentials or user data.
5.3 API Introspection
Detailed API schema metadata is not exposed in production environments.
6. API Access Controls
6.1 Key Lifecycle
API keys follow a defined lifecycle:
- Generation: Keys are generated using cryptographically secure random number generation
- Issuance: The plaintext key is provided to the requestor once at creation; only the hash is retained
- Usage: Each use is logged with a timestamp and running count for audit purposes
- Expiration: Keys expire according to their configured lifetime
- Revocation: Keys may be revoked at any time by an authorised administrator, taking immediate effect
6.2 Permission Scoping
Each API key is assigned permissions appropriate to its purpose. Permissions follow a resource-and-action model, ensuring that keys are granted only the access necessary for their intended function.
7. Password Policy
Projan enforces the following password requirements for all user accounts:
| Requirement | Standard |
|---|---|
| Minimum length | 12 characters |
| Uppercase letters | Required |
| Lowercase letters | Required |
| Numeric digits | Required |
| Special characters | Recommended but not required |
| Temporary password validity | 7 days |
| Account recovery method | Email verification only |
| Error handling | Generic error messages are returned to prevent user enumeration |
8. Multi-Factor Authentication
Projan supports time-based one-time password (TOTP) multi-factor authentication for all user accounts. Users may enrol using any compatible authenticator application.
- TOTP-based MFA is available to all users and may be enabled through account settings
- SMS-based second factors are not supported due to known security limitations
- Projan is committed to enforcing mandatory MFA for all team accounts within 6 months of platform launch
- Adaptive authentication and compromised credential detection are enabled in production to provide additional protection against account takeover
9. Account Lifecycle
9.1 Account States
| Status | Description | Access Level |
|---|---|---|
| Trial | Active free trial period (14 days) | Full access |
| Active | Paid subscription with verified payment | Full access |
| Demo | Beta or demonstration account (14 days) | Full access |
| Inactive | Trial or demo ended without payment | Read-only access during 7-day grace period |
| Expired | Subscription cancelled by user | Access blocked |
| Past Due | Payment failed; retry in progress | Full access for 7 days, then read-only |
| Suspended | Account suspended (e.g. seat limit exceeded) | Read-only access |
9.2 State Transitions
Account status is evaluated at authentication time. Key transitions include:
- Trialling to Active: Automatically when a valid payment method and subscription are confirmed
- Trialling or Demo to Inactive: When the trial or demo period expires without a payment method on file; a 7-day grace period begins
- Inactive to Blocked: When the grace period expires without resolution; authentication is denied
- Past Due to Read-Only: When payment remains unresolved after 7 days
- Expired to Blocked: Expired accounts must be reactivated before access is restored
9.3 Grace Period
When an account transitions to an inactive state, a 7-day grace period is applied. During this period, the user may authenticate and access their data in read-only mode. After the grace period expires, authentication is blocked until the account is reactivated.
9.4 Team Member Inheritance
Team members inherit the account status of their team. If a team’s subscription lapses or enters a grace period, all team members are subject to the same access restrictions.
10. Review Schedule
| Activity | Frequency | Responsible Party |
|---|---|---|
| Full policy review and update | Quarterly | Director |
| API key audit (active keys, usage patterns) | Monthly | Director |
| Advanced security configuration review | Quarterly | Director |
| Permission scope review | On each new integration or API key issuance | Director |
| Account status distribution analysis | Monthly | Director |
11. Contact
For questions about this policy, to report a security concern, or to request access-related assistance, contact:
Email: security@projan.ai
Projan AI Ltd will acknowledge all security-related enquiries within 5 business days.