Right now, two websites are sitting on placeholder text that reads “First Last” and “I help X achieve Y by Z.”
Go look. adriennelara.com and satchelperry.com — Lorem ipsum, a grey silhouette where a headshot goes, fake testimonials from “Jane Doe, Director of Marketing.”
The replacement is already built. A clean “domain for sale” landing page, self-tested eleven times, sitting one step from live. The agent built it. The agent verified it. The agent will not publish it.
On purpose.
Because there’s exactly one thing in this whole pipeline a human has to do — and it takes about sixty seconds. Mats is going to do it. So can you. Here’s the whole thing.
Why the agent stops at the login
The agent can build a whole website. It can write the page, upload the images, set the front page, check that the thing actually rendered. What it can’t do is log in as you.
That’s a line we drew, and we drew it on purpose. Your real password and your 2FA are yours. You don’t hand those to an agent, and you don’t paste them into a chat window. So we don’t.
There’s a second reason, and it’s the reason these two sites are stuck. Their stored password went stale. The agent could try to guess its way in — but one failed login on this fleet trips the firewall (Wordfence), and a tripped firewall can block the whole server for every site on it. So the agent refuses to guess. Good. That’s the behavior you want.
An Application Password walks around both problems at once.
What an Application Password actually is
It’s a WordPress feature — built into core since version 5.6, already on every site in the fleet. You mint a separate 24-character key tied to your user. It logs in over the API only, never through the normal login screen. So:
- The agent never sees your real password. Different key, different door.
- It never touches your 2FA. Application Passwords skip it by design.
- You can revoke it in one click — and only that key dies. Your login keeps working.
- It survives a password reset. Change your real password tomorrow; the key still works. Perfect for a fleet.
- It doesn’t trip the firewall. It uses REST Basic Auth — no login form is ever POSTed, so Wordfence never sees a failed attempt.
That’s the trick in one line: you give the agent a key you can kill, instead of the password you can’t un-share.
What you need
A blitzadmin.com login. That’s the whole list.
blitzadmin.com is the dashboard for all 198 sites in the fleet — every personal-brand site we’ve built lives there. If you can log into it, you can get into any site’s WordPress admin, which is where you mint the key. Mats has a login. (Mats Polman — Leo’s brother, our human on the fleet.) If you’re reading this and you don’t have one yet, that’s the thing to ask for first.
Mint the Application Password — step by step
Log into blitzadmin.com
This is the fleet dashboard. You’ll see the list of sites. Find the one you’re unlocking — for today, that’s adriennelara.com and satchelperry.com.
Open that site’s WordPress admin
From the dashboard, open the site’s WordPress admin (wp-admin). Straight there works too:
https://adriennelara.com/wp-admin/Log in as access@blitzmetrics.com. If that password is lost, click “Lost your password?” on the login screen, or reset it from another admin account — then come back here.
Go to your profile
In the left menu: Users → Profile. Scroll to the bottom, to the section called Application Passwords.
Name the new key
In the “New Application Password Name” box, type:
cowork-hub-publishThe name is just a label so you know what the key is for. Use the same one everywhere and future-you will thank you.
Click “Add New Application Password” and copy the value
WordPress shows you the key once, and only once. It looks like this:
xxxx xxxx xxxx xxxx xxxx xxxxCopy it now. If you close the page without copying, no harm — just delete that entry and add another. The spaces are fine; leave them in.
Hand it to the agent
Paste it into the chat with one line naming the site:
adriennelara.com app password: xxxx xxxx xxxx xxxx xxxx xxxxDo the same for satchelperry.com. That’s your last step — the agent takes it from here.
What the agent does the second you hand it over
You paste the key. Then, without you touching anything else:
- Stores the key in the local credentials file the pipeline reads — not in a saved chat log, not in this public article. Just the field named
app_passfor that site. - Connects over REST Basic Auth — the API door, not the login screen. Firewall-safe, so nothing trips Wordfence.
- Builds the landing page, drops it on a full-bleed template, and sets it as the site’s front page.
- Cache-busts and checks the live page actually rendered — it looks for the real headline, not a stale cached copy.
- Reports back: “adriennelara.com — live.” You watch Lorem ipsum turn into a real page.
“First Last.” “I help X achieve Y by Z.” Fake testimonials. A grey silhouette. The default brand template nobody ever filled in.
“Premium Domain Available.” A real inquiry form. “Domain managed by Dennis Yu.” The page the agent had ready the whole time.
How to revoke it, any time
This is why the whole thing is safe to do. You’re not making a permanent decision. You’re handing over a key you can take back in one click.
Do this once per site
That’s the model for the entire fleet. Humans don’t log in every day — the agent does. You log in once, mint one key, hand it over. From then on the agent publishes, updates, and fixes without another login from you.
So go mint the two that are waiting. adriennelara.com and satchelperry.com are one key each away from real pages. Then do it for the next two. Then the next two hundred.
Questions people ask
Is this actually safe?
Yes — safer than sharing your password. The agent never gets your real password or your 2FA, the key only works over the API, and you can revoke it in one click without affecting your login. That’s more control than a normal shared login gives you, not less.
What if the account password itself is lost?
Use “Lost your password?” on the site’s login screen, or reset it from another admin account. Once you’re into wp-admin, mint the Application Password as above. You only need the real password long enough to get in and create the key.
Does the Application Password expire?
No. It stays valid until you revoke it — and it keeps working even if you change your real account password later. That’s exactly why it’s the right tool for a fleet that rotates passwords.
Why not just give the agent the normal password?
Two reasons. One, a failed login on this fleet can trip the firewall and block the whole server for every site. Two, you’d be handing over your real credentials and 2FA with no clean way to take them back. An Application Password is revocable, scoped to the API, and firewall-safe.
Where does the agent keep the key?
In a local credentials file that only the agent’s publishing pipeline reads — never in this article, and not in a chat transcript we hang onto. If you ever want it gone, revoke it on the site and it’s dead everywhere at once.
Building in public
We document the way we work so anyone on the team can do it — and so can you. Got a site that needs unlocking, or want your own?
See how we build →Written for Mats Polman and every human who holds the key on a fleet of agent-run sites. This is a living SOP — if a step changes, we update it here.