Appendix: business-layer details

What this appendix is for

From personal worker to business worker explains, in plain words, what a business must build around Claude or ChatGPT. This appendix holds the technical details behind that page. Read it when you start to build the business layer.

Terms

A few terms first. OAuth 2.1 is a standard way for an app to get permission to use a service, without sharing a password. An OAuth provider (or authorization server) issues tokens, short-lived keys that prove what a caller may do. A token has a signature that proves it is genuine. It also names an issuer (who created it) and an audience (which service it is for).

The reference technology for each requirement

Requirement	Technology in this reference design	Basis
Own identity	Better Auth as an OAuth 2.1 provider for your MCP server. Neon's Managed Better Auth issues and refreshes tokens. `createMcpAuth()` checks each token's signature, issuer and audience	Vendor-documented¹,²
Durable state	Postgres on Neon. Neon's branches let you test a worker against a copy of the data	Vendor-documented. The design is inferred
Enforced authority	Your MCP server code	The design is inferred
Human approval	A web app that uses Better Auth sign-in. A Claude artifact can display rows, but it is not where approval is recorded	The design is inferred
Audit and operations	The MCP server plus Postgres. Managed Agents also keeps each session's event history on the server	The event history is vendor-documented³

Worker identity in detail

Credentials follow a life cycle. Each worker gets its own. They are short-lived and replaced on a schedule (rotated). They are canceled (revoked) when the role changes. Every audit entry names the worker, the tenant, the approver and the approval ID. So you can answer the question: who did what, under whose authority?

An OAuth client identifies an application. It does not identify which running copy of a worker is acting. So a production server should first bind the signed-in client to an explicit worker identity. That binding includes its tenant and its authority. Only then should it allow any action. Signing a connector in as a dedicated worker account is one way to create the worker principal. On its own, it is not a security architecture. The server must also keep proposing separate from approving, and keep the tenant and approver on record for every action.

What is built in, and what you write

These tables were checked against the documentation available on November 9, 2026. Rows marked "not checked" need checking before you rely on them.

Component	Built in (documented)	You write	Checked against
Better Auth on Neon	An OAuth 2.1 authorization server. Token issuing and refreshing. Discovery and JWKS endpoints (the addresses where clients find the server's settings and its public keys). MCP client registration: client ID metadata documents are on by default, and dynamic registration is optional	Sign-in and consent pages. Scopes for each worker. The approval page	Neon's announcement of November 2, 2026¹
Token checks in the MCP server	`createMcpAuth()` in `@neon/oauth` checks each token's signature, issuer and audience. Adapters for Express, Hono, Next.js and node:http	The tools, the business rules, the approval checks, idempotency and audit logging	The same announcement
Approval page and payment rules	Nothing built in	The approval page and the payment rules from the worked example: one exact payment per approval, an expiry, separate scopes and safe retries	Design, not a product
Postgres on Neon	The database and its branches	The schema (the design of the tables), transactions and constraints	Neon docs

Runtime	How it reaches your MCP server	How approval is requested	Known limits	Status
Claude app	Connectors you add, and include in each scheduled task	Permission prompts. Desktop tasks add more (see Scheduled tasks)	Runs as you. See the limits in Scheduled tasks	Connectors for each task are documented.⁴ The connector sign-in flow was not checked
Claude Managed Agents	MCP servers listed in the agent definition	Your app sends events into a running session and can interrupt it	Beta (header `managed-agents-2026-04-01`). Not eligible for Zero Data Retention or HIPAA	Documented.³ Credential vaults are named but were not checked
Claude Agent SDK	MCP servers set up in your code	Whatever your code implements	You host and operate it	Not checked here

Runtime limits

Claude Managed Agents is in beta, and it is not eligible for Zero Data Retention or HIPAA coverage.³ Zero Data Retention is an arrangement in which Anthropic does not keep your data after a request. HIPAA is a United States law that protects health information.