Security and trust

Klineo separates planning, application access, and onchain authority. An SDK can read permitted evidence and prepare supported workflows. It cannot turn an application role, API key, simulation, or AI recommendation into permission to move vault assets.

This page describes controls present in the source and the canonical release posture as of September 30, 2026. It does not attest that a particular deployment has passed those controls. Before connecting capital, verify the release, chain, contract bytecode, issuer Safe, and policy for that deployment.

Current release posture#

Local contract tests, generated SDKs, working API endpoints, and a healthy UI do not establish production activation. A disposable testnet sandbox is separate from the canonical release. Its test assets, simulated venue dependencies, and EOA ownership are unsuitable evidence for a production Safe-owned vault.

Custody boundary#

The contract architecture assigns vault ownership to the issuer's Safe. The issuer authorizes policy and retains contract-level pause and exit paths. Klineo application membership and developer credentials do not grant Safe signing authority.

The v1 vault contains issuer-only recovery paths that do not require a live policy, executor, or backend. The v2 vault lets its owner pause and transfer specified assets and position NFTs through issuerExit without controller, executor, oracle, or provider cooperation. See Contract architecture for the differences between versions.

Self-custody does not remove smart-contract, token, venue, market, or issuer-signing risk. Exit operations still require a working chain, sufficient gas, issuer authorization, and successful underlying token or NFT transfers. An exit that transfers a position NFT does not promise immediate conversion of that position into cash.

Application access and organization isolation#

Interactive access uses a verified email magic-link session. Production secure-cookie mode uses an HTTP-only session cookie. The authenticated subject comes from the server's session verification; supplying an organization ID does not authenticate an actor.

For organization-scoped operations, the backend resolves current membership for the authenticated subject and applies role checks. The x-klineo-organization-id header selects the intended organization; the server validates membership and resource ownership before access. The database schema enables and forces PostgreSQL row-level security on protected Liquidity Studio tables. Browser-readable records have explicit policies, while workflow and worker records cross separately authorized backend boundaries.

These layers require the correct migrations, database roles, authentication configuration, and deployed runtime. Database owner and explicitly privileged operations remain part of the trust boundary. An integration should use the API rather than database credentials and must never accept a client-supplied role as authority.

Sensitive actions require fresh authentication#

Authority changes and sensitive administrative workflows require a server-verified authentication ceremony within the preceding ten minutes. Examples include membership changes, developer credential creation or rotation, Safe verification, policy approval, submission registration, public report publication, and operational recovery.

A recently issued client timestamp or an existing organization role cannot satisfy this requirement. The current ceremony is email magic-link authentication at assurance level aal1; this documentation does not claim hardware-key authentication or multi-factor assurance.

On LIQUIDITY_STUDIO_REAUTHENTICATION_REQUIRED, complete interactive reauthentication and review the intent and current evidence again. The key to use depends on the operation. Credential creation and rotation store this 401 as a completed failure: the original key will replay it even after reauthentication, so the newly reviewed intent needs a new key after the definitive failure is established. Authentication or scope rejection before the mutation handler, and the ordinary v2 record handler's recent-authentication rejection, do not store a completed result; an unchanged intent can retain its original key after access is restored.

Retain the original key and exact request when completion is uncertain or a failure is transient, and recover the result before considering a new intent. Do not automatically retry authorization failures or generate new keys to bypass review. A service credential cannot satisfy an interactive reauthentication requirement. See Permissions and credentials and authentication failures and stored results.

Bound execution#

Contracts expose typed actions rather than a general-purpose transaction execution interface. Policies bind assets, venues, adapters, action permissions, budgets, freshness requirements, and relevant risk limits. Contract checks include deadlines and replay protection, exact allowance or spend limits, observed token balance changes, position custody, and oracle or pool validation where the action requires it.

