Security

sipi.bot sits in front of payment decisions, so its security posture matters. This page states what is in place today — and, just as importantly, what is not.

The model: a decision layer, not a payment processor

sipi.bot never touches card data. It receives transaction metadata — amount, merchant, category — evaluates it against your rules, and returns APPROVED, BLOCKED, or FLAGGED. All payment credentials are handled by your payment provider (Stripe, an x402 wallet, etc.) under their security perimeter. sipi.bot is the gate in front of that provider, not the provider itself.

Open source & auditable

The core rules engine is public under the MIT license at github.com/kindrat86/sipi-bot. The decision logic — what triggers a block, how velocity is counted, how rules are evaluated — is fully readable. There is no proprietary model in the decision path: the engine is deterministic.

Transport & response headers (in production now)

Every response from sipi.bot ships these headers. You can verify them yourself with curl -I https://sipi.bot/:

HeaderValue
Strict-Transport-Securitymax-age=63072000; includeSubDomains; preload
Content-Security-Policystrict default-src 'self'; scripts limited to self, Stripe, and PostHog (EU); require-trusted-types-for 'script'
X-Content-Type-Optionsnosniff
X-Frame-OptionsDENY (no clickjacking)
Referrer-Policystrict-origin-when-cross-origin
Permissions-Policycamera=(), microphone=(), geolocation=(), payment=(), usb=(), browsing-topics=(), interest-cohort=()
Cross-Origin-* COOP: same-origin, COEP: credentialless

Infrastructure

Hosted on Fly.io (single region: iad). Application state is held on an encrypted Fly volume. The public status of the underlying platform is at status.fly.io; sipi.bot's own health endpoint is documented at /status.

Self-hosting

If you self-host the MIT-licensed core, transaction data never leaves your infrastructure and none of the hosted controls above apply — you own the full security perimeter. This is the right choice for workloads with hard data-residency requirements.

What is not yet in place

We believe in stating this plainly rather than implying compliance we do not hold:

  • No SOC 2, ISO 27001, or HIPAA certification has been completed.
  • No formal third-party penetration test has been performed. The codebase is public and open to community review, but that is not equivalent to a paid pentest.
  • No published vulnerability-disclosure policy (VDP) or bug bounty. If you find a security issue, please report it responsibly to sales@sipiteno.com.
  • No SSO/SAML for the hosted dashboard.

Reporting a vulnerability

Email sales@sipiteno.com with details and reproduction steps. For sensitive reports, you may also open a private security advisory on the GitHub repository. We acknowledge reports within two business days.

For procurement and security questionnaires, contact sales@sipiteno.com.

← Back to sipi.bot