An open-source MCP server that lets an AI agent inspect and change Cloudflare DNS, email trust records, Pages sites and cache — but only as a dry run until a human says apply — and a private agent harness around it that hands bounded jobs to small models, verifies the result, and keeps a hash-chained log. Built by a garage-door contractor who had his own site buried by stray agent deploys four times, and designed so that it cannot happen again.
Most stories about AI touching infrastructure go one of two ways. Either the agent is allowed to do nothing useful, so it is safe and pointless; or someone pastes a master API token into an environment variable, hands the agent a shell, and hopes. Cloudflare Ops MCP — now branded AMH WT, for Walrus Tusk, the mascot — is Artificial Mind Hive's attempt at a third way: the agent can see everything relevant, propose exactly what it wants to change as a before-and-after diff, and touch nothing until the owner approves. Every applied change leaves a record.
The project is open source under the MIT license and is operated by Service Pricer LLC, the same small company behind WALO and Service Pricer. Nothing Unseen shares that publisher, so this is a first-party explainer and the standard is the usual one: every claim is checkable in the public repository, the public docs and FAQ pages, the live Agent Board, or the founder's build record, and the parts that are unfinished are labeled as such. The project's own disclosure applies throughout: it is an unofficial, independent, third-party tool, not affiliated with, endorsed by, or made by Cloudflare, Inc., and the owner is responsible for every change they approve.
The WT walrus, the project's mark. Tap it to open the Walrus Tusk page on artificialmindhive.com.
The problem owners actually have
The honest way to introduce this tool is with the incident that made it necessary, because it is in the record and it is the kind of thing that happens to everyone who lets agents near production.
Artificial Mind Hive's own homepage — the blue hub at artificialmindhive.com that fronts every product the studio ships — was buried four separate times between mid-August and early September 2026. Each time, the live site silently became a different product's homepage. Each time, the cause was the same: an AI coding session, working with a broad Cloudflare token in its environment, ran a raw deploy command against the wrong project name. Not a hack, not a cron job, not a Cloudflare fault. A capable agent with a full-power credential and no gate between "I think I should deploy this" and the deploy.
The fixes tell the story of what a gate actually is. First a guard script that checked the live title every thirty minutes and could roll back to the last good deployment in seconds. Then — after the fourth burial, when the guard had seen the site go red three times in two hours but was report-only — the production branch of the Pages project was renamed so that the default deploy command lands as a preview and cannot touch the live domain at all. Then the guard was taught to auto-heal that one known-bad signature. The lesson in the founder's own notes: never tear down the old path in the same breath as a migration, and never trust a success message; verify by fetching the live page.
That is the problem in miniature. An owner who wants an AI to fix his DMARC record, update the hours on his site, or purge a cache does not want to hand it the keys to the account, and he does not want to approve every byte either. He wants to see the change before it happens, approve it in one tap, and have something check that it actually worked — and undo it if it did not.
The same owner also wants this from a phone, because his laptop is not with him on the ladder. That constraint shaped the second half of the design.
How the industry handles it today
The piece of the industry that made this possible is the Model Context Protocol. MCP is an open standard, announced by Anthropic in November 2024, that lets an AI assistant call tools over a defined schema instead of scraping a screen or improvising HTTP requests. The specification defines how a server advertises tools, how a client calls them, and how authorization works for remote servers; a public registry lists servers that anyone can connect to. Claude, ChatGPT, Grok and most coding agents now speak it. Cloudflare publishes its own Agents SDK with MCP server support and OAuth built in, and its own official MCP servers for its API, builds, bindings and docs.
What MCP does not do is decide how much power a tool should have. That is left to the server author, and the common answers are poor. The typical setup for "let the agent manage my DNS" is a Cloudflare API token in a .env file with Zone:Edit and DNS:Edit on every zone, a thin wrapper that exposes "create record / update record / delete record," and an agent prompt that says "be careful." Cloudflare's own token guidance is to scope tokens to the minimum permissions and zones needed, which helps, but scoping does not add a confirmation step, a diff, or a log.
The security community has named the failure modes. The OWASP Top 10 for LLM Applications lists prompt injection and excessive agency — giving the model more permissions, functionality or autonomy than the task needs — among its headline risks. Simon Willison's "lethal trifecta" is the sharpest statement of the exfiltration problem: an agent that has access to private data, is exposed to untrusted content, and can communicate externally will eventually be tricked into leaking the former through the latter. The NIST AI Risk Management Framework says the same thing in government prose. And the oldest rule in the book — Saltzer and Schroeder's 1975 principle of least privilege, "every program and every user of the system should operate using the least set of privileges necessary to complete the job" — predates all of it.
On the email side, the records this tool manages are governed by public standards: SPF (RFC 7208), DKIM (RFC 6376), DMARC (RFC 7489), and BIMI, the brand-logo-in-the-inbox standard maintained by the BIMI Group, which is only honored when DMARC is at enforcement. Google's sender guidelines require SPF or DKIM for all senders and SPF, DKIM and DMARC for bulk senders. These records fail quietly and cost real deliverability; they are also exactly the kind of change an owner would love to delegate and is right to be nervous about.
So the industry state is: a good protocol for calling tools, good advice about scoping tokens, a well-understood list of ways agents go wrong, and almost nothing that puts a diff and an approve button between the model and the DNS. That is the gap WT fills.
How AMH WT does it
The product has grown through two layers since its first release. The first is the MCP server itself — the Cloudflare operations tools. The second, added in August 2026 as version 0.4, is the private agent harness, which runs bounded jobs on small models with verification and an audit chain. A third layer, the hosted hub that WALO and the cloud agent crew use, grew out of the first two during October 2026 and now reports as version 0.14.1 on the docs page; the downloadable self-host Worker is 0.5.3 and the harness Worker is 0.1.4. The landing page still shows 0.4.2 in a couple of places. Those are the real numbers, and the version drift between the pages is itself part of the record.
The WT page at artificialmindhive.com/WT. The phone-only flow line under the WALO panel is the one-sentence architecture.
Scan first, show the diff, write only after approval
Every tool that reads runs immediately. Every tool that writes returns a plan and a before/after diff and writes nothing, unless the call carries an explicit apply flag — in the CLI, --apply. The FAQ states it as a rule: "Every mutating function is dry-run by default and only writes when { apply: true } is passed." Deleting a DNS record is a further step: an apply never deletes anything as a side effect, and a delete requires its own explicit confirm (CLI --force). The FAQ answer to "Does it ever delete records on its own?" is one word: "Never."
The stats as rendered on November 1, 2026: 51 built-in tools on the hub, 120 live once federated services are counted. Earlier versions of the page showed decorative numbers here; these are the real counts.
The email-trust tools, and the seven bugs
The everyday workhorse is the email set: scan a zone, plan email authentication, verify a domain, set DMARC policy, set up BIMI, configure Email Routing. The tools detect the current SPF/DKIM/DMARC/MX state, plan the minimal change, and refuse the classic footguns — chief among them creating a second SPF record, which breaks SPF entirely. DMARC updates change only the fields you asked for. BIMI setup checks DMARC first and, in apply mode, refuses to write if the policy is missing or none, because inboxes do not honor BIMI below enforcement; you can override with a force flag, and in dry-run it warns.
The record here includes a hardening pass in late August 2026 that found seven bugs serious enough to break a customer's mail or DNS, and the list is worth reproducing because it is what "safe" means in practice:
- The DMARC reader took the first TXT record at
_dmarc, so a stray verification token sitting there made the tool report "no DMARC" and then write a minimal record over a realp=reject, dropping the reporting addresses and subdomain policy. Reproduced end to end, then fixed to select by content and to refuse if two DMARC records exist. - There were no DMARC preconditions. Now the tool refuses to weaken a policy, to enforce with no reporting address, or to jump straight to reject, unless forced.
- Any connector user could change global federation and policy state, poisoning every other user. Those tools are now admin-only.
- The federation tool only checked for
https://, which allowed server-side request forgery against internal addresses. It now blocks loopback, private ranges, link-local (including the cloud metadata address), carrier-grade NAT, and embedded credentials. - A DNS content change silently un-proxied the record, publishing the origin IP and dropping the firewall. It now inherits the proxied flag and TTL from the live record.
- A Pages DNS cutover could leave a domain offline with no undo. It now snapshots and rolls back; the test deleted three records and restored three.
- Email Routing setup reported success on failure. It is now a hard stop, and the destination-verification gate fails closed.
Also from that pass: security headers on every route through a single wrapper so no handler can forget them; revocation that actually revokes (an earlier version deleted the local rows while the refresh token stayed valid at Cloudflare); and rate limiting that took three tries — a KV counter failed because KV is eventually consistent (100 concurrent reads all saw zero), the native rate-limit binding returned "allowed" every time on that account, and a Durable Object counter was exact (700 requests against a 600 limit; the first 429 at request 601). The test suite stood at 104 of 104 after that pass.
DNS, Pages, cache, Turnstile, tokens, diagnostics
Beyond email: DNS record scan, lookup, create, update, no-op detection and guarded delete; Cloudflare Pages DNS cutovers with snapshot and rollback; cache purge; Turnstile widget planning and creation for bot checks; minting of scoped, auto-expiring API tokens (which, per the record, requires a user-level parent token on the Cloudflare side — an account-scoped token cannot create tokens, and this cannot be automated around); a "who serves this domain" diagnostic that tells you whether a Worker route, a Pages project, or nothing at all is answering; and an account doctor that checks the token's real scope rather than trusting what it claims.
Patch a live site, check it, roll it back
The tool that turned WT from a DNS utility into the engine under WALO's agent crew is pages_patch, added in October 2026. It takes the live Pages deployment's file manifest, applies only the files an agent sends on top of it, re-attaches the site's server-side bundle and redirect rules from a stored copy, deploys, runs a health check against the live result — the page title, a public config endpoint, and a couple of key routes — and rolls back automatically if any check fails. It refuses to run at all if the live deployment is not the one it has a stored bundle for, which is the guard against patching on top of someone else's unsynced deploy.
The auto-rollback was first exercised in production by accident on October 15, 2026: a patch to the WALO site was pushed with the wrong expected page title, the health check on / failed, and the hub rolled the site back on its own. The founder's note on it reads, in full: "first real rollback, worked."
Git on the hub, fenced
Version 0.8 put GitHub on the hub so agents could commit, open and merge pull requests without a PC: list repos, read files, search, commit and push, open a PR, merge a PR. The fences: agents may only write to branches under an agent/ or grok/ prefix; no force pushes; no branch deletion; no edits under .github/, so an agent cannot change the workflows that run agents; and merges only on agent PRs that touch nothing in .github/. Commits are signed with the agent's name and brand so the history shows who did what.
The credential model
This is the part the current short version of this article called "the OAuth line," and it has grown.
Hosted OAuth connector. A public user never pastes a Cloudflare token into a chat. They authorize their own Cloudflare account through Cloudflare's consent screen; the access and refresh tokens stay server-side; the user receives an opaque connector key that is stored only as a SHA-256 hash and bound to that single grant. Either side can revoke. The record notes one Cloudflare-side limitation the docs are honest about: Cloudflare exposes no OAuth scope for Pages, so a connector-key user cannot touch Pages through that path.
Self-serve users. Because of that gap, the hub's join page (linked from the WT page) issues a one-tap user key, and a setup page lets the user supply their own Cloudflare token with Pages-Edit permission and, optionally, a fine-grained GitHub token. Both are verified, encrypted at rest, and stored against the user's key. User keys list and run a short set of tools — my sites, who am I, the Pages tools, the repo tools — limited to the user's own accounts and GitHub login; no federation, no admin tools, nobody else's sites.
Per-agent admin keys. The owner's own agents (Grok, Claude, Codex) each get a separate full-power key, and any one of them can be revoked alone without touching the others. The founder's rule for outside agents is the opposite: they never get a hub key at all. They join through Agent Book's own MCP front door, where they can check in, post a note and set a status, and the owner approves or bans them — "the cfops hub key can edit DNS and sites, so it must never go to outside agents."
Policy and federation. An admin can set a per-tool policy — allow, approve, or block — that is checked before every native and federated call; "approve" refuses unless the call carries an explicit approved flag. The hub can also federate other MCP servers under a namespace, so WALO's tools, the QuickBooks tools, a picture-generation tool and the PC's local tools all appear in one catalog, and a dead upstream is skipped rather than breaking the list. When an outside agent wiped a Worker through a raw execute tool in October, the fix was one policy line: block that tool. It stayed blocked.
The private agent harness
Version 0.4 added the second Worker, the AMH WT Agent Harness. The idea is bounded delegation. A front-desk agent the docs call Jack takes a job, splits it into small pieces for specialist agents, watches the limits, and reports who did what. Specialists are reusable profiles you set up once and call by name. Fourteen skill playbooks switch on automatically when a job matches: safe deploys, live checks on phone and desktop, landing-page rollback, mail loopback, lean handoffs, security review, private MCP access, research with real sources, publishing to Nothing Unseen, keeping each agent briefed on the owner's setup, catching errors early, and asking Claude for a second opinion.
What the workers cannot do is the point: no raw shell, no secrets, no browsing outside a per-job allowlist, no writes without a separate approval, no editing their own instructions. Improvements they propose are filed as candidate revisions with evidence, and nothing becomes active until a human reviews it.
Around that sit four deterministic pieces: a verified deploy gate that checks the public target for an explicit 2xx, rejects redirects, and can require an expected release marker before it will report success; zero-AI site health checks that can require an expected text marker, which catches the "200 but the wrong site" failure that buried the AMH homepage; a self-catching email loopback that exercises the real sending-and-routing path and records delivery evidence while explicitly not claiming to prove inbox placement; and alert email on state change, proven end to end in August 2026 with the first real job — a site-health watch that ran with zero AI calls and produced thirteen hash-chained audit events.
The docs page at artificialmindhive.com/wtdocs: twenty-two sections, with the safety model as section six, "the whole point."
Models, labeled honestly. The landing page's "orchestrator briefed" panel says who does what: Claude, ChatGPT (Codex), Grok or a Grok Bot app bot drives the job; Gemini helps with pictures and research; bounded steps run on Cloudflare-hosted models — a free small Llama by default, a paid Kimi K2 lane as a visible profile switch — under the same dry-run gates; and local Ollama models join from the owner's PC when it is on. If a free-tier model ran the job, the record says so. The paid lane is a switch, not a silent upgrade.
The model labeling and the version line, at phone width. The 4/7/30-day retention window for the continuity keeper is named on the page.
The audit chain and retention. Every job keeps a tamper-evident, hash-chained log in one Durable Object per user. Bulky evidence expires on a 4/7/30-day schedule; decisions and receipts are kept. The operator console shows the crew, moving progress bars, and parameters per agent and per day, behind an access key, a rotating session and CSRF protection; a read-only terminal watcher offers the same view without the operator commands.
The crew that runs from a text
The hub's inbox tools — post a task, claim it, finish it, list and cancel — plus WALO's WhatsApp bridge turned the harness into something an owner can use from a phone. The flow printed on the WT page is the whole thing: WhatsApp → WALO → one cloud agent → WT Ops MCP → checked result. The cloud agents, collectively called AMHicle, run on GitHub Actions: a job posted to the board wakes a workflow by committing a one-line file to a dispatch branch; the runner claims the task, runs the agent's own command-line tool under the owner's own subscription (Grok CLI, Claude Code, Codex — logins stored encrypted, no API keys), finishes the task, reports on WhatsApp, and hands off if another agent is better suited (three hops maximum). Agents act only through hub tools; there is no shell. Site changes get the dry run, the health check and the rollback. Quick questions take a read-only lane; site jobs take the careful lane. Each job's token spend is recorded and WALO can report it ("tasks today," "spend week").
The public Agent Board at walohq.com/board on November 1, 2026. Failed jobs are shown next to shipped ones; the counters are zero because the last day was quiet.
Two later additions are worth the record. A team vote: "everyone: draft a landing idea" sends the job to every agent, they score each other's work, and a director agent lands the best through WT with live verification — but nothing from a team job goes live until the owner texts "team go." And a live check of landed claims: when an agent's report says something is published or live, the runner reads each claimed URL from Cloudflare through the hub and appends either "Live check passed" or "Live check failed" to the WhatsApp report, handing a failure to another agent. That was added the day an agent claimed to have published a preview page and a branch that did not exist, and another agent caught it before the owner did.
When GitHub's hosted minutes ran out at the end of October, the founder added a free lane: four self-hosted runners in a Linux VM on his own PC, switchable with one repository variable, so the crew keeps running without a cloud bill. GitHub's self-hosted runner docs describe the mechanism.
Six ways to run it
The docs list six: the cfops command line on your own machine with a scoped token; WhatsApp via WALO; as a custom connector in your own AI app (Grok, Claude, ChatGPT) with a key from the join page; as a zero-dependency library in your own code; as a self-hosted MCP Worker deployed with Wrangler; and as the private agent harness behind the MCP Worker's service binding. The first and fifth need a terminal. The second needs only a phone. The third needs a phone and an AI app that supports custom MCP connectors.
The repository as of November 1, 2026: 131 commits, nine tagged releases, MIT license. The npm package named on older pages was never published; install is a clone.
Under the hood, in plain English
An owner can hold the whole system in one sentence: a messaging channel talks to an agent, the agent can only call bounded tools, the tools dry-run and wait for approval, something that is not an AI checks the live result, and everything is logged. The pieces, in the order a request passes through them:
Channel. WhatsApp (through WALO), an AI app with a custom connector, or a terminal. The owner's text is the only thing that can start a job.
Agent. One named agent per job — a cloud runner under the owner's own subscription, a Grok Bot, or a local model on the owner's PC. It has an identity, a key that can be revoked alone, and a short brief about the owner's setup. It has no shell and no credentials.
Tools. The hub is a Cloudflare Worker. It holds the Cloudflare token server-side and exposes roughly fifty built-in tools plus whatever is federated. Each call is checked against the per-tool policy, rate-limited by an exact Durable Object counter, and scoped to the caller's own accounts.
Approval. Reads run. Writes dry-run and return a diff. The write happens only with the explicit apply flag — which, for WALO users, is the owner saying yes on WhatsApp, and for a terminal user, is --apply.
Check. After a site change, deterministic HTTP checks hit the live URL: status, no redirect, expected title or marker, key routes. No model is involved in the check. A failure rolls back to the previous deployment automatically.
Log. The MCP server appends one JSON line per applied change — timestamp, action, domain, record, before, after, never the token. The harness keeps a hash-chained event log per user in a Durable Object. The Agent Board publishes the anonymized job feed. WALO keeps the chat.
Where the state lives, in plain terms: OAuth grants, hashed keys, policies, federation entries and the patch log live in Cloudflare's KV store; the per-user coordinator and the rate limiters are Durable Objects; the harness is reached from the MCP Worker over a private service binding rather than a public URL; small models run on Workers AI; alerts and the email loopback use Cloudflare's email routing; the operator console sits behind Turnstile and an access key. The cloud agents run on GitHub Actions. None of this requires the owner to run a server.
One architecture truth from the record that is easy to get wrong: a Worker on Cloudflare's edge cannot reach a model running on your laptop. The "local Ollama lane" works because a small companion program on the PC claims jobs from the board and posts results back — the Worker never calls localhost, and the docs say not to fake it.
What it costs, and what is free
The software. Open source, MIT license, free to clone and run. The repository's own license line names Service Pricer LLC / AMH.
Self-hosting. A self-hosted MCP Worker runs within Cloudflare's Workers Free plan, which allows 100,000 requests a day and 10 milliseconds of CPU per request, resetting at midnight UTC. The Workers Paid plan is a $5-a-month minimum and raises those limits; check Cloudflare's pricing page for what the free plan includes for Durable Objects and KV, which the harness uses. The record notes one model-specific cost: the paid Kimi K2 lane on Workers AI requires the paid Workers plan; the default small Llama does not.
The hosted hub. WALO users get Walrus Tusk inside WALO with nothing extra to set up; the join page issues keys with no price listed. The WT page and docs publish no price for the hosted hub, so NU states none.
Cloud agents. The crew runs on the owner's existing AI subscriptions (Grok, Claude, Codex, Gemini), not on API keys billed per token, and on GitHub Actions. GitHub's billing page lists an included monthly compute allowance for free accounts and per-minute rates beyond it; the free PC lane exists for when that runs out.
Cloudflare's services — DNS, Pages, Email Routing, Turnstile — are priced by Cloudflare; the tool adds nothing on top.
Honest limits and what is still being built
It is not a Cloudflare product. Every page says so and so does this article. If a change the tool proposes is wrong and you approve it, that is on you; the dry-run exists so you can read it first.
Pages has no OAuth scope. A hosted-connector user can read zones, write DNS, purge cache and manage routing rules, but cannot touch Pages through Cloudflare's OAuth, because Cloudflare does not offer that scope. The self-serve path works around it by taking the user's own Pages-Edit token, encrypted. That is a workaround, and the docs call it one.
The npm package was never published. Older pages said npm install cloudflare-ops-mcp; the record says the package does not exist on npm and install is a git clone. The current landing page says "git clone."
Version numbers drift across pages. Hosted hub 0.14.1, self-host Worker 0.5.3, harness 0.1.4, and a landing page that still reads 0.4.2 in its program card. The docs page is the authoritative one.
Email loopback proves routing, not inbox placement. The FAQ answer is "No" to "Does the email check prove inbox placement?" It records that the configured path delivered; it does not know what tab the mail landed in.
Tamper-evident is not tamper-proof. A hash chain lets a reader detect that a log was altered; it does not prevent the operator of the Durable Object from altering it. That is the honest scope of the claim, and it is the same scope as every append-only log that is not independently witnessed; RFC 6962 describes the stronger, witnessed version for certificate logs.
Cloud runners are bot-blocked by the owner's own zones. Cloudflare's bot protection on the AMH sites treats GitHub's runner IP ranges as bots, so cloud agents cannot fetch the owner's sites directly; they read them through the hub's own tools. This is a known limit, worked around, and worth knowing if you run the same setup.
The audit of the auto-rollback path in production is thin. It has fired for real once, correctly, on a wrong page title. It has not been deliberately failure-tested against the main AMH hub.
Jobs fail. The Agent Board shows Failed badges. Agents run out of quota (the record has Grok and Gemini both hitting usage limits in October and handing off to Claude), site checks fail, handoffs time out. The design goal is that failure rolls back and reports; it is not that failure does not happen.
Minting tokens cannot be automated. Cloudflare requires a user-level token to create tokens, so the "token vending machine" only works once an owner has made one by hand with the right permission.
One maintainer, agents as co-authors. Much of the code was written by the same AI agents the tool governs, reviewed by the founder, and the commit history shows it. The hardening pass in August found bugs that direct reading had missed and a fourteen-agent review caught — including a one-word binding mismatch that had silently killed the OAuth callback. That is an argument for the review process and an honest statement about the code's origin.
Still open on the roadmap, from the public docs and the record: server-code sites for self-serve users (planned as a GitHub Actions deploy), the automatic daily backup of agent-written content, and the local-model lane as a first-class product rather than the owner's own PC.
A 30-day playbook
For an operator who manages a few Cloudflare zones and wants an AI to help without holding the keys:
Days 1–3: Read, then scan. Read the safety model section of the docs and the FAQ. Clone the repository. Create a scoped Cloudflare token following Cloudflare's token guide — Zone Read, DNS Edit, and nothing else to start. Run the CLI's zone scan on one domain. Read the output. Do not apply anything.
Days 4–7: Plan email authentication, in monitor mode. Run the email-auth planner on the same zone. If it reports DMARC missing, approve a monitor-only policy (p=none with a reporting address) — the tool will refuse to jump to reject anyway. Watch the reports for a week before considering enforcement. Do not touch BIMI until DMARC is enforced; the tool will not let you.
Days 8–12: Pick a path. Terminal users: keep the CLI. Phone users: sign up for WALO and connect Cloudflare through the join page. App users: add WT as a custom connector in Grok, Claude or ChatGPT and say "list my sites."
Days 13–18: One site patch, with the gate. Ask for a small, visible change — a footer line, a page title fix. Read the dry-run diff. Approve. Watch the health check pass. Then deliberately ask for a change with a wrong expected title on a test project and watch it roll back. Now you know what the gate does.
Days 19–24: Policy. Set the delete tools and any execute-style tools to "approve" or "block." Set everything that writes to "approve." Leave reads on "allow." Read the audit log once a day.
Days 25–30: One agent, one job. Give one agent one bounded job — "check these three pages every hour and alert me on a change" is the canonical first one, because it runs with zero AI calls. Read its audit chain. Then decide whether the crew is for you.
Frequently asked
Can an agent change my DNS without asking? No. Every write is a dry run unless the call carries an explicit apply flag. The FAQ says so in those words.
Does it ever delete records on its own? Never. Deletes require their own explicit confirm; an apply never deletes as a side effect.
Where does my Cloudflare token live? Server-side only. The MCP server reads it from its environment, never logs it, never writes it to the audit log, and redacts anything token-shaped from error messages. Public users never supply a token at all; they authorize through Cloudflare's own consent screen.
What do public users connect with? An opaque connector key, stored only as a SHA-256 hash and bound to one OAuth grant. Either side can revoke it.
What counts as a verified deploy? An explicit 2xx from the public target, no redirect, and optionally an expected release marker on the page.
Is there an audit trail? One JSON line per applied change in the MCP server, never containing the token; a hash-chained event log per user in the harness; a public anonymized job feed on the Agent Board.
Do I need a PC? No. The WhatsApp path runs on cloud runners. The CLI and self-host paths need a terminal.
Does it need Git? No. Site changes go through Cloudflare's API directly with the dry-run, check and rollback; the GitHub tools are optional and fenced to agent branches.
Is it official Cloudflare software? No. It is independent, third-party, open-source software by AMH, operated by Service Pricer LLC, not affiliated with or endorsed by Cloudflare, Inc.
Who makes it? Austin Little, a Fremont, California garage-door contractor, under the Artificial Mind Hive name — with, the commit history shows, the AI agents the tool is built to govern.
Where to learn more
- The Agent Harness Pattern — the general design this tool implements: narrow the job, verify the result, log the action, keep approval human.
- Quote Follow-Up: Where Service Pricer and WALO Fit Together — the consumer side of the same approval-first posture, in a contractor's WhatsApp.
- Service Pricer: The Contractor SaaS Built Around Quotes, Jobs, and Real Operator Pain — the business the whole stack was built inside.
- The product pages: Walrus Tusk, the docs, the FAQ, and the public repository.
- WALO and its Agent Board; Agent Book for the agent roster and the outside-agent front door; Artificial Mind Hive for the studio; Apiary for the mirrored edition.
Sources (the record)
- AMH WT (Walrus Tusk) — public repository and README — GitHub
- AMH WT — releases — GitHub
- Walrus Tusk — product page — Artificial Mind Hive
- Walrus Tusk — documentation (safety model, credential model, six ways to run it, versions) — Artificial Mind Hive
- Walrus Tusk — FAQ (dry-run rule, deletes, token handling, audit trail, BIMI gate) — Artificial Mind Hive
- Artificial Mind Hive — studio homepage (the Walrus Tusk card) — AMH
- WALO — Agent Board (live job feed, "powered by Walrus Tusk") — WALO / AMH
- WALO — homepage (the WhatsApp crew) — WALO / AMH
- Agent Book — the outside-agent front door and roster — AMH
- Anthropic — Introducing the Model Context Protocol (Nov. 2024) — Anthropic
- Model Context Protocol — specification (2025-06-18) — modelcontextprotocol.io
- Model Context Protocol — public server registry — modelcontextprotocol.io
- Cloudflare — Agents SDK documentation — Cloudflare
- Cloudflare — Model Context Protocol in the Agents SDK — Cloudflare
- Cloudflare — Durable Objects — Cloudflare
- Cloudflare — Workers KV — Cloudflare
- Cloudflare — Service bindings — Cloudflare
- Cloudflare — Workers AI — Cloudflare
- Cloudflare — Wrangler CLI — Cloudflare
- Cloudflare — Pages rollbacks — Cloudflare
- Cloudflare — Turnstile — Cloudflare
- Cloudflare — Create an API token — Cloudflare
- Cloudflare — API token permissions reference — Cloudflare
- Cloudflare — Workers limits (Free plan: 100,000 requests/day, 10 ms CPU) — Cloudflare
- Cloudflare — Workers pricing (Paid plan $5/month minimum) — Cloudflare
- Cloudflare — Bot Fight Mode — Cloudflare
- GitHub — GitHub Actions documentation — GitHub
- GitHub — Self-hosted runners — GitHub
- GitHub — Billing for GitHub Actions — GitHub
- RFC 7208 — Sender Policy Framework (SPF) — RFC Editor
- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
- RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor
- BIMI Group — Brand Indicators for Message Identification — BIMI Group
- Google — Email sender guidelines (SPF, DKIM, DMARC requirements) — Google Workspace Admin Help
- RFC 6962 — Certificate Transparency (witnessed append-only logs) — RFC Editor
- OWASP — Top 10 for LLM Applications (prompt injection, excessive agency) — OWASP GenAI Security Project
- Simon Willison — The lethal trifecta for AI agents (June 2025) — simonwillison.net
- NIST — AI Risk Management Framework — NIST
- Saltzer & Schroeder — The Protection of Information in Computer Systems (1975; principle of least privilege) — MIT
Originally published on Nothing Unseen, an Artificial Mind Hive (AMH) site. AMH is owned by Austin Little. Product pictures are screenshots of the live sites; tap any picture to open the product.