KEYXE Security
Security, Permissions, and Accountability.
KEYXE is being designed with permission boundaries, protected access paths and clear operational reporting. We distinguish safeguards already implemented in the public website from controls planned for future live Amazon integrations.
Current safeguards and planned controls
Implemented
Current Website Safeguards
Built and covered by automated tests in the KEYXE codebase. Items that depend on production configuration say so.
- HTTPS everywhere. The site and API are designed to be served only over HTTPS on Cloudflare. Applies once deployed.
- Security headers. Content Security Policy with hashed scripts, frame-ancestors none, X-Content-Type-Options nosniff, a strict Referrer-Policy and a restrictive Permissions-Policy.
- Bot protection, verified server-side. Every form submission is checked with Cloudflare Turnstile on the server, including hostname and action. Invalid, expired or reused tokens are rejected.
- Input validation and limits. Strict schemas on client and server, 32 KiB body limit, parameterized database queries, and safe error messages without stack traces.
- Rate limiting and idempotency. Repeated submissions are limited per connection, and retries cannot create duplicate cases.
- Privacy-minded logging. Structured logs record outcomes, not content: email addresses are masked, and message bodies, tokens and IP addresses are not logged. IP addresses used for rate limiting are stored only as salted hashes and deleted daily.
- No third-party trackers. No advertising pixels or analytics scripts. Cloudflare Turnstile, on pages with forms, is the single third-party script.
- Dependency hygiene. Exact, reviewed dependency versions with a lockfile. A secret scan and a dependency vulnerability audit are part of the project’s automated checks.
- Controlled open-source export. Any future open-source release is produced by a curated export of allow-listed files into a clean folder, scanned for secrets, personal data and Amazon identifiers, and published only after a recorded human security and license review. Nothing has been published yet.
Planned — before any live Amazon data
Planned Production Controls
Required before KEYXE handles real seller or advertising data. Not live today, because no live data is handled today.
- Multi-tenant isolation. Every record and request scoped to one organization, enforced in the data layer.
- Encrypted Amazon token vault. Refresh tokens encrypted at rest with managed keys, never exposed to browsers, vendors or AI clients.
- Audit trail. Who connected, exported, approved or changed what — and when.
- Key rotation. Scheduled rotation of application secrets and encryption keys with documented procedures.
- Data lifecycle. Deletion on disconnection or revocation within the period Amazon’s policies require, plus retention limits for everything else.
- Incident response. Documented triage, containment, notification and review steps, exercised before live data is handled.
Plain statements
What we do not claim
- No SOC 2, ISO 27001 or other certification — none has been obtained.
- No independent penetration test has been performed yet.
- No HIPAA or industry-specific compliance claims.
- No Amazon certification, partnership or endorsement.
- No uptime guarantee or service-level agreement.
Amazon’s security requirements for applications that handle Amazon data go beyond a secure website. KEYXE will evaluate and implement the applicable controls before requesting production access, and will describe them here only once they are in place.