ORQANTA / Security & governance

Control is not a wrapper. It is part of the work.

ORQANTA is being designed to support bounded autonomy with explicit human authority, evidence links, and recovery paths. These are design targets, not universal security guarantees.

Illustrative product conceptIllustrative workflow and output. Availability and capabilities vary by deployment.
ILLUSTRATIVE POLICY / ENTERPRISE-01Example production change
Read approved repositoriesExample: allowed
Write isolated branchExample: allowed
Merge to productionExample: human approval
Change access policyExample: blocked

Current website controls

What is implemented on this website.

Website Security Owner and Privacy Owner: designated operator roles held by LANTU TEKNOLOJİ LİMİTED ŞİRKETİ. Last reviewed: 22 August 2026. Review cadence: at least quarterly and after any material hosting, access, tracking, form, or security-control change. These statements apply to this website, not to a generally available ORQANTA SaaS service.

01Available now

Owner-only access

The current Sites publication uses a custom access policy limited to the verified owner account.

02Available now

Fail-closed, minimised contact delivery

The business-inquiry and product-needs forms send no fields while the approved same-origin endpoint, email provider, server secrets, controlled From domain, abuse controls, transfer route, and verified deletion process are incomplete. When enabled, D1 stores no raw submission body; keyed hashes, category, reply choice, delivery state, notice version, consent time, and separate marketing choice receive a 30-day logical expiry.

03Available now

No marketing tracking

The application does not include advertising pixels, behavioural analytics, heatmaps, or session replay.

04Available now

Private cache baseline

Current HTML responses are configured for private, no-store delivery with restrictive browser-security headers.

Verification evidence

Release checks, with an explicit assurance boundary.

The website controls are checked through source review, automated build and route tests, response-header inspection, and an owner-only deployment check before release. This local revision is not represented as production-verified until that final private-deployment check is complete. The local checks cover the absence of application tracking scripts and uploads, fail-closed form behaviour, private no-store HTML and API responses, restrictive security headers, and the Sites access policy. No independent third-party penetration test, audit, certification, or universal security assurance is claimed.

Product design targets

Proposed controls for consequential work.

These are architectural principles under active development, not claims of certification or universal risk elimination.

For meeting, voice-note, or recording inputs, the designed boundary requires applicable recording notice and consent, organisational authority, sensitive-mode handling, access restrictions, a retention and deletion rule, geographic review, and human approval before any bounded agent action. Live meeting participation, continuous call listening, and full voice control are not current website capabilities.

01Concept / roadmap

Bounded authority

Define what a run may read, propose, change, spend, and communicate before execution begins.

02Concept / roadmap

Human decision gates

Place named approval points around irreversible, sensitive, or high-impact actions.

03Concept / roadmap

Evidence-linked output

Connect proposed decisions to sources, tool results, and evaluations that support review.

04Concept / roadmap

Separation of duties

Use independent planning, execution, and review roles where self-approval is unacceptable.

05Concept / roadmap

Recoverable change

Preserve versions, state transitions, and rollback paths for work that changes systems.

06Concept / roadmap

Explicit data boundaries

Route data according to approved policy, provider, geography, and task sensitivity.

07Concept / roadmap

Purpose-bound data use

Minimise collection by default and require a disclosed purpose, lawful basis, authority, retention rule, and review before enterprise or creator content enters a workflow.

Evidence, not theatre

A run should be explainable after it moves.

ORQANTA is designed to support an operating record that can answer: what happened, why, under whose authority, using which evidence, and what can be recovered.

01
Intent record

Example: requested outcome and constraints

02
Decision trace

Example: proposals, approvals, and rejected alternatives

03
Action record

Example: tools proposed and systems affected

04
Evaluation

Example: checks proposed and outcomes observed

Security contact

Report a suspected website security issue.

Send a concise initial report to info@lantu.global with the subject “ORQANTA security report”. Do not include credentials, customer data, or exploit payloads in the first message.

Private access

Define the boundary before the autonomy.

We are looking for design partners with real operating constraints and a serious standard for accountable AI execution.

Start a conversation