Onboarding a new writer usually means making an account and giving it the right level of access. With a governed agent this is deliberately two steps, not one, and that split is the safety feature. The account is created at whatever your site’s default role is, and only then, as a separate approved action, does it get bumped to editor or author.
Because both halves write, this runs create-then-confirm, then a second gated promote.
I want to add [Jordan Rivera, [email protected]] as an [editor]. Do this intwo governed steps and pause between them.
First, check that no account already uses that email, then create the user. Iunderstand the account will land at the site's default role, not the role Iasked for, because create-user always uses the default. Show me the new accountonce it exists.
Then, only after I confirm, bump the role to [editor] through the separate userupdate step. I know that step needs the promote-users capability and will neverdemote the last administrator. At the end, give me the new account id and itsfinal role.Why this is safe to run
The design does the guarding for you. Creating a user always lands at the site’s default role and never a role the agent chose, so an agent cannot mint an administrator or an editor in a single call. Turning the account into an editor or author is a distinct ability behind the promote-users capability, and that role change never demotes the last administrator, so you cannot lock yourself out through it.
Both abilities stay off until you enable them, each call is checked against the capability of the user you bound the agent to, and creating a user is treated as a sensitive write in the Activity Log alongside the role change that follows. If anything looks off, the log shows you the new account id and every step taken against it.
Already connected? You do not have to paste this at all. Ask your agent for the “create an editor or author account safely” recipe, give it the name and email, and it runs the same two-step, approve-between flow on your own site.