Freelance Platform Authorization

Create the narrowest lawful account binding that lets the freelance team research, prepare, and—only where the platform permits—submit routine non-binding work actions without repeated internal approval.

Owner authorization is necessary but does not override provider authentication, platform Terms, identity rules, KYC, payment rules, or regulated obligations.

Use the safest supported route in this order:

1. Official platform team/agency delegation.
2. Official API/OAuth token with least privilege.
3. Owner-controlled persistent browser context created after one-time login.
4. Human action gate when none of the above permits delegation/automation.

Never use password sharing or session theft as an authorization method.

1. Confirm the service and intended actions.
2. Read the current platform policy/Terms source recorded in PLATFORM-POLICY.json and re-check when stale or materially changed.
3. Classify requested actions as:
   • AUTO_STANDING: public research, drafting, estimation, QA, internal preparation.
   • BOUND_AND_PLATFORM_PERMITTED: routine authenticated actions explicitly allowed by the platform/account model.
   • HUMAN_REQUIRED: identity/KYC, binding acceptance, financial instructions, tax forms, payment withdrawal, legal signatures, dispute settlement, account ownership changes.
   • DENY: credential sharing/theft, MFA/CAPTCHA bypass, fake identity, fabricated portfolio/reviews, fake hours, spam, off-platform payment evasion, multiple-account abuse.
4. For browser binding, require the owner to complete provider login/MFA once in the secure live session.
5. Persist only the browser context identifier; never write passwords, cookies, MFA codes, recovery codes, payment credentials, seed phrases, or private keys into public code or logs.
6. Mark a service BOUND only after an actual persistent context exists.
7. Reuse the context until the provider expires/revokes it; then request one-time re-authentication.

Prefer Agency/Team permissions or official API where available. Do not share the owner's password. Do not misrepresent who performed work, falsify hours/work, or evade required platform communication/payment rules. If a proposal/bid action is not clearly permitted to be automated/delegated, prepare it fully and stop at the platform-permitted human/team-member submission gate.

Use truthful person/entity identity only. No account sharing, false identity, multiple-account abuse, fake reviews, or misrepresentation of who provides the service. Agents may prepare gigs, offers, messages, assets and delivery work; authenticated posting/acceptance must follow Fiverr's current permitted account model.

Do not infer permission from technical accessibility. Re-check current provider Terms and use official delegation/API mechanisms where available. If delegation/automation permission is unclear, use HUMAN_REQUIRED_FOR_ACCOUNT_ACTION while keeping all research/drafting/delivery automation active.

A job discovery is not a win. A submitted proposal is not a contract. A contract is not revenue. Revenue is verified only from attributable platform/payment evidence.

Preferred treasury flow: PLATFORM PAYMENT -> CAPITAL CORE RECONCILIATION -> FEES/TAX/RESERVES -> OPERATING BUDGET -> APPROVED TREASURY ALLOCATION.

No autonomous withdrawal, crypto conversion, wallet signing, or value transfer.

For every binding or account action record:

• service;
• route (TEAM, OAUTH_API, PERSISTENT_BROWSER, HUMAN_GATE);
• account binding state;
• exact action class;
• platform policy source/date;
• execution result;
• receipt/message/job/proposal identifier when available;
• human gates encountered;
• no-secret-exposure check.

Use only:

• BOUND
• UNBOUND
• PARTIAL
• HUMAN_GATE
• BLOCKED_PLATFORM_POLICY
• REVOKED

Never claim successful authorization because a connection page merely exists.