Security
Principles, stated plainly
This page describes how Social Intelligence OS is designed to handle authorisation, access, external actions and evidence. It describes principles and practices — not an audit result, and not a certification. What is not claimed is set out just as clearly as what is.
Design principles
Nine areas that shape the architecture
Authorisation and credential handling
Access to a social account is obtained the way the provider intends it to be obtained, and the resulting credentials are treated as secrets.
- Social accounts are connected through each provider's own authorisation flow. The consent screen is the provider's, not ours.
- Social-platform passwords are never requested, never handled and never stored.
- Access and refresh tokens are stored encrypted, and are used only to perform the functions the user asked for.
- A connection operates only within the scopes granted to it; a capability whose scope was not granted does not operate.
- Disconnecting a connection invalidates or removes its stored credentials, and access can also be revoked from the provider's side at any time.
- Credentials are not sold, rented, shared or used for any purpose independent of providing the service.
Access control
What a person can do is a property of their role, checked where the action happens rather than only where the button is drawn.
- Role-based access control governs visibility and capability within a workspace.
- Permissions are enforced server-side at the point of action, so hiding a control is never the only thing standing between a user and an operation.
- Separation of duties can require that the person who prepares an action is not the person who authorises it.
- Membership is explicit: access to a workspace is granted, not inferred.
- Client access is scoped to the material intended for that client.
Workspace isolation
A workspace is the boundary. Content, connections, plans, approvals and reports belong to one, and do not cross into another.
- Every stored record is owned by a workspace, and access is evaluated against that ownership.
- Connected social accounts belong to the workspace that connected them.
- Reports, evidence and audit history remain within their workspace boundary.
- Cross-workspace access is not a feature; there is no mechanism intended to provide it.
Governed external actions
Actions that leave the system and become public are the ones that can cause real damage, so they are the ones held to the strictest process.
- Publishing and public replies require an explicit human authorisation from someone entitled to give it.
- An authorisation binds to the specific payload authorised; a material change invalidates it and requires a fresh authorisation.
- An approval does not override machine validation — a failed platform-level or rights-level check refuses the action regardless of who approved it.
- Publish operations are idempotent, so an ambiguous response cannot be turned into a duplicate post by a retry.
- Outbound activity is paced within each provider's rate limits.
- After an action, the provider's actual state is reconciled against what was intended.
Auditability
If it matters who did something, the record of who did it has to survive.
- Significant actions are recorded with their actor, their time and their outcome.
- Approvals record the payload approved, not merely the fact of approval.
- Publishing records include the provider's response, including failures.
- Audit records may be retained after the underlying content is deleted, because their purpose is to evidence what was authorised — this is set out in the Privacy Policy rather than left implicit.
Creator rights
Permission to use someone's work is a security property: publishing without it is an unauthorised act, whoever approved it internally.
- Rights are modelled as structured grants with a defined scope, not as free-text notes.
- Organic use and paid promotion are validated as separate scopes.
- Grants can expire and can be revoked, and both take effect on subsequent publishing.
- Rights are validated at publish time, independently of the approval workflow.
- Evidence of a grant is retained so that historical permission can be demonstrated.
Data provenance
Numbers are only meaningful when you know where they came from and how confident they are.
- Every metric carries an explicit state: available, unavailable, pending, or unsupported by that provider.
- Unavailable data is never silently treated as zero.
- The time a value was retrieved is recorded alongside the value.
- Report snapshots are immutable and carry the provenance of their evidence.
- Provenance survives export — it is present in the client-facing document, not stripped at the boundary.
Simulation honesty
Building against a simulated environment is legitimate. Presenting its output as real is not.
- Where live provider activation is unavailable, a simulated environment may be used so that workflows can be developed and tested end to end.
- Simulated and live records are distinguished structurally, not by convention.
- Simulated artefacts are labelled wherever they appear, including in exports and client reports.
- Simulated evidence is not presented as live performance evidence.
Secure development principles
The practices behind the code, stated as practices — not as an audit result.
- Secrets are held in configuration and secret storage, never in source control.
- Data is transmitted over encrypted connections.
- Input is validated at trust boundaries, and authorisation is re-checked server-side rather than assumed from the client.
- Dependencies are kept current, and known-vulnerable versions are treated as defects to fix.
- Changes are reviewed and tested before release, with automated checks in the pipeline.
- Errors are monitored so that faults are found rather than waited for.
Transparency
AI disclosure
Parts of Social Intelligence OS are AI-assisted. Where that is the case, it is stated plainly rather than presented as unexplained capability.
Social-platform content is not used by Nabil Semaan to train a general-purpose foundation model.
Where AI assists
- Transcription of spoken audio into time-coded text.
- Analysis of content — visual, audio and contextual characteristics.
- Planning suggestions and storyboarding.
- Drafting of copy, captions and replies.
- Recommendations drawn from an account's own history.
- Assistance in preparing reports.
How it is constrained
- AI output is advisory. It carries no authority of its own.
- Human authorisation is required for governed external actions such as publishing and public replies.
- An approval does not override machine validation.
AI-assisted features may rely on third-party model providers, which process content under their own applicable terms and under the configuration selected for the service. No promise is made here on behalf of a third party about how it configures its own systems.
Boundaries
What is not claimed
A security page is only useful if its limits are as legible as its claims. These statements are here so that nobody has to infer them.
- No formal security certification or attestation is claimed. This page describes design principles and practices, not an audited result.
- No claim is made to SOC 2, ISO 27001, PCI DSS or HIPAA compliance, and no such assessment has been asserted on this site.
- No claim is made to a completed third-party penetration test certification.
- No claim is made to certification under any data protection regime. The Privacy Policy describes how personal information is handled; it does not assert a certification.
- No system can be guaranteed to be completely secure, and nothing here should be read as such a guarantee.
If a formal assessment is completed in future, it will be stated here with its scope, its date and the body that carried it out — and not before.
Next step