How AI Agents Provision Their Own Infrastructure: A Deep Dive into Zero-Human MCP Onboarding

## The Problem: Every MCP Server Needs Credentials When a developer installs an [MCP](https://ainative.studio/mcp-discoverability) server that requires a backend service, there is an invisible UX wall: they must create an account, generate an API key, copy it into a config file, and restart their agent. Each of these steps has a failure mode. Most developers bounce before they complete the flow. We built **zerodb-sequential-thinking-mcp** to eliminate this wall entirely. The first time an agent runs the server, it provisions a [ZeroDB](https://ainative.studio/agent-memory-api) account automatically — no browser, no signup form, no manual key copy-paste. The agent gets credentials in ~800ms and starts working. The human gets an email to claim the account later, if they want to. This is the technical deep dive into how that works. --- ## The Provisioning Endpoint The entry point is a zero-auth REST endpoint: ``` POST /api/v1/public/instant-db ``` No authentication required. The endpoint is rate-limited by IP (5 requests per hour) and creates a temporary ZeroDB account with a 7-day TTL. Here is what it does internally: ```python @router.post("/instant-db") async def create_instant_db(request: Request, db: Session = Depends(get_db)): ip = request.client.host check_rate_limit(ip, db) # 5/hour per IP temp_user_id = uuid4() temp_email = f"tmp_{temp_user_id.hex[:12]}@instant.zerodb.io" workspace_id = uuid4() project_id = uuid4() claim_token = secrets.token_urlsafe(24) claim_hash = hashlib.sha256(claim_token.encode()).hexdigest() api_key = f"tmp_{secrets.token_urlsafe(32)}" # creates user, workspace, project, stores claim hash return { "api_key": api_key, "project_id": str(project_id), "claim_url": f"https://ainative.studio/claim?token={claim_token}&project={project_id}", "expires_in": "7 days" } ``` The critical detail: we store the **SHA-256 hash** of the claim token, never the raw token. The raw token lives only in the claim URL. This is the same pattern used by password reset flows — the server cannot reconstruct the original token from what it stores. --- ## The provision.js Decision Tree The MCP server's boot sequence runs `provision()` before accepting any tool calls. Here is the full decision tree: ``` START │ ├─ ZERODB_API_KEY env var set? │ YES → use it, skip provisioning │ NO ↓ │ ├─ ~/.zerodb/credentials.json exists? │ NO → call /api/v1/public/instant-db, write credentials, print banner │ YES ↓ │ ├─ credentials.claimed == true? │ YES → load api_key from file, done │ NO ↓ │ ├─ credentials.expires_at > now? │ NO → credentials expired, re-provision (new tmp account) │ YES → load api_key from file, done │ END ``` The env var override is the escape hatch for CI environments, Docker containers, and users who already have ZeroDB accounts. Setting `ZERODB_API_KEY` in the MCP config completely bypasses provisioning. --- ## Atomic Credential Write Writing credentials has a subtle failure mode: if the process crashes mid-write, you get a corrupted file. On next boot, JSON.parse throws, and the server errors before the agent can do anything useful. We solve this with the write-to-temp-then-rename pattern, which is POSIX-atomic: ```javascript async function writeCredentials(creds) { const dir = credentialsDir(); await fs.mkdir(dir, { recursive: true }); const tmp = credentialsPath() + '.tmp'; await fs.writeFile(tmp, JSON.stringify(creds, null, 2), 'utf8'); await fs.rename(tmp, credentialsPath()); // atomic on POSIX } ``` `fs.rename()` is a single syscall on Linux/macOS when source and destination are on the same filesystem. The file either contains the old content or the new content — never a partial write. This matters because MCP servers can be killed at any point (timeout, SIGTERM from the agent runtime, OS reaping). --- ## Credential Lifecycle: Three States A provisioned credential moves through three states: | State | claimed | expires_at | Behavior | |-------|---------|------------|----------| | **Temporary** | false | 7 days from creation | Loaded from file on each boot | | **Claimed** | true | null (permanent) | User owns the account, never expires | | **Expired** | false | Past | Re-provisions on next boot | The claim flow: 1. User receives email with claim URL 2. They click it, log in at `www.ainative.studio/claim` 3. Backend validates the raw token against the stored hash, reassigns the project to their real account, issues a permanent `zdb_live_` key 4. MCP server marks `credentials.claimed = true` on next boot --- ## Soft Email Capture After provisioning, we fire a single non-blocking request to capture the user's email: ```javascript // In provision.js — fire and forget if (!credentials.email_sent) { setEmail().catch(() => {}); // never throws, never blocks } ``` The server prints one line to stderr (agent console, not tool results): ``` [ZeroDB] Set ZERODB_EMAIL=you@example.com to receive your account claim link ``` If the user sets `ZERODB_EMAIL` before the next boot, the server calls: ``` POST /api/v1/public/instant-db/send-claim-email { "project_id": "...", "email": "you@example.com" } ``` Rate-limited to 1 email per project. The MCP server works perfectly without ever collecting an email — provisioning is not gated on it. --- ## Multi-Agent Shared Projects One provisioned account can be shared across an entire [agent swarm](https://ainative.studio/agent-swarm) via `ZERODB_CONFIG_DIR`: ```json { "agent-alpha": { "command": "npx", "args": ["-y", "zerodb-sequential-thinking-mcp"], "env": { "ZERODB_CONFIG_DIR": "/shared/zerodb", "ZERODB_PROJECT_ID": "e4f3d95f-593f-4ae6-9017-24bff5f72c5e" } }, "agent-beta": { "command": "npx", "args": ["-y", "zerodb-sequential-thinking-mcp"], "env": { "ZERODB_CONFIG_DIR": "/shared/zerodb", "ZERODB_PROJECT_ID": "e4f3d95f-593f-4ae6-9017-24bff5f72c5e" } } } ``` Both agents read from the same credentials file. Because `writeCredentials()` is atomic, concurrent writes are safe. The shared `ZERODB_PROJECT_ID` means their sequential thinking chains and plan artifacts are visible to each other. --- ## Cross-Session Reasoning with Plan Artifacts The most powerful consequence of persistent credentials is cross-session reasoning. When an agent concludes a thinking chain, it writes a plan artifact to ZeroDB: ```javascript async function concludeChain(chainId, conclusion, client) { const chain = getChain(chainId); const artifact = await client.post('/api/v1/public/memory/v2/plan/', { title: `Reasoning chain ${chainId}`, content: formatChain(chain, conclusion), tags: ['sequential-thinking', chainId] }); return { artifact_id: artifact.id, resume_hint: `Use sequential_resume with artifact_id="${artifact.id}" to continue in a future session` }; } ``` A different agent — or the same agent in a different session — resumes: ```javascript async function resumeChain(artifactId, client) { const artifact = await client.get(`/api/v1/public/memory/v2/plan/${artifactId}`); return { prior_reasoning: artifact.content, step_count: artifact.metadata?.step_count ?? 0 }; } ``` The `artifact_id` is stable across sessions, machines, and agent restarts. Agent A does research, concludes with an artifact_id, hands it to Agent B in a different process that resumes from the same chain. --- ## Security Model **Single-use hash tokens.** The claim token is `secrets.token_urlsafe(24)` (144 bits of entropy), stored only as SHA-256. An attacker who reads the database cannot reconstruct any claim URL. **IP rate limits on provisioning.** Five requests per IP per hour, enforced at the DB layer so it survives server restarts. **Terms acceptance audit.** Every provisioned account records `ip_address` and `terms_accepted_at`. Temporary accounts are purged after 7 days — unclaimed accounts do not accumulate indefinitely. --- ## What This Pattern Enables Agent self-provisioning changes the distribution model for developer tools: - **Zero friction installs.** `npx zerodb-sequential-thinking-mcp` works immediately, no account required. - **Organic growth.** Every `npx` install that hits a new IP creates a new ZeroDB account. The MCP package IS the top-of-funnel. - **Claim conversion.** Users who find the tool valuable claim their account. Unclaimed expirations are a signal, not a loss. - **Enterprise override.** Teams set `ZERODB_API_KEY` and bypass provisioning entirely. The pattern works for any MCP server that wraps a backend service. The provisioning endpoint, credential file, and claim flow are all reusable primitives. --- ## Try It ```bash npx zerodb-sequential-thinking-mcp ``` The first run provisions your account. The second run is silent. Your thinking chains persist across sessions. Source: [github.com/AINative-Studio/zerodb-sequential-thinking-mcp](https://github.com/AINative-Studio/zerodb-sequential-thinking-mcp) Docs: [docs.ainative.studio](https://docs.ainative.studio)

How AI Agents Provision Their Own Infrastructure: A Deep Dive into Zero-Human MCP Onboarding

Check your site's AX Score