SECURITY & TRUST
Architectural, not policy.
How Shopwalk handles data, authenticates partners, and limits what agents can do on behalf of shoppers — enforced by the platform, not promised by the policy.
PRINCIPLES
What the code refuses to do.
01
Shopper data is shopper-owned
The shopper profile is fully portable, exportable, deletable, and never sold or used as collateral for partner deals. This is an architectural commitment, not a policy preference — the platform refuses to monetize shopper data and the source-of-truth boundary is enforced server-side.
02
Capability-scoped agent access
When an agent transacts on a shopper's behalf, it does so with a Macaroon-style capability token scoped to the specific action and session. The token can't be extended, can't be reused for unrelated calls, and is revoked the moment the session ends. Agents don't get blanket account access.
03
PII never leaves the platform
Real email and phone are masked at the boundary. Brands and retailers receive scoped identifiers and platform-managed communications channels. The shopper's actual contact info never touches a partner system unless the shopper explicitly grants it for a specific reason.
04
Brand authority is architecturally enforced
Brand-intent sovereignty, session scoping, and the no-paid-rank-in-organic commitments are enforced by the code path, not the contract. There is no override flag for a high-value partner. Architectural constraints are constraints because they are inviolable.
STANDARDS
Open, audited, replaceable.
Shopwalk composes well-understood standards over inventing proprietary protocols. Standard implementations get standard auditing; partners can use the same primitives on their side; nothing about the security model depends on the secrecy of Shopwalk-specific design.
Authentication for partners and shoppers. Standard implementation; no Shopwalk-specific deviations.
High-assurance OAuth profile applied on commerce transactions. Token-binding, PAR, and the additional security guarantees of the financial-grade profile.
Capability tokens for agent-on-behalf-of-shopper actions. Caveats narrow what a token can do; tokens are unforgeable but freely shareable, and intermediaries can attenuate, never amplify.
Mutual TLS between Shopwalk and enterprise partner integrations for the partner-administration surface.
TLS 1.3 on all public endpoints. HSTS preload. Strict CSP on the application surface. Standard hardening.
VULNERABILITY DISCLOSURE
If you find something.
Report security vulnerabilities directly to [email protected]. Include reproduction steps, scope, and impact. We acknowledge within one business day.
We follow standard coordinated disclosure norms. We'll work with you on a remediation timeline before any public discussion. Researchers who report responsibly are credited in our security acknowledgments unless they prefer otherwise.
We do not currently run a paid bounty program — that's likely to change once the platform is at scale. In the meantime, we'll send a thank-you in kind for substantive reports.
COMPLIANCE POSTURE
Honest about phase.
Shopwalk is in active development. We make commitments we can keep:
• GDPR + CCPA aware design. Right-to-access, right-to-erasure, and consent-revocation primitives are first-class in the architecture. Production-ready DSAR handling is in build.
• SOC 2 path planned. Type I targeted for after the first commercial cohort goes live. Type II to follow.
• No certifications claimed prematurely. We will not advertise SOC 2, ISO 27001, or any other certification until it is held. The architectural commitments above are stronger guarantees than most certifications enforce.
Questions about the security model?
Reach the engineering team directly. For partner-specific security review during integration, your account lead will coordinate.