All Docs
FeaturesAgentOS Scope OutUpdated March 11, 2026

v0.1.1 — Email Allowlist Access Gate

v0.1.1 — Email Allowlist Access Gate

Overview

Release v0.1.1 introduces the primary security control for the proptech intelligence platform: a hardcoded email allowlist that gates all access to the application. Only explicitly approved internal team members can sign in. There is no public sign-up flow, and unapproved sign-in attempts are rejected with a clear error message.

How It Works

Allowlisted Accounts

Access is currently restricted to two approved email addresses:

EmailRole
glyn@agentos.comInternal team
dylan@agentos.comInternal team

Any attempt to sign in with an email address not on this list will be rejected.

Sign-In Flow

  1. The landing page (/) immediately redirects to the sign-in screen — there is no marketing or public-facing landing page.
  2. The user enters their credentials.
  3. The authentication layer checks the submitted email against the hardcoded allowlist.
    • ✅ Allowlisted email → access is granted and the user proceeds to the dashboard.
    • ❌ Unlisted email → sign-in is blocked and the user sees an "access restricted" message.

No Self-Registration

There is deliberately no sign-up or account creation flow. This is an internal tool and access must be provisioned manually by a developer updating the allowlist in the codebase.

Adding a New Approved User

To grant access to an additional team member:

  1. Locate the allowlist definition in the authentication layer of the codebase.
  2. Add the new email address to the list.
  3. Redeploy the application.

Note: There is no admin UI for managing the allowlist in this release. All changes require a code update and redeployment.

Security Considerations

  • The allowlist is enforced server-side at the authentication layer — it cannot be bypassed by manipulating client-side state.
  • Rejected sign-in attempts receive a generic "access restricted" message. No additional details (e.g. whether the email exists or not) are disclosed.
  • Because there is no public sign-up path, the application surface area for unauthorised access is minimal.

Limitations

  • The allowlist is hardcoded; adding or removing users requires a code change and redeploy.
  • No audit log of rejected sign-in attempts is recorded in this release.
  • No role-based access control (RBAC) is implemented — all allowlisted users have equal access to the full application.