Security: encryption, audit, and protection

What it is

Security is the “is this data protected?” layer of a governed data product. It covers encryption (at rest and in transit), access control (who can see what — often implemented via governance), and audit logging (who accessed what and when). Without security, context that’s rich and consumable can still be exposed or misused. In Loxtep, a governed data product is designed with security in mind so the context we deliver is protected end to end. The platform processes data in the United States, in a single region — the same posture described in our privacy policy.

How it’s made

Security for a governed data product is implemented and documented as follows:

• Encryption. Encryption at rest and in transit is the default for data the platform stores and serves. Keys are managed with a key store (for example, AWS KMS). A cipher such as AES-256, a TLS version such as TLS 1.3, and a key-rotation cadence are examples of how those controls can be described in metadata — illustrations, not a guaranteed rotation schedule or TLS version.
• Access control. Access is enforced at the consumption layer (and at pipeline layer for writes): every request is authenticated (e.g. JWT or API key) and authorized against the asset’s governance policies. Denied requests get 403 and are logged; no data is returned. So “security” and “governance” work together: governance defines who can do what, security enforces it at runtime.
• Audit logging. Access to an asset, and changes to its definition, can be logged: who, when, and what. An illustrative request shape is GET /context/orders/4821 — that path is an example, not a shipped route. How long those logs are kept (for example, a multi-year retention window) is an illustration of a retention choice, not a fixed platform guarantee. The trail supports compliance and incident response.
• Processing location. Loxtep processes data in the United States, in a single region, consistent with our privacy policy.

Example security metadata for a governed data product:

{
  "security": {
    "encryption": {
      "at_rest": "AES-256",
      "in_transit": "TLS 1.3",
      "key_management": "KMS; rotation 90d"
    },
    "access_control": "Enforced at API and pipeline; see governance.access",
    "audit": {
      "access_logged": true,
      "retention": "7y",
      "fields": ["actor", "timestamp", "resource", "action", "result"]
    },
    "processing_location": "United States"
  }
}

In Loxtep, encryption at rest and in transit is the default, alongside access control and audit logging. The KMS rotation cadence, TLS version, and audit retention period in the example above are illustrations of how those controls can be described — examples, not guaranteed settings. Processing stays in the United States.

Why it matters for governed data products and AI

Context that contains customer, order, or financial data must be protected. By making security a first-class part of the governed data product story, you ensure that the context you build and deliver is encrypted, access-controlled, and auditable. For AI, that means the model receives context through a secure, logged channel — and you can prove who had access to what. In Loxtep, a governed data product is designed to be protected so the context we deliver is not only useful but safe.