AI & Passport Protection
VSL treats external AI as a scoped assistant to VSL commerce services, not as the independent source of payment, ownership, fulfilment or verification truth. Commerce Passport and AI Sales Passport are separate and have different evidence boundaries.
Provider-agnostic AI connection model
VSL does not make one AI vendor the security boundary.
VSL's AI connection architecture is built around a standard VSL MCP connection and OAuth-style authorisation rather than a privileged hard-coded path for one model vendor. The VSL client/user connection, granted scopes/capabilities and seller ownership determine what an external AI can request.
- OAuth 2 and PKCE-style controls protect supported connection authorisation flows.
- Scopes and per-client capabilities limit which tools/actions an external AI can request.
- Ownership validation prevents one seller's AI connection from acting on another seller's private commerce context.
- Opaque/public references reduce the need to expose internal database IDs to external clients.
Prepared action → confirmation → execution
High-impact actions are separated from conversational text.
- An external AI asks VSL to prepare an allowed action, such as a payment request or seller-approved follow-up.
- VSL validates seller ownership, current commerce state, permitted scope/capability and required parameters.
- VSL returns a prepared-action reference rather than silently writing the financial/commercial result.
- Where confirmation is required, the user approves the prepared action and VSL issues/validates the appropriate one-time confirmation control.
- The action is executed through the existing VSL commerce bridge/service, with an idempotency key to make retries safe.
- Action/audit/security events provide evidence of what was requested, authorised and executed.
AI connection data VSL processes
VSL limits the boundary to the connection and commerce context required by the authorised tool.
| Data group | Examples | Protection objective |
|---|---|---|
| Connection identity | AI client/connection reference, user/seller owner, connection status, granted scopes/capabilities | Prove who authorised the connection and what it is authorised to do. |
| Public commerce context | Public seller identity, public catalog, currencies, public capability/evidence references | Allow discovery without exposing restricted KYC or secrets. |
| Seller instructions | AI Sales Passport: business description, tone, negotiation policy, working hours, refund/delivery preferences, pricing/language/escalation instructions | Represent seller-controlled instructions as assertions, not as provider-verified facts. |
| Prepared actions | Prepared-action reference, intended action, relevant seller-owned order/customer/payment reference, requested parameters | Separate “proposal” from “execution”. |
| Confirmation / delegation | Confirmation state/token reference, delegated limits/guardrails, pause/resume status | Enforce the user's approval boundary. |
| Audit and security | Idempotency key/reference, action audit record, security event, timing/result metadata | Trace and safely retry high-impact actions. |
AI Sales Passport vs Commerce Passport
They are intentionally not the same record.
AI Sales Passport
The AI Sales Passport contains seller-controlled selling instructions and guardrails. A seller can describe the business, preferred tone, negotiation rules, working hours, refund/delivery preferences, pricing/language rules and escalation instructions. These are primarily asserted by the seller.
Commerce Passport
The Commerce Passport is VSL's structured commercial identity/evidence view. It combines seller assertions, public seller/catalog information, VSL-observed commerce, verified integrations, verified transaction evidence and derived metrics, and identifies what is public, observed or verified rather than flattening everything into one trust badge.
Commerce truth remains in VSL services
The AI layer reads permitted data and prepares permitted actions; it does not redefine a payment or order.
- A payment is paid only when the payment system/provider verification establishes that state.
- An order belongs to the seller/customer relationship recorded by VSL; an AI text response cannot substitute ownership.
- Inventory, delivery and disputes remain in their respective VSL systems/services.
- AI actions use existing VSL commerce/payment services rather than writing directly to core financial tables.
- If current state changes between preparation and confirmation, VSL rejects the stale instruction or requires a fresh preparation before execution.
Regional AI compliance
AI controls are supplemented by jurisdiction-specific transparency and privacy requirements.
For EU/EEA users, the AI Act Article 50 transparency rules apply to covered systems from 2 August 2026. VSL clearly identifies AI interaction where the law requires that disclosure and separately classifies each AI feature instead of treating the entire platform as one regulatory category.
GDPR, UK GDPR, Nigeria's NDP Act, Kenya's DPA, Ghana's Act 843, South Africa's POPIA and Canadian privacy rules can also apply to personal data passed into or generated around an AI feature. The fact that information is sent to an AI provider does not remove VSL's need for purpose limitation, minimisation, access controls and an appropriate vendor/data-transfer assessment.
Regulatory and provider references
Primary regulator, government and provider materials used to frame this public compliance overview. External documents can change; VSL reviews the applicable source before relying on it for a launch or feature decision.