Security is an architecture decision, not a feature added later.
Centaurtech builds systems for organisations that answer to regulators, auditors and the public. Encryption, access control, sovereign AI and independent testing are scoped in at the first architecture session, because retrofitting any of them onto a finished system is how projects fail their assessment.
On-premise · Air-gapped · Data residency · Self-hosted AI
This is what Centaurtech designs and deploys for client systems. It is a description of delivery capability, not a claim about certifications we hold or a description of our own internal corporate environment.
Controls are scoped per engagement, sized to your risk profile, your regulator and your budget. Not every control belongs in every build. Part of our job at the architecture stage is telling you which ones your system genuinely needs and which ones would be expensive theatre.
Your quote names the controls. Whatever is agreed at architecture stage appears in the written scope, control by control, so there is never ambiguity later about what was delivered and what was not.
Where the system runs is a security control in itself.
-
Model 01
Managed cloud, named residency
The system runs on infrastructure in a jurisdiction you name, with no cross-border transfer of your data. Suitable where a regulator requires data to stay in country but does not require the system to sit inside your own network.
Typical fit: commercial, regulated data, no on-prem mandate -
Model 02
On-premise, your hardware
The whole system runs on hardware you own, inside your network. You hold the infrastructure, the data and the encryption keys. We build, deploy and hand over with a documented runbook, and it keeps running whether or not we are still engaged.
Typical fit: banks, hospitals, agencies with an on-prem policy -
Model 03
Air-gapped, no outbound path
The system runs with no route to the public internet at all. Updates arrive through a controlled offline process. Language models run locally, so sensitive records are processed inside the environment and never leave it.
Typical fit: classified, defence, sensitive citizen records
Most AI tools solve your problem by sending your data to somebody else's servers. For a ministry or a bank, that is usually where the conversation ends.
We deploy language models that run entirely on infrastructure you control, including fully air-gapped environments with no outbound network path. Case files, citizen records, customer data and internal documents are processed on your hardware and never leave it. No external model provider receives your data, because there is no route for it to travel. For most regulated organisations this is the difference between adopting AI and shelving it.
- Self-hosted models. Open-weight models running on your servers, sized to your hardware, with no external API dependency.
- No training on your data. Your content is not used to train anyone's model, because it never leaves your environment in the first place.
- Retrieval over your own corpus. The model answers from your documents and your records, with the source of every answer traceable.
- Auditable prompts and outputs. Where your policy requires it, every query and response is logged for review.
Eight domains we design and build against.
We describe categories rather than naming specific products. A published inventory of a client's exact tooling and versions is a starting map for an attacker, so vendor detail belongs in your architecture document under NDA, not on a public page.
-
01
Data protection and encryption
Protecting data at rest, in transit and in backup, with key custody arranged to match your policy rather than ours.
- Encryption at rest across storage, database and backups
- Current TLS only in transit, with mutual TLS between services where the design calls for it
- Key management with custody held by the party your policy requires
- Data classification and retention rules enforced in the system, not in a document
-
02
Identity and access
Every action attributable to a person, and every person holding the narrowest permission set that lets them do their job.
- Role-based access control designed around your actual org structure
- Single sign-on and directory integration where you already run one
- Multi-factor and passwordless authentication options
- Least privilege by default, with privileged actions separately recorded
-
03
Secure development lifecycle
Security checks that run on every change, before code reaches an environment where it could matter.
- Automated dependency and vulnerability scanning on every build
- Secret scanning so credentials never reach a repository
- Static analysis for insecure patterns and missing authorisation
- Reproducible, version-pinned builds so what is tested is what ships
-
04
Infrastructure hardening
Assuming a component will eventually be compromised, and limiting what the attacker gains when it is.
- Service isolation so a breach in one component does not become a breach of the system
- Unprivileged runtime with kernel capabilities dropped to the minimum
- Immutable and non-executable working storage to block dropped payloads
- Hardened baseline images, patched on a defined cycle
-
05
Network and ingress control
A small, deliberate front door, and nothing else reachable from outside it.
- Single controlled ingress, with databases and internal services never exposed publicly
- Network segmentation between tiers
- Rate limiting and automated blocking of hostile traffic
- Denial of service mitigation appropriate to the deployment model
-
06
Monitoring, detection and response
Knowing quickly, because the gap between compromise and detection is what turns an incident into a disaster.
- Continuous intrusion detection with alerting to a channel your team actually reads
- Tamper-evident audit trails for actions that carry legal or financial weight
- Automated checks that the deployed configuration still matches the approved one
- A written incident response procedure with named roles
-
07
Sovereign and air-gapped AI
AI capability that does not require handing regulated data to an external provider.
- Language models self-hosted on infrastructure you control
- Fully air-gapped operation with no outbound network path
- Retrieval restricted to your own corpus, with answers traceable to source
- Query and output logging where policy requires review
-
08
Resilience and recovery
A security control most vendors leave out, until the day it is the only one that matters.
- Automated backups with restores actually tested, not assumed
- Recovery objectives agreed in writing before the build starts
- Documented runbooks so recovery does not depend on one person
- Ransomware-resistant backup design where the threat model warrants it
We do not mark our own homework.
The scanning we run during a build is a development control. It catches known vulnerabilities, leaked credentials and insecure patterns before they ship. It is not assurance, and we will not present it as assurance.
Assurance comes from someone who does not report to us. That is a third-party testing firm, your own security team, or an assessor your regulator appoints, including a national agency where that applies.
- We prepare the environment. A dedicated test instance, seeded with realistic but non-production data, so testing never touches live records.
- We hand over the documentation your assessor needs. Architecture description, data flows, a control matrix mapped to the framework your auditor uses, and the deployed configuration.
- We remediate findings against agreed dates. Each finding gets an owner, a fix and a target date, tracked to closure rather than to a status meeting.
- We produce closure evidence for re-testing. The assessor verifies the fix. Our word that something is fixed is not the evidence.
How findings are shared. Never publicly. Full technical findings go under NDA to named recipients on your security team. What circulates more widely is an attestation from the testing party confirming scope, date and that findings were closed, plus a remediation closure report.
Publishing a live finding is publishing a working attack path. We will not do it, and we would advise you not to either.
What we do not claim.
If you are evaluating vendors seriously, this section is more useful than the rest of the page. A supplier who claims everything has told you nothing.
- We are not ISO 27001 or SOC 2 certified as an organisation. We build to those control families and can map a delivered system against them for your audit. We will not imply a certification we do not hold. If your procurement requires a certified vendor, say so early so neither of us wastes a cycle.
- We do not present our own testing as independent assurance. Independent means independent.
- We do not guarantee any system is unbreachable. Anyone who does is either inexperienced or not being straight with you. What we commit to is a defensible architecture, controls proportionate to your threat model, and honest disclosure when something needs fixing.
- We do not run a 24/7 security operations centre. Monitoring and alerting are automated and continuous. Human response is during business hours unless a separate support arrangement is agreed in writing.
- Controls outside your agreed scope are not in your system. Your quote lists what is included. Nothing on this page is delivered by implication.
Found something? Tell us.
If you believe you have found a security issue in anything Centaurtech operates or has delivered, email concierge@techadvantage.io with the detail and, if you have it, steps to reproduce.
We will acknowledge receipt and keep you updated while we investigate. We ask that you give us a reasonable opportunity to address the issue before publishing it, and that you do not access, modify or retain data that is not yours while investigating. We will not pursue anyone who reports in good faith and follows those two conditions.
What procurement usually asks.
Is Centaurtech ISO 27001 or SOC 2 certified?
No. Centaurtech is not currently certified against ISO 27001 or SOC 2 as an organisation.
We build to those control families and we can map a delivered system against them for your audit, but we will not imply a certification we do not hold. If your procurement requires a certified vendor, tell us early so you are not spending time on a process we cannot pass.
Can the system run entirely inside our own network?
Yes. On-premise deployment runs the whole system on hardware you own, inside your network, with you holding the infrastructure, the data and the encryption keys.
Where the environment requires it, we deploy fully air-gapped with no outbound network path, and updates delivered through a controlled offline process.
Can we use AI without sending our data to a third party?
Yes. We deploy language models that run on infrastructure you control, including fully air-gapped environments with no route to the public internet. Documents, case files and records are processed on your hardware and never leave it.
This is usually the reason a ministry or a bank can adopt AI at all, because sending regulated data to an external model provider is often not permitted.
Do you provide encryption at rest?
Yes, where it is in scope. Encryption at rest covers the storage layer, the database and backups, with key management designed so that keys are held by the party your policy requires to hold them. In an on-premise or air-gapped build that is normally you, not us.
Encryption in transit uses current TLS only, with mutual TLS between services where the design calls for it.
How do you handle penetration testing?
We do not mark our own homework. Independent testing is performed by a third party or by your own appointed assessor, including a national agency where that applies.
We prepare the environment, provide architecture documentation and a control matrix, remediate the findings, and produce closure evidence for re-testing. Our own scanning during the build is a development control, not assurance, and we do not present it as assurance.
How are penetration test findings shared?
Never publicly. Full technical findings go under a non-disclosure agreement to named recipients on your security team only.
What circulates more widely is an attestation from the testing party confirming the scope, the date and that findings were closed, plus a remediation closure report. Publishing a live finding is publishing a working attack path, so we do not do it and we would advise you not to either.
Who owns the system and the keys at handover?
You do. Source code, infrastructure definitions, deployment runbooks and documentation are handed over.
In on-premise and air-gapped builds you hold the encryption keys and the administrative credentials, and the system continues to run whether or not Centaurtech is still engaged. There is no dependency on a Centaurtech login.
Does every project include every control on this page?
No, and a vendor who says otherwise is selling you controls you do not need.
Scope is set at the architecture stage against your risk profile, your regulator and your budget. Your quote names which controls are included and which are not, so there is no ambiguity later about what was delivered.
Can you support our own audit or assessment process?
Yes. We provide architecture documentation, a control matrix mapped to the framework your auditor uses, data flow descriptions, and evidence of the controls actually deployed.
Where your assessor raises findings we produce a remediation plan with owners and dates, then evidence of closure.
How do we report a security issue to Centaurtech?
Email concierge@techadvantage.io with the detail and, if you have it, steps to reproduce. We will acknowledge receipt and keep you updated as we investigate.
Please do not publish the issue before we have had a reasonable opportunity to address it, and please do not access, modify or retain any data that is not yours while investigating.
Bring us the requirement, not just the project. If you have a security standard to meet, an assessor to satisfy or a policy that rules out the obvious approach, that is the conversation to start with. It shapes the architecture, and architecture is cheap to change before the build and expensive after.
Discuss your requirements