# Appendix: business-layer details (/claude-and-chatgpt-2/architecture/appendix-business-layer-details) --- type: Document title: "Appendix: business-layer details" description: "The details behind the business layer: OAuth tokens and how the MCP server checks them, the reference technology, worker identity, what you build yourself, and runtime limits." status: stable order: 0.4925 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-09T20:42:36Z chapter: "F00A" part: Front expert_status: required concepts: [] last_verified: 2026-11-09 sources: - id: neon-better-auth title: "Managed Better Auth is now an OAuth provider, with MCP support (Neon, November 2, 2026, verified 2026-11-09)" resource: https://neon.com/blog/managed-better-auth-oauth-provider-mcp - id: better-auth-mcp title: "Better Auth MCP plugin (Better Auth, verified 2026-11-09)" resource: https://better-auth.com/docs/plugins/mcp - id: managed-agents title: "Claude Managed Agents overview (Anthropic, verified 2026-11-09)" resource: https://platform.claude.com/docs/en/managed-agents/overview - id: cloud-scheduled-tasks title: "Automate work with scheduled tasks (Anthropic, verified 2026-11-09)" resource: https://code.claude.com/docs/en/routines generated: at: 2026-11-09T20:42:36Z by: process:panaversity trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- ### What this appendix is for [From personal worker to business worker](from-personal-worker-to-business-worker.md) 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[^neon-better-auth],[^better-auth-mcp] | | 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[^managed-agents] | ### 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[^neon-better-auth] | | 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](worked-example-brightlines-payment-run-as-a-business-ai-worker.md): 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](scheduled-tasks.md)) | Runs as you. See the limits in [Scheduled tasks](scheduled-tasks.md) | Connectors for each task are documented.[^cloud-scheduled-tasks] 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.[^managed-agents] 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.[^managed-agents] **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. [^neon-better-auth]: As verified on November 9, 2026. Managed Better Auth is now an OAuth provider, with MCP support, Neon. [^better-auth-mcp]: Better Auth MCP plugin, Better Auth. [^managed-agents]: As verified on November 9, 2026. The overview covers the hosted harness and sandbox, sessions, events and beta status. Claude Managed Agents overview, Anthropic. [^cloud-scheduled-tasks]: Automate work with scheduled tasks, Anthropic.