Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

Solution Overview

Superna Data Security for AI Infrastructure exists to answer a question that Kubernetes alone cannot: "who accessed or changed this data?" This page explains the problem it solves and how the product delivers it. The rest of the documentation covers each workspace in detail.

The traditional security model breaks in Kubernetes​

The legacy security model assumed a fixed user identity tied to a fixed host on static infrastructure. Kubernetes invalidates those assumptions:

  • Applications run as pods, not fixed servers.
  • Pods are ephemeral and dynamically scheduled across hosts. They move on failures, load balancing, scaling events, and scheduled jobs.
  • Data is mounted automatically through Persistent Volume Claims (PVCs).

As a result, data access can originate from any pod, on any host, at any time. This makes it extremely difficult to attribute who read or changed a given dataset.

The Kubernetes visibility gap​

Kubernetes itself does not provide:

  • Data-level audit logs — create, read, update, delete, and ACL changes.
  • Traceability of data access — there is no built-in linkage from user → pod → host → data.
  • Attribution of data changes — there is no way to identify which application or job modified data.

Why this matters for AI​

AI pipelines rely heavily on shared data, such as training datasets, RAG document stores, embeddings, and model artifacts. Without data-level visibility:

  • Data can be accessed, modified, or exfiltrated without attribution.
  • AI systems can be silently compromised.

The lack of data-level auditing and traceability creates a critical gap:

  • No ability to track data changes.
  • No end-to-end data-access lineage.
  • No attribution to a user or application.

This results in compliance risk (audit and regulatory requirements) and data-security exposure.

Key insight: without the ability to trace user → pod → host → data → change, AI data in Kubernetes is fundamentally unprotected and unauditable.

How the platform closes the gap​

The platform delivers the following capabilities. Each maps to a workspace documented elsewhere in these docs.

  • Unified topology of workloads and data access — a single, real-time map linking user → pod → PVC → storage → data, so you can see exactly who is accessing what data, and from where. See Data Security Posture.
  • Storage audit logs connected to Kubernetes context — raw file and object events are ingested and enriched with Kubernetes metadata, turning them into fully attributed actions tied to pods, users, and namespaces. See File Activity.
  • Visibility into sensitive data across PVCs — data is continuously discovered and classified across volumes, highlighting PII exposure and high-risk datasets in real time. See AI Risk Pipeline and Security Metrics.
  • Accountability for AI/ML workloads — a complete accountability chain from user → AI workload → data accessed, enabling traceability, governance, and insider-risk detection.