Onboarding & medical privacy
Separate policyholder, adviser, beneficiary and employee authority. Restrict medical evidence to authorised underwriting and claims roles; minimise what agents and service providers receive.
THE ATLAS SECURITY DESIGNA changing defence.
A changing defence.
A consistent experience.
Polymorphic cyber security is our design concept for a defence that changes approved parts of its attack surface, while keeping customer services and accountability steady.
See how it worksAcross all six Atlas applications
Application safeguards are implemented; the security lab remains a simulation. The examples use fictional signals. They do not monitor visitors, detect malware, rotate real credentials or change infrastructure.
WHAT THE TERM MEANS HEREMake a foothold
Make a foothold
less useful over time.
The closest established concept is moving-target defence: controlled changes that reduce the usefulness of an attacker’s knowledge or access. Atlas proposes expiring authority and replacing affected service instances within approved boundaries.
Risk-based verification, least privilege and AI-agent restrictions support that design. They are separate safeguards; a changing graphic or a new login screen is not a security control.
Read NIST’s moving-target defence definitionEXPLORE THE DESIGNChange the situation.
Change the situation.
See the response.
Choose a product and a scenario. Advance each step to see the proposed controls and the customer experience together.
Atlas Insurance (Life)Policyholder identity, medical privacy, fund switches and claims authority
ATLAS DEFENCE LABSIMULATION · NO LIVE TELEMETRY
Review a policyholder fund-switch instructionIllustrative request
SCOPED & CONTROLLED
IdentityIdentity verified
PolicyCheck scope
ServiceInstance A
EvidenceRequest recorded
A conceptual view. No credentials, infrastructure or customer data are changed by this demo.
STEP 1 OF 3 · ROUTINE ACCESS
Check the request
Evaluate the identity, tenant, purpose and action against an approved policy.
CUSTOMER EXPERIENCE
Continue with the familiar service.
EXAMPLE SIGNAL
Known context · permitted action
1 / 3
Illustrative evidence trail
LOCAL DEMO ONLY- 01Identity and scope evaluated; no blanket trust from a prior login.
This explanatory trail resets when you change scenario. It is not a saved incident record, a security log or a live approval workflow.
ATLAS INSURANCE (LIFE)Protect the policyholder.
Protect the policyholder.
Preserve the promise.
The proposed security design covers protection policies, investment bonds and single or regular premiums. Sensitive actions need their own checks, even after a successful login.
Explore the insurance simulationPremiums & policy changes
Validate the identity and authority behind payer, bank-account and beneficiary changes. Hold suspicious requests for independent verification and retain the original instruction and decision evidence.
Investment bonds & fund switches
Bind authority to the specific policy, funds and allocation. Check the mandate, applicable advice and risk-assessment requirements, product restrictions and approvals before release. An agent cannot change its own investment mandate.
Claims, surrender & recovery
Separate assessment, approval and settlement authority. Verify payee changes independently; reconcile recovered instructions to avoid duplicate payments. Preserve claim evidence and provide a human support route when a request is held.
These are design requirements for the connected security service. Live fraud detection, adaptive infrastructure and insurer or payment integrations require implementation and validation; the simulation does not activate them.
THE PROPOSED DEFENCE MODELChange with purpose.
Change with purpose.
Keep control.
Defensive actions stay within systems Atlas is authorised to operate. We do not retaliate against apparent attack sources. Adaptive timing is bounded and auditable; it does not replace independent security testing or guarantee immunity.
Short-lived authority
Separate human and workload identities. Limit each agent to approved tools, data, tenants, actions, time and spend. Reject expired, revoked or out-of-scope requests.
Controlled replacement
Replace suspect service instances using verified images and narrowly scoped identities. Preserve durable data, transaction integrity, investigation evidence and approved data residency.
Accountable adaptation
Use signed, versioned policies and pre-approved response boundaries. Separate policy author, approver and executor; retain rollback, emergency stops and independent review.
TRANSPARENT DELIVERY STATUSWhat exists.
What exists.
What still needs delivery.
Application controls updated on 30 October 2026. This is not an independent security assessment, live posture feed or certification.
| Control | Current status | Scope and next requirement |
|---|---|---|
| Independent email verification and expiring sessions | Implemented baseline | Each Atlas application has its own verification flow and session. Email codes are not phishing-resistant MFA; stronger identity methods need integration and testing. |
| Adaptive verification abuse protection | Implemented baseline | All five apps apply persistent network-scoped verification limits, escalating temporary cooldowns and bounded random retry timing. Existing code-attempt and email-sending limits remain. This is application-level protection, not a DDoS mitigation service. |
| Browser and request safeguards | Implemented baseline | A shared response layer applies anti-framing, content-type, referrer, feature-access and sensitive-response cache controls. Cross-site browser mutations are rejected. Strict script policies remain on the four dedicated Workers; Risk Atlas has a more limited CSP pending a tested React nonce migration. |
| Account session containment | Implemented baseline | Authenticated users can sign out all devices within their current app. Other Atlas apps keep separate sessions. Account suspension and access removal are enforced by existing server-side checks. |
| Customer and employee authorisation | Mixed scope | Enterprise operations across all six apps enforce roles, department and entity scope, bounded delegation and independent approvals. Existing Risk and Compliance module memberships remain separate; older role walkthroughs are still demonstrations. |
| Payment facial and SMS checks | Banking sandbox | Payment-bound verification is demonstrated with synthetic outcomes and test codes. Real liveness, fraud, mobile identity and SMS providers are not connected. |
| Rotating workload credentials and service instances | Proposed | Requires a secrets/workload identity service, orchestration, revocation propagation and tested replacement policies. Not activated by this page. |
| Endpoint malware, ransomware, domain cloning and volumetric attacks | Requires infrastructure services | Endpoint protection, malware scanning, managed WAF and DDoS configuration, phishing-domain monitoring and tested immutable recovery are not supplied by the application controls. These require connected services and operational validation. |
| Device risk, attack detection and adaptive policy | Proposed | Requires trusted telemetry, detection tuning, customer challenge/recovery design and a server-side enforcement point. No device profiling is performed by this demo. |
| AI-agent containment and approval controls | Proposed | Requires an authenticated tool gateway, mandate registry, isolated execution, monitored egress and independently authorised changes. No autonomous security agent is enabled here. |
| Security operations and assurance evidence | Proposed integration | Connect detection, incident response, protected evidence storage and independent testing. Existing application records are not a central security monitoring service. |
OWNERSHIP THROUGH ALL THREE LINESAdaptive controls.
Adaptive controls.
Accountable people.
Proposed oversight for every Atlas deployment. Software supports the control framework; it does not establish compliance by itself.
Board & senior management
Approve risk appetite, reserved decisions and delegated limits. Review material incidents, customer harm, control exceptions and recovery evidence.
First line · security & operations
Own control operation, service health, response runbooks and customer support. Exercise only approved, bounded emergency authority.
Second line · risk & compliance
Challenge policy, monitor exceptions and validate privacy, regulatory applicability and customer outcomes. Track overdue remediation.
Third line · internal audit
Independently assess design and effectiveness, including privileged access, evidence integrity, recovery tests and management closure claims.
The management view should report
Revocation delays · failed policy checks · isolated services · recovery times · customer verification failures · agent mandate breaches · unresolved incidents · overdue actions.
These are proposed measures. No live scores or fictional “secure” percentages are presented as actual performance.A CONTROLLED ROUTE TO ACTIVATION
Build. Validate. Then activate.
- 01
Scope the first deployment
Confirm assets, tenants, providers, threat model, service availability, data locations and permitted response actions.
- 02
Connect and enforce
Integrate identity, secrets management, telemetry, policy enforcement and orchestration. Establish named owners and separation of duties.
- 03
Prove the response
Test stale credentials, cross-tenant access, agent misuse, false positives, dependency failure, recovery, reconciliation and rollback. Obtain independent assurance.
- 04
Approve and monitor
Secure the required security, privacy, operational and local compliance decisions. Begin with a monitored pilot, then expand with measured evidence.
Same Atlas jurisdiction scope
Isle of Man · Jersey · Guernsey · UK · EU · UAE · Cayman Islands · Bahamas.
Applicability depends on the legal entity, licence, activity, data and outsourcing arrangements. Select the actual EU Member State and UAE regime. Security changes must respect approved data locations, retention, accessibility and incident-reporting obligations; local validation is required.
Does “polymorphic” mean self-rewriting production code?
No. This blueprint uses approved changes to authority and infrastructure. An AI agent must not rewrite its own permissions, deploy unreviewed code, move customer data across borders or erase evidence. Customer interfaces and public URLs can stay familiar while underlying controls change.
Will this make Atlas automatically compliant or immune to attacks?
No. It can be part of a layered security programme once implemented and validated. Sound access control, patching, secure engineering, monitoring, privacy, recovery and independent assurance remain necessary.
Design referencesNIST SP 800-160 Vol. 2 Rev. 1 · Cyber resiliency NIST SP 800-207 · Zero trust architecture NIST SP 800-63B-4 · Authentication References inform the design. They are not endorsements or certifications of Atlas.