V2 adapter registration binds a venue to the adapter's actual runtime code hash and audit and manifest commitments. A commitment records reviewed evidence identity; its existence alone does not prove an independent audit occurred. The controller adds policy expiry, authority expansion delays, control epochs, immediate demotion or revocation, and ordered scheduled-plan reconciliation. Missing required evidence blocks a risk-taking path instead of substituting a demo value.

The current v2 release forbids arbitrary targets, arbitrary calldata, proxy upgrades, AI execution, and public-mempool fallback. A strategy compiler or policy preview produces preparatory evidence. It does not enable a disabled adapter or activate a release.

Evidence and audit history#

Material application mutations preserve actor identity, organization, reason, request correlation, resource identity, and evidence hashes. Versioned policies, proposals, Safe handoffs, chain observations, and reconciliation records make a decision traceable from preparation to observed settlement. Idempotency and resource versions help prevent duplicate actions and overwriting a decision made against older evidence.

Transaction submission, inclusion, finality, and reconciliation are separate states. A submitted transaction hash is not proof that the intended economic result occurred. Chain reorganization or conflicting observations can invalidate an earlier view. Use finality and reconciliation evidence when presenting settled results.

Signed exports require independent key trust. A public key embedded in a signed bundle can prove that bundle is internally consistent; it cannot prove the identity of its issuer. Compare the key or fingerprint with an independently obtained trust anchor and verify hashes and disclosure scope.

Release verification#

Canonical release manifests bind the release to source and artifact identity, chain and environment, contract runtime hashes, dependency evidence, gates, expiry, and designated approvers. Activation requires independent security, contract, operations, and issuer approvals. V2 also binds the exact verified v1 release digest and feature-specific rollout and authority limits.

The release gates include independent contract review, contract invariant and pinned-venue testing, data and oracle quorum, provider and KMS attestations, incident and issuer-exit drills, legal and commercial review, and capped testnet acceptance. Those are acceptance requirements, not completion claims. Current canonical manifests do not supply the evidence needed for live activation.

Before accepting a claimed live integration, inspect its runtime status and obtain the applicable release evidence. Confirm the feature is released, the emergency state permits it, the chain and named vault are authorized, and the release has not expired. Contract bytecode must match that release. Read-only status availability by itself is insufficient.

Integration responsibilities#

Store API keys and OAuth client secrets on a server or in a secret manager. Do not put them in browser bundles, source control, analytics events, exception bodies, or support transcripts. Use the narrowest available scopes, set an expiry where practical, and rotate or revoke credentials when ownership changes or exposure is suspected.

Treat token symbols and display metadata as untrusted labels. Match chain IDs, addresses, runtime evidence, integer quantities, and decimals. Preserve the provenance and confidence of market inputs; display unavailable or degraded evidence explicitly. Keep raw secret values and unpublished organization evidence out of logs and public reports.

Klineo's source describes security controls and release checks. No SOC 2, ISO 27001, insurance coverage, blanket asset-safety guarantee, or completed independent audit is asserted by this page. Confirm any future assurance claim against its dated report, scope, release identity, and exclusions.

Reporting a security issue#

Use the private security contact supplied with your organization's onboarding or support agreement. Include the affected SDK or API version, a concise impact description, a minimal reproduction using test data, and request correlation IDs where available. Do not send active credentials, signing keys, private documents, or assets of value.

If you do not have a private contact, request one through Klineo's existing support channel before sharing sensitive details. No dedicated public vulnerability inbox or bug-bounty program is asserted here. An issuer concerned about vault authority should use its reviewed pause and exit procedure and preserve the relevant evidence.

Implementation references#

The canonical status is recorded in contracts/liquidity-studio/manifest/liquidity-studio.release.json and liquidity-studio-v2.release.json. Acceptance requirements are maintained in docs/liquidity-studio/RELEASE_GATES.md. Session, membership, and recent-authentication behavior are implemented in the backend authentication middleware and Liquidity Studio and Operating System routers. Contract controls are described in Contract architecture.