Metadata-Only by Design: The Lattix SDK and Platform API Enter Developer Preview

Lattix Technologies has published the public developer preview of the Lattix SDK family (Rust, Go, Python) and the Lattix Platform API. The documentation is live at /docs/sdks and /docs/api. The OpenAPI contract for the HTTP control plane is published at /openapi/sdk-control-plane.yaml. This is a public preview: the surface is stable enough to build against, and reserved language on production commitments remains in force for named deployments.

The architectural headline is the same one that governs every Lattix product: protected data does not transit the control plane. The HTTP API is metadata-only on the wire, and the SDKs pair that control plane with a set of in-process embedded-protection helpers that keep artifact bytes and key material inside the caller. Applications enforce protect, access, rewrap, sign, and verify operations locally. The platform answers the questions that must be centralized, who is calling, what policy applies, how the key should be handled, whether to register the resulting artifact, and what evidence to record, without ever seeing the plaintext.

Why metadata-only matters

The dominant integration pattern in data security tooling still asks the application to ship the data to a service that will protect it, decrypt it for authorized readers, and return it. That pattern introduces a second copy of the plaintext, a second trust boundary, a second audit surface, and a bandwidth profile that does not scale across coalition, tactical edge, or regulated environments.

Lattix inverts the pattern. The SDKs use the Platform API to resolve the decisions that must be centralized per operation: is the caller allowed to do this, what handling is required, how should the key material be handled, how does the resulting artifact register to the ledger, and what evidence should be emitted. The application performs the cryptography locally through the SDK's embedded-protection helpers. The platform never holds the protected bytes. In the bootstrap response, this stance is explicit: plaintext_to_platform: false. It is the contract, not a configuration choice.

The operational consequences are specific. Audit surfaces compress to the metadata stream. Bandwidth is bounded by the size of the policy decisions, not the size of the data. Regulatory regimes that require data to remain in a defined locality remain satisfied because the data never leaves the enforcement node. Air-gapped and tactical-edge deployments use the same control-plane contract as cloud deployments, because the contract describes decisions, not payloads.

The nine control-plane operations

