Security built in, not bolted on.
GreenLightOS handles creative IP, professional identity, and audience data. Here is exactly how we protect it — with specific controls, not vague assurances.
Safeguards help protect your work. Security considerations
Access controls, logging and provider safeguards reduce risk, but no internet-based service can guarantee absolute security. Keep independent copies of important work.
The Privacy Policy explains authorised access, provider handling and your rights. These safeguards do not replace our obligations under applicable law.
Your credentials are protected at every layer.
Passwords are hashed using bcrypt with 12 rounds — a deliberate work factor that makes brute-force attacks computationally expensive. Two-factor authentication (TOTP) secrets are encrypted using AES-256-GCM before storage. Sessions use 32-byte cryptographically secure IDs, delivered via HttpOnly, Secure, SameSite=Lax cookies — inaccessible to client-side scripts.
- Passwords hashed with bcrypt-12 — never stored in recoverable form
- TOTP 2FA secrets encrypted with AES-256-GCM before database storage
- Sessions: 32-byte cryptographic IDs, 7-day TTL, HttpOnly + Secure cookies
- Secure token exchange for mobile clients via OIDC code flow
The right people see the right things. Nothing more.
Access is controlled at multiple levels. Role-based access control (RBAC) enforces which actions each user type can perform — audience, creator, and admin roles are checked at every protected endpoint. Storage objects carry object-level ACLs with explicit read/write permissions tied to owner identity. Admin routes are protected by a belt-and-suspenders global guard that validates platform role before any admin logic runs.
- RBAC enforced via middleware on every protected route (audience / creator / admin)
- Object-level ACLs on cloud storage — owner-scoped read/write with public/private visibility
- Global admin guard: platform role validated before any admin endpoint responds
- Server-controlled role assignment is designed to prevent privilege escalation
Layered controls protect API boundaries.
Schema validation, access checks, throttling and defensive HTTP headers reduce risks at API boundaries. Limits and configuration differ by endpoint and environment; no input validator or header guarantees that every attack is prevented. These controls are safeguards, not a certification that all requests are sandboxed or all vulnerabilities eliminated.
- Schema validation at protected API input boundaries rejects malformed data before business logic
- Global rate limit: 100 req/min per client
- Auth throttle: 10 failed attempts per 15 min per IP, with exponential back-off + Retry-After
- Helmet enforces CSP, X-Frame-Options: DENY, and other defensive headers
- CORS is restricted to approved application origins
Privacy controls reduce unnecessary disclosure.
Audience responses are aggregated or de-identified before creators see them. Request-log redaction reduces the risk of credentials appearing in logs; it is not a guarantee that logs can never contain personal data. GreenLightOS.ai does not itself train or fine-tune models on writing without specific consent. The Privacy Policy's provider register explains implemented AI/storage routes and the limits of verified training, retention and human-review assurances.
- Audience results limit disclosure of respondent identity
- Pino log redaction: Authorization and Cookie headers stripped from all request logs
- Private-by-default creative content; provider handling and verification limits are disclosed
- No third-party advertising trackers or data brokers
Every significant action leaves a trail.
All admin actions — approvals, bans, role changes, IP blocks — are written to a persistent audit log table capturing the actor ID, target entity, action type, IP address, and metadata. A real-time in-memory ring buffer tracks the last 10,000 requests and 1,000 errors for health monitoring and anomaly detection. Structured JSON logging via Pino provides machine-readable records across the API.
- Admin audit log table: actor, target, action, IP, timestamp on every admin action
- Real-time request ring buffer: last 10,000 requests + 1,000 errors in memory
- Structured Pino logging — consistent, machine-readable records across all services
- Anomaly detection hooks for unusual traffic patterns
Report integrity you can verify yourself.
Where enabled and confirmed for a particular report, a SHA-256 hash can be recorded on Base for tamper-evident integrity verification. A locally generated hash is not proof of a successful on-chain transaction. Source writing and private report contents are not intentionally published on-chain. The proof does not establish authorship, copyright, accuracy or commercial value.
- Eligible reports can carry a hash with separately verified on-chain status
- Tamper-evident: any post-publication change invalidates the hash
- Independently verifiable by anyone with the report and the on-chain record
- A confirmed transaction timestamps a recorded hash, not independently proven authorship or creation time
Responsible Disclosure
If you discover a security vulnerability in GreenLightOS, please report it directly to us. We aim to acknowledge reports promptly, investigate responsibly, and keep good-faith researchers informed. We do not pursue legal action against researchers who avoid privacy violations, disruption, and data destruction while disclosing in good faith.
hello@greenlightos.ai