Access Expectations

This document defines the access control standards that apply to all EGI systems, services, and projects. These expectations are mandatory for internal tools and strongly recommended for client-facing applications.

Named Accounts Only

Every individual who accesses an EGI system must use a named, personal account. Shared accounts are not permitted.

Rules

• Every account must be traceable to a single individual
• Generic accounts (e.g., admin@, dev@, support@) are prohibited for human use
• Service accounts (used by automated systems) must be clearly labeled as such and documented with an owner
• If multiple people need access to the same resource, each person gets their own account with appropriate permissions

Why This Matters

• Audit trail: Named accounts make it possible to trace every action to a specific person
• Accountability: Shared accounts make it impossible to determine who performed an action
• Revocation: When someone leaves, only their account is disabled; shared account password rotation is error-prone and disruptive

Least Privilege

Every account, token, and API key should have the minimum permissions necessary to perform its intended function. No more, no less.

How to Apply

Context	Least Privilege Practice
New user accounts	Start with no access; grant permissions explicitly based on role
GitHub repositories	Grant write access only to assigned repositories; read access only when needed
API keys	Scope to specific endpoints, resources, or actions
Database access	Use read-only connections for reporting; write access only for the application layer
Cloud services	Use IAM policies scoped to specific resources; avoid wildcard permissions
Environment variables	Only deploy secrets needed by the specific service

Privilege Escalation

When a team member needs elevated access (e.g., temporary admin access to debug an issue):

1. Request access through the #operations Slack channel with a clear justification
2. The operations lead grants time-limited elevated access
3. Access is revoked automatically or manually after the stated timeframe
4. The escalation is logged for audit purposes

Group-Based Access

Access should be managed through groups or roles, not individually assigned permissions. This simplifies provisioning, auditing, and revocation.

Standard Groups

Group	Description	Typical Members
Developers	Write access to assigned code repositories, Vercel deployments, PostHog analytics	Software engineers
Designers	Read access to design-related repos, Penpot projects	UI/UX designers
Project Managers	Read access to repos, full access to SuiteDash, PostHog viewer access	PMs, team leads
Operations	Admin access across all services; responsible for provisioning and deprovisioning	Operations leads

How Groups Work in Practice

• When a new developer joins, add them to the "Developers" group in GitHub, Vercel, and other services
• When a developer is assigned to a new project, add them to the project-specific team in GitHub
• When someone leaves, remove them from all groups -- this revokes all access in one step
• Review group memberships quarterly to prevent privilege creep

Multi-Factor Authentication (MFA)

MFA is required for all EGI-operated services that support it. This is a non-negotiable requirement for all team members.

MFA Requirements

Requirement	Detail
Enrollment deadline	Within 24 hours of account creation
Preferred method	TOTP authenticator app (Authy, 1Password, Google Authenticator)
Acceptable fallback	SMS-based MFA (only when TOTP is not supported by the service)
Hardware security keys	Encouraged for high-privilege accounts (org admins, Cloudflare admins)
Recovery codes	Must be generated and stored securely in a password manager

MFA for Client Applications

When building client-facing applications, MFA should be:

• Offered to all users
• Required for admin and elevated-privilege roles
• Implemented using TOTP (time-based one-time passwords) as the default method
• Documented in the auth handoff documentation for Anchor

Quarterly Access Reviews

Every quarter, the operations lead conducts a formal review of all access across EGI systems.

Review Process

1. Generate the access report: Pull the current member list from each service (GitHub, Slack, Vercel, PostHog, ERPNext, Cloudflare, SuiteDash)
2. Cross-reference with active roster: Compare the access lists against the current list of active team members
3. Identify discrepancies:
   • Former employees who still have access (must be revoked immediately)
   • Active employees with permissions beyond their current role (must be adjusted)
   • Unused accounts or dormant sessions (must be investigated)
4. Remediate: Revoke, adjust, or deactivate as needed
5. Document: Record the review date, findings, and actions taken

Review Checklist

Check	Action if Failed
All accounts belong to active team members	Revoke access immediately
Permissions match current role assignments	Adjust to least privilege
MFA is enabled on all accounts	Require enrollment within 48 hours
Shared credentials have been rotated in the last 90 days	Rotate immediately
Service accounts have a documented owner	Assign an owner or deactivate

Compliance and Enforcement

• These expectations are communicated during onboarding (see Employee Setup)
• Violations are addressed through the manager, not punitively, but with the expectation of immediate correction
• Repeated violations or refusal to enable MFA may result in access suspension pending resolution