The SDKs and the Platform API expose the same nine control-plane operations. Each SDK method maps 1:1 to a route under /v1/sdk/*.

capabilities returns the caller's identity, the active authentication mode, deployment-default scopes, and which platform domains are configured. whoami returns the resolved tenant, principal, subject, and scopes, useful as a lightweight credential check. bootstrap returns the embedded-enforcement model, the supported operations (protect, access, rewrap), the supported artifact profiles (tdf, envelope, detached_signature), and the control-plane domains the SDK may reach. exchange_session exchanges SDK client credentials for a short-lived bearer token when client-credentials mode is in use.

protection_plan takes workload and resource metadata and returns a local-enforcement plan for a proposed protect, access, or rewrap. policy_resolve returns authorization and handling guidance decoupled from a specific artifact profile or key workflow. key_access_plan returns the local cryptographic steps for a wrap, unwrap, or rewrap flow. artifact_register records the resulting protected-artifact metadata, digest, profile, optional stable CID, and optional Merkle-root CID for multi-object artifacts, after local protection completes. evidence ingests metadata-only events tied to protected artifacts and policy decisions for the Immutable Ledger.

Every request and response on this surface is a metadata structure. No route in /v1/sdk/* accepts or returns raw document bytes or prompt text. Every response includes the resolved caller block (tenant_id, principal_id, subject, auth_source, scopes) so the caller can branch on identity and scope exactly rather than on parsed English error messages.

Local embedded-protection helpers

The control plane answers decisions. The data-plane work, producing and consuming envelopes, TDFs, and detached signatures, happens in the caller's process, through a parallel set of embedded-protection helpers that each SDK ships alongside the nine control-plane operations.

The helper families present across all three bindings are consistent: local planning and CID binding (prepare_local_protection, generate_cid_binding in Rust and Python; PrepareLocalProtection, GenerateCIDBinding in Go), envelope protect/access/rewrap, TDF protect/access/rewrap with attribute-update helpers, detached-signature sign/verify, and managed symmetric-key providers that the caller registers with the SDK at construction time. The method names follow each language's normal conventions: the Rust crate uses builder-style, the Go module uses Options-style, and the Python package uses async with Pydantic models under lattixsdk.models.

The division of labor is clean. The helpers never surface plaintext to the platform. They do surface caller-stable CIDs and content digests back to the control plane through artifact_register and evidence, so the Immutable Ledger carries a cryptographically verifiable record of which exact object each decision was made against. Merkle-root CIDs are a first-class field on both registration and evidence for artifacts composed of multiple objects.

Three bindings, one core

Rust is the canonical core. The Rust crate on crates.io owns HTTP behavior, contract serialization, and platform semantics. The Go module at github.com/LATTIX-IO/sdk-go-public is a CGO bridge over the same native core. The Python package lattix-sdk-python on PyPI (import lattixsdk) exposes the core through a ctypes bridge and presents an async API with Pydantic models that mirror the platform contract.

Rust is the right choice when an application wants the minimum dependencies, the native builder surface, and direct access to the full local-helper feature set. Go fits sidecars, gateways, and service-mesh enforcement where the Rust native library ships alongside the Go binary. Python fits data pipelines, notebooks, and orchestrated workloads where the async surface and Pydantic models carry the integration weight.

The three bindings are version-aligned. When the Rust core is released, the matching Go and Python packages are released against the same control-plane contract. Per-language reference lives with each package, docs.rs/sdk-rust for Rust, pkg.go.dev for Go, and the PyPI README and lattixsdk.models for Python, and is not duplicated on the docs site.

Authentication

The Platform API surfaces three auth modes on the capabilities and bootstrap responses: bearer_token for the normal public integration path, trusted_headers for controlled environments where a private deployment terminates authentication at ingress and injects caller identity, and bearer_token_or_trusted_headers as a compatibility mode in which a bearer token takes precedence when both are available. External clients should prefer the bearer-token flow regardless of what a given deployment also supports.

The two public credentials patterns are bearer token and SDK client credentials. Bearer-token mode attaches a pre-issued JWT in the standard Authorization: Bearer ... header; in Rust, Client::builder(base_url).with_bearer_token("..."); in Go, sdk.Options{ BearerToken: "..." }; in Python, LattixClient(bearer_token="..."). SDK client-credentials mode exchanges a client_id, client_secret, tenant_id, and requested_scopes at POST /v1/sdk/session for a short-lived bearer token, cached and refreshed automatically by each SDK. The session-exchange route is the only route with a published rate limit; 429 responses include a Retry-After header in seconds. Credentials are never sent on any route other than /v1/sdk/session.

Scope-based authorization runs through every route. Each route publishes its required scopes on the capabilities response, so a well-written client discovers the scope graph at startup and can present exactly the claims each operation requires. 403 responses identify the missing scopes by stable machine-readable codes, not English strings.

What the SDK is and is not

The SDKs are the embedded-enforcement path for the Zero Trust Fabric. They are how applications participate in Lattix protection flows without giving up locality over their own data. They interpret key-handling guidance against the Hierarchical Key Model, register protected artifacts against the Immutable Ledger, and emit evidence events on the same structure.

They are not a data-in-motion gateway, a CASB shim, or a classification scanner. Those capabilities exist in the platform as separate products. The SDK's scope is the primitive that every higher-level integration composes against, and keeping it tight around the nine control-plane operations plus the embedded-protection helpers is what makes the contract auditable.

Getting started

Read the SDK overview at /docs/sdks for the conceptual model and pick the binding that fits the workload. Follow the quickstart at /docs/sdks/rust, /docs/sdks/go, or /docs/sdks/python. Open the API Explorer at /docs/api/explorer for a browsable reference generated from the same OpenAPI document the SDKs are built from. If you are generating your own client, use /openapi/sdk-control-plane.yaml as the source of truth.

The developer preview is live. Reserved language on production commitments remains in force for named deployments, and the contract surface is frozen for the preview window. Feedback on the OpenAPI shapes, the nine-operation mapping, the embedded-protection helper surface, and the artifact-profile set is the specific signal the team is listening for before graduation to general availability.