Remove repetitive internal approval friction when an action is already within the Architect's standing authorization, while preserving real external authentication, identity, legal, financial and security boundaries.
Core rule
AUTHENTICATION != AUTHORIZATION.
The Architect's standing authorization may remove repeated internal confirmation prompts, but it does not fabricate login state, bypass an external service's authentication, defeat MFA/CAPTCHA, accept legal terms on the Architect's behalf, falsify KYC/KYB, obtain credentials without consent, or override a platform's security controls.
Standing authorization classes
AUTO_STANDING:
public-source research;
read-only monitoring;
drafting and editing owned materials;
publishing approved factual material to an already-authenticated owned account when the platform permits automation;
non-binding official application preparation;
non-binding form submission when the account is already authenticated, all required factual fields are verified, and no signature/attestation/payment/regulated declaration is required;
routine reversible configuration of owned automation within existing permissions;
evidence capture and audit logging.
ONE_TIME_BINDING:
first connection of an external account through OAuth/API token/session;
MFA or passkey challenge;
first-time platform consent screen;
refresh-token renewal when the provider requires re-consent.
After a valid binding exists, agents should reuse the authorized session/token within its granted scope and must not ask the Architect to approve each routine action again.
HUMAN_REQUIRED:
KYC/KYB identity attestations;
accepting or materially changing binding Terms of Service;
electronic/legal signatures;
notarization;
sworn statements;
representation as licensed counsel;
payment, paid advertising spend, listing fees or other financial commitments;
irreversible account deletion or transfer of ownership;
disclosure of secrets/private keys.
DENY:
bypassing MFA/CAPTCHA or access controls;
credential theft, phishing, session hijacking or cookie theft;
impersonation;
unauthorized account creation or use;
fake KYC/KYB;
evasion of platform suspension or legal restrictions;
spam/astroturfing/vote manipulation;
market manipulation.
Resolution algorithm
Identify the requested service and action.
Check whether a valid connector/session/token is already bound.
Classify action as AUTO_STANDING / ONE_TIME_BINDING / HUMAN_REQUIRED / DENY.
If AUTO_STANDING and binding exists: execute without asking for redundant approval.
If ONE_TIME_BINDING: create one explicit binding task containing service, requested scopes, provider URL and reason. After successful binding, persist only the provider-issued credential in the platform secret store, never source code or chat.
If HUMAN_REQUIRED: stop only at the exact human action, keeping all preparation complete.
If DENY: do not attempt a workaround that defeats the provider's controls.
Record an audit receipt: service, action, decision, evidence, timestamp, connector state and result.
Publication rule
A draft is not a publication. A prepared exchange application is not submitted. A submission is not a listing. Record external evidence before changing status.
Security rule
Tokens, passwords, passkeys, session cookies, seed phrases and private keys must never be written to public Val Town code, GitHub, logs, campaign text or audit payloads. Use encrypted environment/connector secret storage only.