Building a Local Data Vault for AI Applications: A Look Inside Securelytix

Building a Local Data Vault for AI Applications: A Look Inside Securelytix

AI applications are becoming increasingly connected.

An application might send data to an LLM, an AI agent might call an internal API, that API might query a database, and the resulting context could pass through several third-party services.

The problem isn't always the AI model itself.

The bigger question is:

Where does sensitive data go before, during, and after an AI request?

Email addresses, phone numbers, government IDs, payment information, and customer records can end up in prompts, logs, traces, vector databases, third-party APIs, or model context.

This is the problem we built Securelytix Data Vaulting to address.

The core idea is simple:

Replace sensitive values with meaningless tokens before they enter an AI or external processing path.

This article looks at the architecture and low-level design behind the Securelytix Data Vault.

The Core Architecture

Securelytix sits between the application and the systems that process sensitive data.

The architecture has three primary areas:

1. Client tier — application, API gateway, pipeline, or AI application
2. Customer infrastructure — Securelytix SDK/Vault runtime and customer-managed PostgreSQL
3. Securelytix platform — licensing and observability services

The key design decision is that the vault runtime runs inside the customer's infrastructure.

This allows tokenization to happen locally before sensitive values move downstream.

1. Tokenization Without Rebuilding the Application

The first design goal was developer experience.

We didn't want teams to rewrite their application architecture just to introduce data protection.

The client can be an existing application, API gateway, data pipeline, backend service, or AI application.

The application communicates with the local Securelytix runtime through simple HTTP APIs:

POST /api/v1/tokenize
POST /api/v1/detokenize

For example:

{
"email": "[e-mail]",
"name": "John Doe"
}

The vault replaces sensitive values with non-sensitive references:

{
"email": "ufmcqfarg.abx_stx",
"name": "rtfs2hvp2d_stx"
}

The exact token format isn't important to the application.

What matters is that downstream systems no longer need the original value.

1. Tokenization Happens Locally

The Securelytix SDK can run as a pod or container inside the customer's Kubernetes or Docker environment.

The basic flow is:

Application
|
| POST /tokenize
v
Securelytix SDK
|
| store mapping
v
Customer PostgreSQL

The sensitive data doesn't need to travel to a remote Securelytix service just to be tokenized.

Instead, the tokenization boundary exists inside the customer's infrastructure:

Application
|
v
Securelytix SDK
|
v
Token
|
v
AI / External APIs

This can be particularly useful for organizations with data residency, compliance, or network isolation requirements.

3. PostgreSQL as the Token Store

Securelytix uses a customer-managed PostgreSQL instance as the token store.

The customer's data therefore remains within the customer's infrastructure and existing database controls.

Conceptually:

Securelytix SDK
|
| Parameterized SQL
v
PostgreSQL
|
+-- Token mappings
+-- Vault data

From the application's perspective, the token is simply a safe reference.

4. Tokenization vs. Detokenization

These are intentionally separate operations.

Tokenization
Sensitive value
↓
Securelytix
↓
Token
Detokenization
Token
↓
Securelytix
↓
Original value

An application doesn't need the original value everywhere just because one service needs it.

If an authorized business operation requires the original value, the application can request it through:

POST /api/v1/detokenize

This creates a clearer boundary around where sensitive data is actually required.

5. Why Run the SDK as a Pod?

For Kubernetes environments, the SDK can run as its own pod:

`Kubernetes Cluster

Application Pod
|
HTTP
|
v
Securelytix SDK Pod
|
SQL
|
v
Customer PostgreSQL`

This gives platform teams a familiar deployment model.

For Docker-based environments, the same concept can be implemented using containers.

6. Licensing and Machine Identity

The architecture also separates licensing from the core tokenization path.

The runtime can use configuration such as:

API_KEY
DATABASE_URL
LICENSE_PUBLIC_KEY

Licensing communication can use endpoints such as:

/api/v1/validate-license
/api/v1/sync-usage

The important architectural principle is that licensing remains separate from the actual tokenization data path.

The SDK should not need to send every tokenization request through an external licensing service.

1. Observability as a Separate Layer

Security systems still need to be observable.

