Clerk.com
Provider-backed identity with Clerk-managed authentication and social/enterprise sign-in capabilities.
Security
Security, without the bullshit.
Neocortex has configurable authentication, data, AI and deployment controls. This page describes what is actually in the repository and separates current capabilities from future assurance work.
Authentication
Not PIN-only.
The current Neocortex platform authentication configuration exposes three provider options: Clerk.com, Microsoft Entra ID and Supabase. PIN authentication also remains supported for operator workflows. The active combination is controlled through Platform Settings.
Microsoft Entra ID
Microsoft organisational identity through the configured Entra provider.
Supabase
Supabase Auth for email/password or magic-link authentication where that provider is selected.
Current controls
What the platform can actually control.
Authentication modes
Platform Settings supports a provider-backed authentication mode as well as the existing PIN method. The exact combination enabled is a deployment setting — it is not accurate to describe Neocortex as PIN-only.
Client portal authentication
The client portal uses Supabase Auth/session handling in the current application.
Access control
Application routes and integrations are designed around explicit access checks and provider credentials rather than assuming that a browser session is trusted.
Data storage
The platform supports configurable storage architecture, with Supabase and OneDrive among the supported options depending on deployment configuration.
AI routing
AI calls can pass through the Neocortex router so providers can be selected by capability and availability rather than hard-coding one model vendor into every workflow.
AI governance
Budgets, limits, routing, context controls and human review can be applied to AI workflows. Exact controls depend on the deployment configuration.
Auditability
Operational workflows can retain structured records and activity data; retention and logging are deployment-dependent and should be mapped to the customer requirements.
Deployment choice
Neocortex is designed to run in managed cloud or customer-controlled environments, allowing architecture decisions around region, provider and operational control.
Security architecture
Security follows the data.
Identity, data classification, storage, AI providers, integrations, logs, backups and deployment location all form part of the threat model.
Identity
Provider-backed authentication, sessions, access checks and credential separation.
Data
Storage location, classification, retention, export and deletion are architecture decisions.
AI
Model/provider routing, context, tools, budgets and human approval can be controlled.
Operations
Monitoring, incident response, backups and recovery need to be configured for the target environment.
Honest boundaries
No invented certifications.
- Neocortex is not claiming a blanket SOC 2, ISO 27001 or government security certification. Compliance is deployment-, customer- and scope-specific.
- Authentication provider configuration does not automatically make every downstream integration or data store compliant with a particular regulation.
- PIN authentication remains available for operator workflows, but it should not be presented as equivalent to enterprise SSO/MFA.
- Google is not a standalone provider option in Neocortex’s current Platform Settings. Social sign-in may be available through the selected identity provider configuration, such as Clerk, but that is provider-dependent.
Go deeper
Architecture, residency, sovereignty and privacy.
The architecture reference covers Australian Government frameworks, cybersecurity standards, data residency, sovereignty, privacy and regulatory considerations.
Open ArchitectureSecurity questions
For deployment-specific security architecture, contact peterb@digitalresponse.com.au or use the contact page.