Ingen SOC 2-, ISO 27001- eller annan certifiering finns.
Säkerhet
Isolering och verifierat arbete, i konstruktionen.
Den här sidan beskriver hur plattformen faktiskt är byggd: databasgränsen, sessionsgränsen, byggsandlådan, betalvägen och exportvägen. Den listar inga certifieringar eller revisioner, eftersom inga finns.
Tenantisolering i databasen
Isoleringen upprätthålls där datan bor, inte bara i applikationskoden.
- Varje tenantkänslig tabell har en organisationsägare (organization_id eller motsvarande tenancygräns) med sammansatt ägarskap till projekt.
- Row-level security är påtvingad för tenanttabeller, och runtime-rollerna är snäva: identitetsrollen kan inte läsa projekt- eller plånbokdata, och gränsen avvisar PostgreSQL-administrativa roller, superuser-roller och roller med fil- eller serverbehörighet.
- Tenantkontext sätts per transaktion. En identifierare som kommer från en webbläsare är en begäran, aldrig en behörighet.
- Skyddade skrivningar går genom funktioner som självständigt verifierar session och aktuell behörighet, och direkta skrivningar från applikationsroller är återkallade för dessa tabeller.
Sessioner och aktuell behörighet
Autentisering kontrolleras vid ingången, och behörigheten kontrolleras om i stunden den används.
- Sessionscookies är HttpOnly och SameSite=Lax, __Host-prefixade i produktion, och varje anrop kopplar sessionen till en användare och en tenant innan något annat sker.
- Webbläsaranrop som ändrar något måste komma från den konfigurerade originen, och bodyn är begränsad (application/json, 16 KiB, fem sekunders tidsgräns).
- Känsliga ändringar — MFA, utfärdande av nycklar, köp, planbyten — kräver färsk autentisering i stället för en långlivad session.
- MFA är TOTP med engångs-återställningskoder. Tokens och koder förbrukas atomiskt, så två samtidiga användningar kan inte båda lyckas.
Nycklar och åtgärdsgodkännanden
En nyckel är ett avgränsat, återkalleligt bemyndigande — inte en stående nyckel till plattformen.
- API- och MCP-nycklar hashas i vila, binds till en organisation, ett varumärke och ett projekt, har explicita scopes och begränsad livstid, och visas exakt en gång.
- Om någon tas bort från ett team återkallas personens nycklar permanent, och en återställd lösenordshändelse ogiltigförklarar nycklar som utfärdats tidigare.
- Känsliga och fakturerbara åtgärder kräver ett kortlivat godkännande bundet till användare, organisation, projekt, exakt åtgärd, mål och inputens kanoniska digest.
- Förbrukning av godkännandet, admission av jobbet, creditreservation, revision och outbox-post committas i en enda transaktion; om det betrodda callbacket misslyckas rullas hela admissionen tillbaka. Ändrade roller eller medlemskap återkallar permanent väntande godkännanden.
Byggen körs isolerat
Kundens och AI:ns kod behandlas som otillförlitlig, eftersom den är det.
- Byggen körs i en tillfällig container på en minimal basbild med nätverket avstängt, tak för minne och CPU, processgräns, read-only filsystem, en begränsad noexec-tmpfs, ingen Docker-socket och inga produktionsnycklar, under en tidsgräns.
- En artefakt måste klara digest- och storleksverifiering och skrivas genom ett atomiskt lager — skriv, flusha, läs tillbaka, atomisk rename, läs tillbaka igen — innan ett byggkvitto registreras. En krasch kan därför aldrig lämna ett klart-läge utan varaktiga bytes.
- Bygg- och artefaktkvitton är append-only; en uppdatering eller radering utlöser ett oföränderlighetsfel.
- En arbetare håller ett fencat lån, förnyar det medan den arbetar och stoppar om den tappar ägarskapet. Käll- och arkivgränser (1000 poster, 256 KB per fil, 16 MB totalt) tillämpas både in och ut.
- Filinnehåll levereras till webbläsaren som escapad text: uppmärkning i en sparad fil förblir inert och körs aldrig.
Betalningar verifierade från signerade händelser
Pengar rör sig bara när leverantören säger det — och plattformen kan bevisa det.
- Betalwebhooks verifieras med riktig signaturkontroll över den begränsade råa requestkroppen, med replay- och tidskontroller och exakt konto- och test/live-omfattning. Endpointen bekräftar bara varaktigt mottagande.
- Credits blir ett saldo först efter att betalningen verifierats mot leverantören — faktura, payment intent och charge — och en grant tillämpas exakt en gång.
- Priser tas aldrig från en webbläsare: belopp och creditenheter kommer från en server-side-katalog, och ett pris som inte matchar förväntad produkt, belopp, valuta och cykel avvisas.
EU-hosting och dokumenterad härdning
Vad som är sant idag, inklusive det som inte är färdigt.
- Servrarna står i EU och hanteras av plattformen. Kunder får aldrig en leverantörspanel; allt går genom Hostingsurge.
- På produktionsservern installerades väntande OS-uppdateringar (inklusive säkerhetsuppdateringar), brandväggen aktiverades med bevarad SSH, HTTP, HTTPS och HTTP/3, och reverse-proxyns administrationsbindning begränsades till localhost och verifierades efter omstart.
- Trafiken terminerar genom TLS och en härdad proxy; administrationsgränssnitt exponeras inte mot internet.
- Kontrolldatabasen säkerhetskopieras varje natt på servern; extern lagring av backuper är inte aktiverad ännu, och det sägs här i stället för att antydas.
Vad denna sida inte påstår
Sagt rakt ut, eftersom en säkerhetssida som överdriver är sämre än ingen alls.
Ingen oberoende säkerhetsrevision har genomförts.
Ingen tredjepartsrapport från penetrationstest finns.
Ingen drifttids-SLA och inget bug bounty-program erbjuds.
Ingen adress för säkerhetsrapportering är publicerad ännu. Fram till dess har ett fynd ingen bekräftad kanal — och sidan kommer att namnge en när den finns.
Läs gränsen, besluta sedan.
Utvecklarsidan dokumenterar de verkliga endpointerna och deras autentisering. Dokumentationssidan anger vad som är implementerat modul för modul.
Allt ovan beskriver den aktuella versionen. Ingen certifiering, revision eller SLA påstås någonstans på denna sajt.