Blog

April 10, 2026 | Reading time: 10-12 minutes

How the ARKONA Access Request Pipeline Actually Works

Someone clicks "Request Ecosystem Access" on the portfolio site. A success message appears: "Your request is under review. You will be contacted with an invite code once approved." What happens between that click and the moment they're inside the platform, navigating COMET or reviewing FORGE agents? This article traces the entire pipeline — every system touched, every decision gate, every piece of infrastructure that makes it work.

Layer 0: The Email Infrastructure

Before any access request can function, the domain needs working email. The ARKONA ecosystem runs on arkonaresearch.com, hosted through Cloudflare with ProtonMail handling all email operations. The DNS configuration is the invisible foundation:

MX records tell the internet where to deliver mail. SPF declares which servers are authorized to send mail on behalf of the domain — without it, anyone could forge a From: [email protected] header. DKIM provides cryptographic signing so the recipient's server can verify the message wasn't tampered with in transit. DMARC ties SPF and DKIM together with a policy: quarantine messages that fail both checks.

Without all four layers, outbound email lands in spam folders and inbound email bounces. The access request pipeline depends on email at two points: admin notifications when requests arrive, and OTP verification codes during passkey registration. Both fail silently if the DNS is misconfigured.

Stage 1: The Contact Form Submission

The access request lives on the portfolio site's contact page. The form collects five fields: name, email, organization, area of interest (dropdown), and an optional message. The interest categories map to ecosystem domains — AI Governance, Software Engineering, Cybersecurity, Research, Business Operations, and General Inquiry.

When the user clicks submit, the form posts to POST /api/contact on the Cloudflare Worker. The Worker performs three operations in sequence:

Validation. Name, email, and interest are required. The email is checked against a regex pattern. If any field is missing or malformed, the request is rejected with a 400 status before it touches the database.

Rate limiting. The Worker queries the D1 database for submissions from the same email address in the last 24 hours. If three or more exist, the request is rejected. This prevents both accidental duplicate submissions and deliberate flooding. The rate limit is per-email, not per-IP, because a legitimate user switching networks shouldn't be penalized.

Storage and notification. The submission is inserted into the contacts table with a pending status, the submitter's IP address, and a UTC timestamp. Immediately after the database write, the Worker sends a push notification to the admin via ntfy.sh — an open-source push notification service. The notification includes the submitter's name, email, organization, and interest area. It arrives on the admin's phone within seconds.

The user sees "Request Sent" and waits. The system has their submission in a database with full audit trail. The admin has a real-time notification on their phone.

Stage 2: Admin Triage

The admin reviews incoming requests through the protected API. GET /api/invite/contacts returns the last 100 contact submissions with their status. Each record shows who submitted, when, from where, and what they're interested in.

This is a human decision point. The admin evaluates context: Is this a hiring manager who was sent the portfolio link? A colleague reviewing the ecosystem for a collaboration? A researcher interested in the AI governance framework? Or an automated scraper that filled in garbage data?

The status field on the contact record tracks the outcome: pending (unreviewed), reviewed (seen but no action), invited (invite code issued), or declined (rejected). This state machine ensures no request falls through the cracks.

For approved requests, the admin moves to Stage 3.

Stage 3: Invite Code Generation

The admin creates an invite code by calling POST /api/invite/create with a bearer token. The request body specifies two things: the email address and the scopes.

The email must match the contact submission — the invite code is bound to a specific person. The scopes are a comma-separated list of domain identifiers that control what the user can access once inside the portal:

• comet — AI Governance Dashboard
• forge — Software Factory
• muxd — Hybrid LLM Router
• rango — Scholar and Security Center
• bizops — Business Applications
• media — AI Media Suite

A hiring manager reviewing the portfolio might receive comet,forge. A cybersecurity collaborator might get comet,rango. No user gets access to everything unless explicitly scoped for it.

The system generates a code in the format ARK-XXXXXXXXXXXX — a 24-character alphanumeric string from a cryptographically secure random source. The code is stored in the invite_codes table with a 7-day expiration. After 7 days, the code becomes inert — it cannot be used to register even if it was never redeemed.

The admin sends the code to the user out-of-band — typically via the same email thread that initiated the conversation. The code travels through ProtonMail's encrypted infrastructure, authenticated by the SPF/DKIM/DMARC records configured in Layer 0.

Stage 4: Email Verification

The user navigates to the portal registration page and enters their email address and invite code. The system performs three checks before sending anything:

1. Does this invite code exist in the database?
2. Does the email on the invite code match the email the user entered?
3. Is the invite code unexpired and unused?

If all three pass, a 6-digit one-time password is generated and emailed to the user from [email protected]. The OTP is stored in Cloudflare KV with a 10-minute TTL — after 10 minutes, the code self-destructs. Rate limiting caps OTP sends at 5 per email per hour.

