Security

Control starts with clear authority.

Neptlium reduces ambiguity by separating authenticated access, authorization, financial authority, external evidence and canonical financial state.

Core principle

Login does not equal financial authority.

Authentication answers who is present. Authorization asks whether that principal may perform a particular action in the current context. Financial authority goes further: consequential state belongs to governed server-side systems, not to what a browser renders or requests.

This separation is deliberate because visible, approved, submitted, settled and reconciled are different states.

Control model

Protection is a set of boundaries, not a slogan.

Identity & access

Authenticated identity establishes who is present. Session and account boundaries are handled separately from permission to create a financial consequence.

Authorization

Ownership, role, policy and current resource state are evaluated on trusted server boundaries for sensitive operations.

Financial authority

A browser can express intent. It is not the authority that decides canonical financial state, execution or settlement.

Provider boundaries

External execution or infrastructure systems remain outside browser authority. Provider observations are treated as evidence until the responsible domain process validates their meaning.

Data protection

Privileged credentials and service-level secrets stay outside public client code. Missing trusted configuration should fail closed rather than simulate capability.

Audit & evidence

Important actions and state transitions are designed to remain attributable and reviewable while audit records, ledger records, provider evidence and reconciliation retain distinct meanings.

Financial integrity

Evidence does not become finality by being visible.

RequestedAuthorizedSubmittedSettledReconciled

Infrastructure boundary

Privileged systems stay outside public client authority.

Neptlium keeps privileged credentials, provider secrets and service-role capabilities on reviewed server-side boundaries. Public interfaces should receive only the information and actions they are authorized to use.

Where deployment or infrastructure controls are not publicly verified, this page does not convert implementation assumptions into external security claims.

Reporting

Report a security concern.

If you need to report a security concern today, use Neptlium’s established contact route and avoid including passwords, private keys, authentication tokens or other sensitive credentials in an initial message.

Contact Neptlium

Security is also part of how you use the platform.

Clear account boundaries and careful handling of sensitive information help protect your work. A product explanation is not a security certification or a guarantee against loss.

Protect access and verify requests

Use the intended Neptlium destination and check the address before entering account information. Do not share passwords, verification codes, recovery material or session links. Treat unexpected requests to change a payment destination or bypass review as a reason to pause and verify.

Report concerns with limited evidence

For an initial report, describe the affected page, approximate time, observed behavior and potential impact. Redact personal and financial data. Do not access another person’s records, move funds or disrupt a service to demonstrate a concern.

Questions and next steps

Does signing in give someone access to organization funds?: No. Identity, organization membership and permission for a particular action are separate requirements. A displayed role or an identifier alone is not financial authority.
Where should I report a security issue?: Use the contact route for initial guidance. This page does not establish a paid bounty, guaranteed response deadline or a separate vulnerability-reporting agreement.