Skip to main content
MuthoCommerce
On this page
  1. Part A — AI and automated features
  2. Part B — API, OAuth, webhook, MCP, and agent access

AI and Developer Features Policy

Version: 2026-08-03

Effective date: 3 August 2026

This Policy governs MuthoCommerce AI assistants, generated drafts, semantic search, classification, recommendations, automated workflows, APIs, OAuth applications, webhooks, MCP or agent interfaces, and related developer features. It forms part of the Merchant Terms and Acceptable Use Policy.

Part A — AI and automated features

1. AI is assistance, not authority

AI output can be inaccurate, incomplete, outdated, biased, unsafe, or similar to output produced for another user. Merchant must review the source context, factual claims, price, stock, recipient, tone, legal requirements, and likely effect before publishing, sending, or acting on output. A fluent answer is not evidence that it is correct.

MuthoCommerce AI does not replace legal, tax, financial, medical, product-safety, employment, or other professional advice. Merchant remains responsible for store content and decisions it approves.

2. Permission and confirmation boundaries

An AI feature may read only the store data and tools allowed by the authenticated user's server-enforced permissions. It must not expand permission because a prompt asks it to. A model suggestion does not authorise an action.

The following actions require clear human confirmation immediately before execution, with the target and effect shown to the user:

  • publishing or materially changing a product, price, discount, policy, domain, or public campaign;
  • sending a marketing broadcast or a message to multiple recipients;
  • cancelling or refunding an order, charging a payment, purchasing shipping, or changing inventory;
  • exporting personal data, changing staff permission, creating a credential, or connecting an external account;
  • deleting content or data, disabling a store, or changing a security setting; and
  • executing a workflow that can create a comparable financial, legal, privacy, or reputational effect.

Low-risk reversible drafts, searches, classifications, summaries, and analyses may run without per-action confirmation when the user invoked the feature. An approved workflow may execute its clearly described actions within the scope, spend limit, audience, and duration approved by the Owner. It must keep an audit trail and provide a kill switch.

3. Prohibited AI use

Merchant must not use AI features to:

  • make a solely automated decision about employment, credit, lending, insurance, housing, education admission, medical treatment, legal rights, or access to an essential service;
  • infer or target a person using health, biometric, religious, political, sexual, child, precise-location, or similarly sensitive information;
  • impersonate a real person deceptively, fabricate evidence, generate a fake review, or conceal an automated interaction when that would mislead;
  • generate or optimise unlawful discrimination, fraud, malware, credential theft, harassment, sexual exploitation, or any conduct prohibited by the AUP;
  • submit passwords, PINs, one-time codes, full payment credentials, private keys, unsupported government IDs, or data Merchant is not authorised to process; or
  • bypass a model safety control, account permission, rate limit, confirmation step, or spend control.

4. Customer-facing AI

A customer-facing assistant must identify the merchant, disclose that it is automated where a shopper could reasonably believe it is human, and offer a practical human handoff. It may provide product and order information supported by authorised store data. It must not invent availability, delivery promises, payment confirmation, refund approval, warranty, or legal terms.

If confidence or source data is insufficient, the assistant must say so and route to a human instead of guessing. Merchant must review conversation quality, escalation, and complaint handling and may not deploy AI as a barrier to a lawful human complaint.

5. AI data and model improvement

Prompts, retrieved context, output, feedback, action approvals, and safety telemetry are processed to provide and secure the invoked feature. Merchant Personal Data remains governed by the DPA. MuthoCommerce will minimise context, enforce tenant separation, and avoid sending fields unrelated to the task.

MuthoCommerce and its model subprocessors will not use Merchant Content or Merchant Personal Data to train a general-purpose model without a separate express written opt-in. The opt-in must identify the data, model recipient, purpose, benefit, retention, withdrawal method, and whether withdrawal affects a model already trained. Using a feature is not that opt-in.

Merchant must give shoppers any notice and choice required when their data is used in a customer-facing AI feature. Sensitive-data use requires express feature support, a documented necessity assessment, and any legally required consent.

6. Output rights and complaints

As between MuthoCommerce and Merchant, Merchant may use generated output subject to the agreement and third-party rights. MuthoCommerce does not promise that output is unique, copyrightable, or non-infringing. Merchant must conduct appropriate review before commercial publication.

Merchant may report a harmful or incorrect output and request human review of an AI- assisted enforcement or support decision. MuthoCommerce will preserve relevant model, prompt, source, policy-version, and approval evidence according to the incident or complaint retention schedule.

Part B — API, OAuth, webhook, MCP, and agent access

7. Credentials and scopes

API keys, OAuth client secrets, refresh tokens, webhook secrets, and agent credentials are confidential. Developers must store them server-side, encrypt them in transit and at rest, use the narrowest scopes, rotate exposed credentials, and revoke them when no longer needed. Secrets must not appear in browser code, mobile binaries, public repositories, logs, analytics, or support screenshots.

OAuth applications must use the registered redirect URI, state and PKCE where supported, display accurate app identity and scopes, and obtain affirmative merchant authorisation. An application must not misrepresent a broad scope as required when a narrower scope can perform the function.

8. Permitted data use

A developer may use API data only to provide the merchant-authorised function stated at installation. The developer must maintain an accurate privacy notice, lawful basis, security controls, rights route, retention period, and subprocessor record. It must not sell data, build unrelated advertising profiles, train a general model without a specific lawful opt-in, combine competing merchants' identifiable data, or re-identify aggregated data.

When access is revoked or the function ends, the developer must stop collection and delete merchant and shopper data within 30 days unless a specific legal duty requires a limited record. Backup copies must be isolated and expire on a documented schedule.

9. Rate limits and platform integrity

Developers must respect documented rate, concurrency, pagination, and payload limits; cache only where safe and permitted; use backoff with jitter; and avoid bulk polling when a webhook exists. Circumventing a limit, creating accounts or keys to evade it, scraping undocumented endpoints, or interfering with another tenant is prohibited.

MuthoCommerce may impose an emergency limit or revoke a credential to protect security, availability, legal compliance, or other merchants. MuthoCommerce will give the general reason and a remediation route where safe.

10. Webhooks and automated actions

Webhook delivery is at least once unless documentation expressly says otherwise. Consumers must verify the signature and timestamp before processing, reject stale or invalid messages, use a durable business idempotency key before side effects, handle out-of-order events, acknowledge promptly, and retry safely. A transport delivery is not proof that the underlying business action succeeded.

An agent or MCP client acts only with the permissions and spend/action boundaries granted by the authenticated merchant. It must show material actions for approval as required in section 2, preserve an audit trail, and never treat model text as a trusted credential or authorisation instruction.

11. Security and incident duties

A developer must notify MuthoCommerce and affected merchants without undue delay after discovering credential exposure, unauthorised access, or misuse affecting the Service or MuthoCommerce data; revoke or rotate affected credentials; preserve evidence; and cooperate with containment. Public vulnerability testing must follow the Responsible Disclosure Policy.

12. Review, suspension, and termination

MuthoCommerce may require information reasonably necessary to review security, privacy, scope, branding, and functionality. A developer must correct a curable issue within the stated period. MuthoCommerce may immediately restrict access for credential theft, data exfiltration, malicious code, deceptive consent, unlawful use, material privacy risk, or service interference. Revocation does not authorise retention of previously obtained data.

API versions and features may change. MuthoCommerce will give reasonable deprecation notice for a stable public API except for urgent security, legal, or provider changes. Preview interfaces may change without that commitment.