The response to the user is deliberately vague: "If the invite is valid, a code was sent to your email." This is intentional. If the response said "Invalid invite code" or "Email doesn't match," an attacker could enumerate valid codes or test email-code pairs. The uniform response reveals nothing about the internal state.

The user checks their inbox, finds the 6-digit code, and enters it. The system compares it using a constant-time algorithm — XOR accumulator, not string equality — to prevent timing side-channel attacks where an attacker measures response latency to determine how many digits matched.

On success, a 15-minute registration token is issued. The clock is ticking.

Stage 5: Passkey Registration

With the registration token, the user's browser initiates a WebAuthn ceremony. The server generates a challenge — a random byte sequence that prevents replay attacks — and sends it to the browser along with the relying party identifier (arkonaresearch.com).

The browser calls navigator.credentials.create(), which triggers the device's authenticator: Face ID on iPhone, Touch ID on Mac, Windows Hello on PC, or a hardware security key. The user performs a biometric gesture. The authenticator generates a public-private key pair, signs the challenge with the private key, and returns the signed attestation to the browser.

The browser sends the attestation to the server. The Cloudflare Worker performs full server-side verification:

• Decodes the CBOR-encoded attestation object
• Parses the authenticator data binary structure
• Verifies the RP ID hash matches the expected domain
• Checks that both User Presence and User Verification flags are set
• Extracts the COSE public key and converts it to SPKI format for storage
• Stores the credential ID, public key, counter, and algorithm in D1

The invite code is marked as used. A user account is created. A session cookie is set — HttpOnly, Secure, SameSite=Strict, scoped to /api. The user is in.

No password was created. No password exists anywhere in the system. The private key never left the authenticator hardware. Authentication going forward requires physical possession of the registered device and a biometric match.

Stage 6: Scoped Portal Access

Once authenticated, the portal page loads and calls GET /api/portal/me to retrieve the user's profile. The response includes their email, display name, the scopes from their invite code, and their membership date. Every API call re-validates the invite code — if the admin revoked it between page loads, the next request fails immediately.

The portal then calls GET /api/portal/status to retrieve the list of accessible domains. Each domain entry includes a name, description, and access URL. The URLs point to either static demo snapshots (screenshots of the running services) or live Cloudflare Tunnel endpoints, depending on the access tier.

The user sees only what their scopes allow. A comet,forge scope shows two domain cards. A comet,rango,bizops scope shows three. There is no menu item, link, or API response that reveals the existence of domains outside the user's scope.

The Admin Control Surface

The admin retains full control at every stage. The protected API provides six operations:

View contacts (GET /api/invite/contacts) — See all submissions with status tracking.

Create invite (POST /api/invite/create) — Generate a scoped, time-limited invite code for a specific email.

List invites (GET /api/invite/list) — See all issued codes with usage status.

List users (GET /api/invite/users) — See all registered portal users with active session counts and registered credential counts.

Revoke invite (POST /api/invite/revoke) — Delete an invite code and cascade-revoke all sessions for users who registered with it.

Kill all sessions (POST /api/invite/kill-all) — Revoke every active session in the system. The nuclear option.

Revocation is instant. There is no grace period, no "session will expire at end of day" delay. The next API call from a revoked user returns 401, and the portal UI immediately shows the authentication gate.

The Complete Pipeline

Viewed end-to-end, the access request pipeline has seven discrete stages, three human decision points, and four automated verification steps:

DNS Infrastructure (MX/SPF/DKIM/DMARC)
    |
    v
Contact Form Submission -----> D1 Database + ntfy.sh notification
    |
    v
Admin Triage (human) ---------> approve / decline
    |
    v
Invite Code Generation -------> ARK-XXXX, scoped, 7-day expiry
    |
    v
Out-of-Band Delivery (human) -> email via ProtonMail
    |
    v
Email OTP Verification -------> 6-digit code, 10-min TTL
    |
    v
Passkey Registration ----------> WebAuthn, biometric, no password
    |
    v
Scoped Portal Access ----------> domain cards based on invite scopes
    |
    v
Ongoing Admin Control ---------> revoke, kill-session, kill-all

Every stage has a security gate. The contact form has rate limiting. The invite code has email binding and expiration. The OTP has time limits and constant-time comparison. The passkey has cryptographic verification. The session has HttpOnly cookies and re-validation. The admin has instant revocation.

The entire system runs on Cloudflare's free tier — Workers for compute, D1 for storage, KV for ephemeral state, Pages for the static site. ProtonMail handles email with end-to-end encryption. The monthly infrastructure cost is the price of the ProtonMail subscription.

From the outside, it looks like a contact form. From the inside, it's a zero-trust access control pipeline with seven layers of verification, scoped permissions, real-time admin notifications, and instant revocation — built without a single traditional server.