protected_account
Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program
The admin change targets the caller's own account or a more privileged one (403).
Meaning
An admin operation would change the status, credentials, email or username of, or
delete, the caller's own account or an account that holds, in any organization, a
privileged permission the caller lacks; changing any privileged account also needs
roles.assign. Role changes are refused the same way when they would grant or
revoke a role on the caller's own account, grant a platform role outside the main
organization, or grant a role holding a permission the caller lacks. A password, a
reset link, an email or a username is refused on a broker's linked account from every
caller: the account signs in only through its member organization.
Impact
Nothing changed. A support agent or user administrator sees this when acting on an owner, an auditor or themselves; it is the intended boundary, not an outage.
Diagnosis
Look the request id up on the Troubleshooting page. The refusal is recorded as
admin.access.denied with reason protected_account and cause own_account,
target_outranks_caller, owner_tier_required, account_linked,
platform_ or role_outranks_caller. Compare the target's roles
with the caller's (GET /); a linked account's
username begins with member:.
Mitigation
- As an administrator: ask someone whose roles cover the target's, such as an organization owner, to make the change. Changes to your own account go through another administrator or the hosted UI's self-service flows.
- As an admin-API developer: treat it as final for this caller; do not retry.
Escalation
Escalate when an owner is refused a change on an end user, or the cause does not match the roles the two accounts hold. Open an issue with the request id, the cause, both accounts' roles (role ids only) and the server version.
Problem code runbooks · Generated from internal/ in nauthera-server.