Publishing without an account: how Sakupa's credential model differs from OAuth

#sakupa #mcp #ai #staticsites

I am not a Sakupa developer. I found this MCP server while looking into how AI agents publish websites, and this post is organised from public information on the official site and manual only. It is not a hands-on review.

Sakupa is an MCP server that lets an AI agent publish and operate a static site with no account registration. That sentence raises an obvious question for anyone used to the usual web: if there is no account, what proves the agent is allowed to touch your site? The answer is a credential model that works quite differently from OAuth, and it is worth understanding before judging it.

OAuth hands out scoped tokens; Sakupa hands out a key you hold

In the OAuth flow most of us know, you log in somewhere, grant scopes, and a service holds a token that can act for you until it expires or is revoked. The identity lives on the provider's side.

Sakupa skips the account entirely. There is no login, no user record on the provider's side to hold the permission. Instead, the credentials that authorise publishing are kept locally, on your own machine. The agent acts with the key you hold, not with a token a provider issued in your name. That is a deliberate trade: no account to be breached or locked, but also no "reset my password" button on a provider's site.

The key is local, so losing the machine matters

Because the credential lives locally, the recovery design has to answer a question OAuth never asks: what happens when the machine holding the key is gone? Sakupa's answer is recover, with two paths — one that uses the old device, and one that uses DNS ownership to prove the site is yours and hand it back.

That is why recover matters more here than in an account-based service. In an OAuth world you would reset a password; here, recovery is the password reset. It is the mechanism that makes "no account" workable rather than fragile.

Rotating means invalidating everything at once

The other side of a local key is rotate. When you rotate, the old credentials stop working entirely. There is no partial revocation, no per-device session list to pick from. One operation invalidates the whole set, and the new key takes over.

That all-or-nothing shape is consistent with the rest of the design: the credential is a single thing you hold, so replacing it means replacing all of it. It is simple, but it means rotation is a deliberate act, not something to do casually in the middle of other work.

Read-only first, confirm before anything changes

Before any of this touches a live site, analyze runs a read-only check: it looks at whether the site is publishable without changing anything — not the site, not the contract. And before publishing, there is a preview and a confirmation step. The agent does not publish the moment it is asked; it shows the change and waits.

This matters for a key-based model in particular. A key that can publish is powerful, so the check-before-change design is what keeps that power from firing on a vague instruction. The confirmation step is the human checkpoint in a system with no account dashboard to fall back on.

Money stays on a separate track

Pricing is public: the catalog is listed under plans, your actual contract and renewal are checked with billing, and paid plans start at ¥200 a month per site, with no automatic upgrade to a higher tier as far as the official information goes.

Payment itself never goes through the AI. The agent creates a link, and you complete the payment on Stripe's hosted page. The AI never sees a card number. So the credential that publishes your site and the money that pays for it travel on separate tracks — one local key, one hosted checkout.

What this model asks of you

A credential model without accounts asks for three things:

Keep the machine, or keep the DNS. Recovery works through the old device or through DNS ownership. Either way, you hold the proof.
Treat rotation as a full reset. rotate invalidates everything at once; there is no partial undo.
Use the confirmation step. The preview and confirmation before publishing is the checkpoint that replaces an account dashboard.

It is a design that trades the convenience of "log in anywhere" for the simplicity of "nothing about you is stored anywhere." Whether that trade is right depends on what you want from a small site — but it is a coherent trade, not an oversight.

DEV Community