Ask Shimpz to prove authority without receiving the factor
An Action names the exact authentication mechanism, not a credential field. Shimpz completes the trusted ceremony. The password and factor metadata never enter Assistant code.
Successful assurance returns nothing; failure never returns
Declare the exact capability, auth:password, in @action(human_requests=[...]). The SDK
call returns None only after fresh, request-bound assurance succeeds. Rejection, cancellation, expiry, or an
unavailable ceremony terminates the Action automatically. The title and description are shimpz.text request copy. Local may let its
Supervisor correct a rejected password inside the same pending ceremony; the Action remains paused and receives
nothing until assurance succeeds or the request terminates.
An Action declares and issues at most one authorization request: either approval or one auth:* mechanism. Input requests remain independent. Do not add approval before authentication;
successful authentication already authorizes the exact pending Action.
See the trusted password ceremony
This is the semantic control Shimpz presents without exposing it to the Action.
Action // auth:password
Confirm the DNS change
Re-enter your Supervisor password before publishing this change.
Action publish-dns from Example Assistant v1.0.0
needs human validation. Expires in 300 seconds.
password
Use when the Supervisor must re-enter the current Supervisor password before the Action continues.
ctx.request_auth(
"password",
title=text("Confirm the DNS change"),
description=text("Re-enter your Supervisor password before publishing this change."),
)
return await publish_dns_change(change)Request only assurance a Space can prove
password- Available, using the current Supervisor password.
totp,passkey- Valid declarations that a Space cannot prove. Team stops the Action as unavailable assurance before any ceremony appears.
An unavailable assurance class fails closed; it never falls back to a weaker class. Declare password.