Security you can inspect
People, workloads, data and AI each get only the access the job needs, and what they do is recorded.
Architecture
Built to be trusted, and to prove it.
Most vendors say their software is secure. We would rather show you. This page explains how Neocortex is put together, the standards we design against, and the evidence you can ask to see.
Data handled on purpose
We decide what data is, where it lives and how long it stays before any system touches it.
Control over where and who
You choose the region, the provider and who holds the keys, then we show you the evidence that it holds.
Fourteen domains
The things we think about before we write a line of code.
Not just the application. Each column builds on the one before, so the shade deepens as we move from why we are building something to how we prove it is safe.
Purpose
What is this for?
Business and operating model
We start with what the organisation is trying to achieve: its capabilities, who owns what, how much risk is acceptable and how success will be measured.
Experience and service
Real journeys for customers and staff, accessible by design, with a person to talk to when the software cannot help.
FinOps and commercial control
Cloud, licence and AI spend is visible by team and by client, with budgets that stop a runaway bill before it happens.
Build
How is it made?
Applications
Modular services rather than one tangle, clear APIs, and a sensible path off legacy systems instead of a big-bang replacement.
Integration and APIs
APIs, events and webhooks with versioned contracts, rate limits and monitoring, so connections do not quietly break.
Data and information
We classify data before deciding where it lives, then track ownership, quality, lineage and retention from there.
AI and agents
Model routing, answers grounded in your own records, tool permissions, evaluation and human approval, with every action recorded.
Protect
How is it kept safe?
Identity and access
Every person, service and agent has a name. Access is least-privilege, authentication is strong, and secrets stay out of code.
Cybersecurity
Zero-trust thinking, threat modelling, secure development, patching and detection, because an attacker only needs one gap.
Cloud, platform and network
Landing zones, regions, private connectivity and segmentation, so workloads are separated and exposure is kept small.
DevSecOps and delivery
Everything ships through source control, automated tests and security gates, with evidence kept for every release.
Prove and run
How do we show it?
Operations and resilience
Monitoring, incident response, backups and recovery targets that are tested, not assumed.
Governance, risk and compliance
Policies become controls, controls map to obligations, and audit evidence is collected as we go rather than scrambled together at the end.
Sovereignty and residency
Where data is stored and processed, who holds the keys, and which jurisdictions could compel access, all written down and evidenced.
Neocortex solution design
The platform, in C4 diagrams.
System context, containers, the AI Brain core and the deployment options, drawn to the C4 model so an architecture team can challenge them.
Level 1
System context
Who uses Neocortex and the systems around it: identity provider, business systems, AI models (cloud or on-box), Composio and hosting.
Level 2
Containers
The deployable parts of one customer instance: experiences, gateway, Conductor, Trust Fabric, AI gateway, Second Brain, integration fabric, capability apps and data stores.
Level 3
Components of the AI Brain core
How a request becomes governed work: Conductor, Personas, policy check, agent runtime, approvals, model routing, retrieval and evidence.
Deployment
Deployment options
The same containers managed in Australia, in your cloud tenancy, or in your data centre, with an optional hybrid link.
Reference solution design. Components marked Roadmap are direction, not shipped. Capability availability, hosting model and integrations are confirmed per customer during the two-week discovery.
Security architecture
Nine layers, from the rule on paper to getting back up.
Each layer assumes the one before it can fail. The shade deepens toward the moment something goes wrong.
- 01
Policy
Business, legal, regulatory and contractual requirements become design rules we can point to.
- 02
Identity
People, services and agents each have an identity, the least access that works, and strong sign-in.
- 03
Data
Data is classified first, then storage, models, integrations and regions are chosen to fit.
- 04
Cryptography
Encrypted in transit and at rest, with key custody separated from application access where the risk calls for it.
- 05
Network
Trust zones, minimal public exposure, private links where needed and controlled outbound traffic.
- 06
Application
Secure coding, dependency checks, input validation, secrets management and automated security tests.
- 07
AI
Models, prompts, retrieval, tools and outputs are controlled, tested and approved by a person where it matters.
- 08
Detection
Security telemetry, audit trails and alerts feed one place, so something odd is noticed and explained.
- 09
Recovery
Protected backups, restores that have been tried, recovery targets and a plan for carrying on.
Reference workflow
Turn requirements into evidence.
Every requirement goes through the same five steps. Here is one real requirement carried all the way through, so “evidence” means something you can ask for.
Worked example
Keep personal information secure
Australian Privacy Principle 11 (Privacy Act 1988)
- 01
Classify
What the system is for, who uses it, what data it holds, how critical it is and what could go wrong.
For this requirement
Client records hold personal information, so they are classed as sensitive.
- 02
Constrain
The limits that follow: regions, providers, identity, retention, security and AI rules.
For this requirement
Stored only in approved regions, encrypted, and open only to people who need it.
- 03
Design
The target architecture, the controls, the integrations and who runs what.
For this requirement
Australian-region database, encryption at rest and in transit, role-based access.
- 04
Prove
Tests, configuration, logs, contracts, attestations and sign-offs that show it is true.
For this requirement
A configuration export, access and audit logs, and confirmation of where it is hosted.
- 05
Monitor
Watching for drift, incidents, vulnerabilities, supplier changes and new rules.
For this requirement
Alerts on unusual access and a check for settings drifting from the approved design.
Australian government and law
The standards we design against.
These are the frameworks and laws that may matter depending on the customer, the information involved and the jurisdiction. Listing one is not a claim that Neocortex is certified or compliant with it. That depends on the deployment and its scope, and we show it with evidence.
Australian Government Architecture (AGA)
Patterns and standards for government systems, including privacy, application security and secure data exchange.
PSPF Release 2026
The protective-security policy for the Australian Government across six security domains, mandatory for in-scope Commonwealth entities.
ASD Information Security Manual (September 2026)
The controls ASD recommends for protecting government IT and operational technology.
Essential Eight
ASD’s prioritised mitigation strategies and maturity model, mapped to the ISM.
Digital Service Standard
How government services are designed and delivered: user needs, accessibility, privacy, security and testing.
Privacy Act 1988 and the Australian Privacy Principles
The core privacy regime: collecting, using, securing and disclosing personal information, including sending it overseas.
Notifiable Data Breaches scheme
When a breach is likely to cause serious harm, you have to assess it and notify.
Security of Critical Infrastructure Act 2018
Extra obligations for regulated critical-infrastructure entities and systems of national significance.
Data Availability and Transparency Act 2022
A framework for sharing certain government data under statutory safeguards.
Archives Act and records obligations
Keeping, disposing of and archiving records, where they apply.
International assurance
And for multinational and regulated environments.
NIST CSF 2.0
Risk-based cybersecurity outcomes: Govern, Identify, Protect, Detect, Respond and Recover.
NIST Privacy Framework
A voluntary way to manage privacy risk alongside cybersecurity risk.
ISO/IEC 27001:2022
Requirements for an information security management system.
ISO/IEC 27701:2025
Requirements for managing personal information as a controller or processor.
ISO/IEC 42001:2023
Requirements for managing AI responsibly, from development through use.
EU GDPR
EU personal-data law: lawful processing, minimisation, security, accountability, individual rights and transfers.
EU AI Act
Risk-based AI regulation in force since 2024 and broadly applicable from 2 August 2026, with staged exceptions.
WCAG 2.2
The accessibility baseline for inclusive digital services. Government requirements depend on jurisdiction and context.
Residency and sovereignty
Location is only one part of control.
Data residency
Where data is stored or processed. It is enforced through region choice, service settings, backups, logs and provider contracts.
Data sovereignty
Who has legal and practical control over the data, and which laws could reach it. Hosting in Australia does not by itself settle that.
Data localisation
A rule that certain data must stay inside a defined geography. That is stronger than simply preferring local hosting.
Provider jurisdiction
Where the provider, its parent company and its subprocessors are based. It can matter even when the workload runs in Australia.
Operational sovereignty
Who can administer, decrypt, export, delete or restore the system. Privileged access and key custody are part of sovereignty.
Evidence over claims
Every statement about residency, security or compliance is backed by configuration, contracts, attestations, logs and a clear scope.
The deployment decision record
For each customer we write down the approved data classes, the permitted regions and processing locations, the model providers and subprocessors, how keys are managed, who has privileged access, where backups and support sit, which legal jurisdictions apply, and how you would leave. We treat that record as an architecture control, not marketing copy.
Privacy and data governance
Privacy is a property of the design, not a policy page.
Purpose and minimisation
Collect and show only what the stated purpose needs, and keep operational context apart from unrelated personal information.
Classification
Classify information before it reaches search, analytics, AI prompts, logs, backups or third parties.
Consent and lawful basis
Record the authority for processing where it is required. A generic platform consent is not a substitute for the customer’s own obligations.
Cross-border controls
List every overseas provider, subprocessor, support location and transfer path, and apply APP 8 or GDPR mechanisms where they apply.
Retention and deletion
Set retention by record type, automate deletion where possible, and keep legal holds and statutory records when required.
Subject rights
Support access, correction, deletion or restriction, and export, where the applicable law gives those rights.
AI privacy
Control training and feedback use, prompt retention, provider logging, sensitive data, retrieval scope and human review.
Breach readiness
Audit trails, detection, runbooks and a notification decision path that suits the customer’s regulators.
Want to see the evidence for your situation?
Tell us the data, the regulators and the regions that matter to you, and we will show you how the design answers each one.