Read-only by design
SOC360.AI aggregates, correlates and reports. Integrations pull findings and telemetry; the platform does not push changes, run scans, patch systems or execute response actions in your tools.
Platform security
You are trusting us with your security data. Here is how we protect it.
SOC360.AI sits on top of the tools you already run. That makes trust structural, not cosmetic: we hold findings, posture and exposure data for your whole estate. This page explains how the platform and the code behind it are built, and what guarantees follow from that design.
How the platform is built
Six architectural properties that limit blast radius by construction.
Per-tenant isolation
Every record is scoped to an account and an organization. Isolation is enforced in the database with row-level security policies, not only in application code, so a query can only ever return data the signed-in user's tenant owns.
Least-privilege access
Roles are account admin, power user and read-only. Roles are stored separately from user profiles and evaluated server-side, so privileges cannot be changed from the browser.
Vaulted connector credentials
API tokens and connector secrets are stored in a private, restricted table that application queries cannot read back. They are used only server-side during a sync and are never returned to the browser or included in exports.
Server-side data access
Ingestion, report generation, exports and AI features run in server functions. Third-party endpoints are called from the server, so customer credentials and raw responses never transit the browser.
Audit logging
Administrative actions — customer creation and deletion, data flushes, exports and configuration changes — are written to a tenant-scoped audit log you can review at any time.
How the code is kept safe
Secure engineering process
Changes ship through version-controlled builds with automated type checking and linting. Every release is reproducible and revertible, and the running version can be rolled back if a defect is found.
Continuous security review
The codebase and database policies are scanned for common weaknesses — missing row-level security, over-permissive grants, exposed secrets and vulnerable dependencies — and findings are remediated before release.
Transport security
The application and all its APIs are served over HTTPS. Outbound connector calls use TLS, with certificate verification configurable per connector for self-hosted intelligence sources.
Data portability and deletion
Customers can export their tenant data as structured JSON or CSV at any time, and can delete a customer environment or flush demo data with an explicit confirmation step.
Operating practices
- Authentication and session handling are provided by the managed identity layer; passwords are never stored by the application.
- Secrets and API keys live in server-side secret storage; they are not embedded in client code or in the repository.
- Ingestion writes normalised records only — no shell execution, no dynamic code evaluation on ingested content.
- Public API endpoints for webhooks verify a shared secret or signature before any data is processed.
- Exports and backups redact tokens, credentials and other secret material.
- Demo data is tagged and isolated from live telemetry so reporting cannot mix the two.
Responsible disclosure
If you believe you have found a security issue in SOC360.AI, email security@soc360.ai with steps to reproduce and any supporting detail. Please do not test against other customers' tenants or access data that is not yours. We will acknowledge your report and keep you updated while we investigate.
Scope of this page
This page describes how SOC360.AI is designed, built and operated. It is not a certification, audit report or legal warranty, and it does not assert compliance with any specific standard or regulation. Customers evaluating SOC360.AI for a regulated environment should request our current documentation and contractual terms directly so claims can be reviewed against evidence.