Research & credentials
Research IP, vendor keys and broker credentials need access appropriate to their purpose. Read access itself can be sensitive, even where an account cannot change a row.
Nexus engineering · Deep dives
Security architecture
& resilience.
A trading platform holds authority as well as information. Security means controlling who can place orders, change a dataset or ship code—and having a way to contain a compromise and recover with confidence.
Protect authorityLimit the damageDetect & containProve recovery
Design and selected evidence reviewed 2 November 2026. A self-assessment of a small platform; institutional requirements are identified separately.
01 · Start with the consequence
What would a compromise cost?
The design starts with the assets and the decisions they enable. An attacker could steal a credential, alter a dependency, compromise a trusted device or destroy operational history. An authorised user can cause the same damage by mistake.
Data & trading authority
A changed contract parameter, model configuration or executable can alter an order. Protect the path from source data and reviewed code to the instruction the broker receives.
Operations & recovery
Loss of capture, control access or the trade record can leave an operator unable to reconcile or act. Recovery must restore a trustworthy service and its credentials, as well as its data.
02 · Keep each boundary explicit
Public reach does not confer trading authority.
The public website and market-status view terminate at an edge server. The core platform sits on a private network. The important decision is what may cross between them.
Visitor
Website and selected market-status data.
→HTTPS
Narrow public surface
Static pages. Exact-path read-only proxy, caching and rate limits.
→Allow-listed reads
Core platform
Service identities, database grants and application controls.
Administration
Trusted device → private WireGuard network → SSH key → account permissions. Deployment and data changes then use their own controlled paths.
Make exposure a small decision.
The market-status gateway admits named read-only routes, with a catch-all for other API paths. It avoids publishing the internal console or a general-purpose proxy. Caching and rate limits also bound the load reaching the core.
Documented design: public read-only access decision; described on Infrastructure.
Authenticate the action as well as the connection.
Private networking encrypts the network hop and restricts reachability. Application authentication and authorisation still matter. The trader's API guard rejects a missing configured key; that code check does not establish complete end-user identity or access control across every service and proxy.
Source inspected 2 Nov 2026. Authentication coverage must be assessed route by route.
04 · Treat delivery as a security boundary
Code can exercise every permission its service holds.
A dependency, a build runner and an AI coding agent all participate in the path to production. Review needs to consider the authority of the resulting program as well as whether its tests pass.
- 1
Review the change
Review the specific revision, including permissions and deployment behaviour. Keep exceptional approvals explicit and attributable.
- 2
Scan code & dependencies
Data-service CI runs secret scanning. Data and trader dependency workflows audit the locked dependencies on relevant changes and a daily schedule.
- 3
Control the release
Core deployment gates reject dirty, stale or unintended rollback releases. Release access and runner credentials remain assets to protect.
- 4
Keep the receipt
Record what shipped and connect operational evidence to the revision. A successful build alone does not prove what is running.
Instructions are not a permission system.
Agent changes use the work, review and deployment controls described in Agents and CI. Repository text and external material can be hostile input. Credential access, tool permissions and release authority need enforcement outside the model's judgement.
AI-assisted review provides another technical check. Agents controlled by one operator do not provide independent organisational assurance.
A clean scan has a defined scope.
Secret scans can miss credentials, and dependency audits cover known advisories. Their presence does not prove a clean repository history or that someone received and acted on an alert. Rotation is still necessary after exposure.
OS security updates are automated; restarts and reboots are controlled around trading. The patch-policy checker passed on 2 Nov. Installing an update and running the updated code are separate milestones.
Workflow source inspected 2 Nov 2026; this is evidence of configured checks, not an all-clear vulnerability assessment. Patching policy and its operational trade-offs.
05 · Assume a boundary can fail
Contain first. Recover from a trustworthy state.
Operational alerts, deployment records and an incident register help reconstruct a failure. Security detection also needs to identify misuse that leaves a service looking healthy. These scenarios show the questions a response must answer.
Explore a compromise scenario
Illustrative response scenarios, not reports of incidents or claims of a completed security exercise.
A trusted device is compromised.
- What is at risk?
- Network membership, active sessions, source access and any credentials available to that device.
- Boundary to examine
- Which services can it reach, and which actions require a separate identity or approval? A private network connection alone cannot answer that.
- Containment plan
- Remove the device, revoke its sessions and keys, and assess downstream credentials. If trading authority may be affected, halt new orders and reconcile the broker state through a trusted route.
- Evidence required to resume
- A replacement trusted endpoint, verified revocations, an access review and an incident record explaining the period of exposure.
A dependency or proposed change is malicious.
- What is at risk?
- The credentials, data and network access of the build runner or deployed service executing that code.
- Boundary to examine
- Review, scanners and release gates offer checks; permitted service actions can still be abused. Inspect the privileges and outbound access of the executing identity.
- Containment plan
- Stop the affected release path, preserve evidence, isolate the workload and revoke exposed credentials. Establish a trusted build environment before producing a replacement.
- Evidence required to resume
- A reviewed dependency and source revision, a trustworthy build, rotated credentials and a reconciliation of any production writes or orders.
The production host is compromised.
- What is at risk?
- Live data, service identities, local logs and any backup locations the compromised account can modify.
- Boundary to examine
- An offsite copy protects against host loss. Resistance to malicious deletion also depends on separate credentials, snapshot permissions and control of the storage account.
- Containment plan
- Isolate the host, preserve evidence and protect the recovery copies. Select a known-good recovery point and rebuild in a trusted environment, with replacement credentials.
- Evidence required to resume
- Restore integrity, application checks, broker reconciliation and a deliberate decision about the lost interval. A checksum alone cannot establish that the source was uncompromised.
A halt preserves exposure.
The trading halt stops new orders and holds existing positions. It does not flatten the book. A security response must therefore include broker access, reconciliation and a separate decision about existing market exposure.
The execution deep dive explains the trading controls. These are containment tools, not intrusion detectors.
Test the recovery you intend to rely on.
The scheduled database smoke restore and full TimescaleDB restore both reported success on 2 Nov. They provide database recovery evidence. They do not prove clean-room recovery after an attacker compromise, recovery of every secret, or the recovery time of the complete application.
See backup and restore scope. Security exercises must also test detection, escalation, credential custody and the decision to resume.
06 · Scale the assurance with the responsibility
What I would require at institutional scale.
Nexus makes engineering decisions inspectable. A sovereign investor adds different consequences: confidential investment information, a larger supplier estate, multiple privileged teams and a much greater cost of compromise. The control programme must reflect those responsibilities.
Account for every privileged action.
Central identity, phishing-resistant MFA, joiner/mover/leaver controls, time-bounded privileged access, access recertification and separation of production approval from implementation. Test emergency access and its custody.
Give alerts an owner who can act.
Security telemetry and retention, endpoint protection, monitored authentication and privilege changes, out-of-hours response and rehearsed escalation. Exercise a stolen identity and a compromised supplier, including communications and recovery authority.
Trace where information and authority go.
Classify investment and personal data; define residency, retention, encryption and key custody. Assess cloud, data, broker and AI providers for access, subprocessors, concentration risk, incident obligations and exit arrangements.
Make residual risk an owned decision.
Independent security testing, vulnerability remediation targets, exercised recovery objectives and a risk register with owners and review dates. Choose certification and external assurance according to the institution's obligations and the reliance placed on each service.
Requirements, not claims of deployment.
The institutional controls above are the programme I would define with security, risk and operations colleagues. This page does not assert that Nexus has implemented them all or has independent security certification. Its current evidence is deliberately narrower.
The organising framework is NIST CSF 2.0: Govern, Identify, Protect, Detect, Respond and Recover. The Assurance page records the dated self-assessments and their limitations.