AOL-Connect as an open platform for volunteers

• Our route table gets one new option per route: which key scope it needs. Routes without it stay app-only. This one switch is the whole “public API”.
• Grant actions, not routes. Some app routes return several views. A key reaches only a listed method, path and view. The first key actions are small, bounded reads: one page, a fixed set of fields, the same visibility rules as the app.
• Bulk reads (offline sync, exports) stay app-only.
• The public subset lives under /api/v1/ as aliases of the same handlers. A future v2 is a new alias set, never a change in place.
• The machine-readable description (OpenAPI) grows with each public action, from the validation schemas the routes already use. A test fails if a public action has no description.
• Rejected: a separate API gateway (a second copy of routing and rules, which drifts) and GraphQL (unbounded queries against database limits).

• The authorization server runs inside our existing Worker, using Cloudflare's workers-oauth-provider library. It supports OAuth 2.1 with PKCE, client metadata documents, dynamic registration, protected resource metadata (RFC 9728) and resource indicators (RFC 8707). It stores only hashes of tokens.
• Our existing sign-in page is the login step. A new, script-free consent page lists the scopes in plain words.
• A token holds: user, chosen role membership, client, scopes and expiry. Access tokens last about an hour. Refresh tokens rotate and expire after 30 days.
• Effective rights = the action is listed for scope S, the token has S, and the action runs the same checks as the app for that person and role.
• Token actions accept only a bearer header and ignore cookies. App routes keep today's same-site protection. The consent page cannot be framed.
• Client registration: client metadata documents first (ChatGPT prefers them), dynamic registration for older clients, pre-registered clients for builder apps.
• Personal read-only key (step 2) for clients without OAuth, such as the xAI API: one role, 30 days, shown once, revocable.
• Device flow (RFC 8628) for screens without a keyboard, such as an event-day kiosk.
• Rejected: pasted personal API keys as the main path, Cloudflare Access as the volunteer login (built for staff tools, per-user cost above 50 users), an outside identity vendor, and hand-written OAuth.

Never by key in the first three steps: export, import, erase, password reset, member changes, and settings. Those stay in the main app. Reading notes is a separate later scope that needs its own owner decision.

For the Teachers CRM, its “area: action” permissions would map to scopes the same way, if the group team agrees.

• One /mcp endpoint on the same Worker, Streamable HTTP, stateless, built with Cloudflare's createMcpHandler. It accepts the current MCP version (2026-07-28) and the older versions clients still use.
• It publishes protected resource metadata, checks that each token was made for this server, and never passes a token on.
• Step 1 read tools: follow-ups due, find my lead, my upcoming events, team numbers (coordinators). Marked read-only. No free text.
• Step 2 write tools, in two parts: the tool stores a pending change and returns a preview with a link “Confirm in AOL-Connect”. The pending change is single-use and expires in 10 minutes. The write is one conditional database update.
• Tool hints such as “read-only” or “destructive” help the client, but they are not the guard. The guard is on our server.
• Answers carry minimum fields: first name and last initial, phone masked to the last two digits, no email.
• Rejected: a confirm tool the AI can call, client-side approval prompts as the only guard, a chatbot we host and pay for, and write tools in step 1.

• One production dispatch namespace, as Cloudflare advises, with tags per builder. Each app is one user Worker.
• A dispatch Worker on the builder domain finds the app and refuses disabled ones.
• An outbound Worker sees every outgoing request and allows only our API host.
• Custom limits cap CPU time and sub-requests per call.
• Apps get no database, storage or Durable Object bindings.
• The dispatch Worker runs the sign-in for every app and keeps the user's token. The outbound Worker adds it to calls to our API. The builder writes a plain request to /api/v1/.
• Cloudflare's default “untrusted” isolation: no shared cache between apps.
• A strict Content Security Policy on every page limits where the browser may send data. Review checks for other ways out. The builder agreement and the kill switch cover what remains.
• Rejected: builders deploying to their own Cloudflare accounts (we could not enforce limits or the kill switch) and builders reading the database.

• Cloudflare's rate-limit binding per token and per client (for example 60 calls a minute) as a cheap first gate. These counters are approximate, so exact caps (such as changes per day) are counted in the database.
• A new read log records time, user, role, client, tool, record type, record numbers and outcome. No names, phones or text. Kept for one year, the period the DPDP Rules name for logs.
• Changes go through existing actions, which already write the audit log. We add which tool made the change.
• Kill switch at four levels: user, client or app for everyone, the whole deployment, and any single builder app.

1. The builder applies, is nominated by a coordinator, signs the builder rules (confidentiality, DPDP duties, no copying data out) and finishes training.
2. The builder develops against the test site with practice data and test keys.
3. Automatic checks: size, requested scopes, no secrets in code.
4. A person reviews any app that asks for a write scope, and checks privacy and ways data could leave.
5. Each new version is reviewed again. Approved apps appear in the catalogue only for the roles and teams the admin allows.
6. Effort: a few hours a week for every 20 builders.