Architecture

The honest answer to "how does oakallow actually work?" From the sign-in screen to the permission decision, here's what each request touches and where the data lives.

The shape in one line

Every oakallow request runs on a Cloudflare Worker at the edge, reads from a single shared D1 database, and returns a decision in milliseconds. No separate backend hop, no third-party in the auth path.

The surfaces

Four hostnames, four different audiences. Each one is its own Cloudflare deployment with its own auth posture.

oakallow.com
Marketing

Public landing pages. What you're reading right now. Doesn't touch customer data.

oakallow.io
Customer dashboard

The web app where teams manage orgs, tools, approval rules, billing, and members. Cloudflare Pages + Workers.

api.oakallow.io
Agent runtime

The edge worker that every governed tool call routes through. Authenticates the caller (a REST API key, or the MCP connector), resolves the permission, optionally gates on approval, deducts credits, writes the audit row.

iOS + Android
Mobile apps

Native apps for approving or denying agent actions on the go. Same APIs, same identity, same audit trail.

A request, end to end

What happens between your agent deciding to call a tool and the result coming back.

An incoming agent request hits a Cloudflare Worker at the edge. Three steps happen in one worker, in one hop: API key check via SHA-256 hash and KV lookup, 12-level policy cascade resolution in D1, and HMAC-signing of the decision (a signed receipt returned inline for every verdict). No backend round-trip.
1

Your agent calls oakallow with an API key

The request lands on the nearest Cloudflare edge, typically in the same region as your agent. The worker verifies the key against a SHA-256 hash in our database. Raw keys are never stored.
2

Permission cascade resolves, and the decision is signed

The worker walks a layered rule tree (org → tenant → resource → tool → method → tags) to decide whether the call is allowed, requires an approval, or is blocked. Because the rules live in the same database the worker reads from, there's no extra network hop. In the same step, the worker signs the decision — an HMAC-signed receipt is returned inline, for every verdict, binding the verdict to the exact request. There is no separate minting call.
3

If approval is required, humans get notified

An approval request is created and dispatched to whatever notification channels you've configured: Slack, PagerDuty, email, a webhook, or the mobile app. The agent's call is held until the request is decided or expires.
4

The signed receipt is the proof

The decision receipt the check returned is a single-use, HMAC-signed proof of what oakallow decided. It encodes the verdict, the tool, and the parameters, so it can't be re-used or re-shaped after the fact. An allowed receipt authorizes the run; a disabled receipt is the proof oakallow blocked it.
5

Your tool runs, the result comes back

For an allowed decision, your agent runs the underlying tool. The worker deducts credit for the call and writes an immutable audit row capturing the outcome.
6

Every step is queryable later

Each layer leaves a row: the signed decision, the approval lifecycle, the execution result. The Activity page on your dashboard reads exactly those rows; nothing is reconstructed or inferred.

Two ways an agent reaches the runtime

The walkthrough above follows a REST API key (oak_live_), the path your own backend uses. An AI agent can also reach the same runtime through the MCP connector at /mcp: a person-driven client (Claude, ChatGPT) authenticates with OAuth, and an autonomous agent that runs on its own uses a scoped oak_agent_ token. Whichever credential is used, the permission cascade, the approval gate, and the audit row are identical, the credential only changes who is calling.

See Agents for autonomous-agent identities and the MCP docs for the connector.

Who can sign in

Three identity paths for humans, all converging on the same session model.

Three sign-in paths (passkey, email one-time code, enterprise SSO) all converge on a single oakallow-signed session that's valid across the web app, mobile apps, and admin.

Passkey (primary)

WebAuthn on web, native passkey on iOS and Android. Face ID, Touch ID, Windows Hello, fingerprint, or a hardware key.

Email one-time code

For first sign-in, new devices, or when no passkey is enrolled. Six digits, five-minute lifetime, hashed at rest.

Enterprise SSO

Microsoft Entra today. Your IdP handles authentication and MFA; we just receive the assertion and provision the account.

Where state lives

One shared Cloudflare D1 database

All three workers (the customer dashboard, the agent runtime, and the internal admin app) read and write the same D1 database. That keeps the customer view and the runtime decision in lockstep. When you change a permission rule on the dashboard, the next agent request sees it.

Cloudflare KV holds short-lived caches (API key lookups, OAuth grants). Cloudflare R2 holds support attachments and blog media. See the Trust page for the full vendor list.

The full oakallow stack: AI agent clients (Claude, ChatGPT, Cowork) and approvers connect through Cloudflare Workers + Pages. The auth worker, dashboard, and admin app all read and write the same Cloudflare D1 policy and runtime database. API keys, auth caches, and OAuth grants live in KV.

Want to dig deeper?

The Info page collects every FAQ we've written, including the technical ones on permission resolution, signed decision receipts, and audit guarantees.

Read the full FAQ