Securelytix uses OpenTelemetry for logs, traces, and metrics.

These signals can flow into an OpenTelemetry collector and then into monitoring systems such as Grafana.

Securelytix SDK
|
+-- Logs
+-- Traces
+-- Metrics
|
v
OTel Collector
|
v
Observability

This separation is deliberate.

Operational telemetry should help teams understand what the system is doing without becoming another place where sensitive payloads are unnecessarily duplicated.

8. What Happens to a Real Request?

Consider an application receiving:

{
"customer": {
"email": "[e-mail]",
"phone": "+91XXXXXXXXXX"
}
}
Step 1: Application receives the request

The application processes the request normally.

Step 2: Application calls the local vault
POST /api/v1/tokenize

Sensitive fields are sent to the local Securelytix runtime.

Step 3: Securelytix creates tokens

The runtime generates token references and stores the required mapping in customer-managed PostgreSQL.

Step 4: Application continues with tokenized data

Instead of:

{
"email": "[e-mail]"
}

the downstream workflow receives something like:

{
"email": "tok_abc123"
}
Step 5: The token moves through the AI workflow
Application
↓
AI Agent
↓
LLM
↓
Tool / API
↓
Database

The original email address isn't required at every stage.

Step 6: Detokenization happens only when required

An authorized operation can call:

POST /api/v1/detokenize

and retrieve the original value when there is a legitimate business need.

9. Why This Matters for AI Agents

AI agents make the data-flow problem larger.

An agent might have access to:

CRM
Jira
Slack
GitHub
Databases
Internal APIs
Cloud services
LLMs
Third-party tools

A customer record can therefore travel through multiple systems:

Database
↓
Agent
↓
Prompt
↓
LLM
↓
Tool
↓
API
↓
Logs / Traces

Instead of trying to secure every downstream system individually, data vaulting addresses the problem earlier:

Does every system actually need the sensitive value?

If an application can operate on a token instead of an email address, phone number, customer ID, or other sensitive value, fewer systems need access to the original data.

1. Local Runtime vs. Remote Privacy API

There is an important architectural difference between a local vault and a centralized privacy API.

With a remote service:

Application
|
| Sensitive data
v
Remote Privacy Service
|
v
Token

The sensitive data has already crossed a network boundary.

With a local runtime:

Application
|
| Sensitive data
v
Local Securelytix SDK
|
v
Token
|
v
External Systems

The tokenization boundary exists much closer to the application.

For organizations with strict data residency, compliance, or network isolation requirements, that difference can matter significantly.

11. Separating the System Into Failure Boundaries

The architecture separates three major concerns.

Data Plane
Application
↓
Securelytix SDK
↓
PostgreSQL

Handles tokenization and detokenization.

Control Plane
Securelytix SDK
↓
License Backend

Handles licensing-related communication.

Observability Plane
Securelytix SDK
↓
OTel Collector
↓
Monitoring

Handles logs, traces, and metrics.

Separating these paths makes the system easier to reason about and prevents unrelated services from becoming dependencies for the core data path.

12. The Developer Experience

Security products often become difficult to adopt when they require developers to completely change their applications.

The goal with Securelytix Data Vaulting is much simpler:

tokenize()
↓
use token
↓
detokenize() when required

Instead of forcing teams to:

rewrite application
rewrite database
rewrite AI integration
rewrite APIs
rewrite infrastructure

the security layer should fit into the architecture developers already have.

Final Thoughts

AI security isn't only about securing the model.

The real data path can look like:

User
↓
Application
↓
Agent
↓
LLM
↓
Tools
↓
APIs
↓
Databases
↓
Logs

Sensitive data can leak at any of these points.

A data vault changes the question from:

"How do we secure every system that receives sensitive data?"

to:

"How many systems actually need the sensitive data in the first place?"

Securelytix Data Vaulting is built around that principle.

The runtime stays inside the customer's infrastructure, uses customer-managed PostgreSQL for token storage, exposes simple tokenization and detokenization APIs, and keeps licensing and observability as separate infrastructure concerns.

For developers, the goal is straightforward:

Protect sensitive data before it enters the wider application and AI ecosystem — without rebuilding the applications you already have.