← Back to Blogs
HN Story

Implementing Data Level Access Control with CipherStash Stack

May 22, 2026

Implementing Data Level Access Control with CipherStash Stack

In the traditional security model, application access is centered around a human user behind a session. However, the rise of AI agents—which chain tools, spread data through prompts, and operate across logs and traces—breaks this assumption. When an agent acts on behalf of a user, it often inherits broad permissions that create significant security risks if the agent is compromised or prompt-injected.

CipherStash Stack introduces Data Level Access Control (DLAC), a paradigm shift that moves security from the perimeter or the row level down to the individual data value. By ensuring that each piece of sensitive data carries its own encryption and that the right to decrypt is bound to a specific identity, CipherStash ensures that protection travels with the data wherever it goes.

The Five Pillars of CipherStash Stack

CipherStash Stack is designed as a set of composable building blocks, allowing teams to adopt DLAC incrementally—one field at a time—rather than through a "big-bang" migration.

1. Value-Level Encryption

Unlike encryption-at-rest, which protects the disk, CipherStash provides searchable encryption for individual fields. Using EQL, Postgres can perform filters, sorts, and joins directly over ciphertext. This means data remains encrypted not just at rest and in transit, but also in use.

2. ZeroKMS Key Management

Managing a unique data key for every single value would typically be computationally expensive. ZeroKMS solves this by acting as a hyper-fast key service backed by AWS KMS. It is reported to be up to 14x faster than calling AWS KMS directly, eliminating the need for complex application-side key caching.

3. Transparent SQL Proxy

For legacy applications or BI tools where code changes are impossible, the CipherStash Proxy sits between the app and Postgres. It transparently rewrites SQL statements, encrypting parameters on the way in and decrypting results on the way out, allowing developers to use plain SQL while maintaining DLAC.

4. Identity-Bound Auth

CipherStash integrates with OIDC providers (such as Auth0) to ensure that decryption is authorized against a real end-user identity. This removes the reliance on shared service accounts or long-lived keys; the CipherStash Token Service verifies and maps claims on every decryption request.

5. Agent Skills

To prevent the common pitfall of developers (or AI agents) "hand-rolling" encryption, CipherStash provides agent skills. These are documented building blocks that allow AI coding assistants to implement the stack correctly the first time, ensuring security decisions are captured as reviewable code in pull requests.

Technical Implementation in TypeScript

Implementing DLAC starts with defining an encryption schema. Developers can specify which fields are encrypted and what type of searchable operations are required:

import { encryptedTable, encryptedColumn } from '@cipherstash/stack/schema';

export const users = encryptedTable('users', { 
  email: encryptedColumn('text').equality().freeTextSearch(),
  meta: encryptedColumn('json').searchableJson(),
});

Once the schema is defined, the SDK handles the encryption and querying process:

import { client } from '@cipherstash/stack';
import { users } from './encryption/schema';

// Encrypting a value for insertion
await db.insert(users).values({
  email: await client.encrypt('alice@example.com', { column: users.email }),
});

// Querying using an encrypted term
const needle = await client.encrypt('alice@example.com', { column: users.email });
const rows = await db.select().from(users).where(eq(users.email, needle));

DLAC vs. Traditional Security Models

It is important to distinguish DLAC from other common database security strategies:

Strategy Protection Level Weakness
Transparent DB Encryption Disk/Physical Does nothing against stolen credentials; DB hands plaintext to any logged-in user.
Row-Level Security (RLS) Row/Policy Policy lives in DB config; DB still reads plaintext to evaluate the policy.
Tokenization Vaults External Every read requires a round trip to the vault, complicating application logic.
CipherStash DLAC Value/Cryptographic Protection is a property of the data itself. Misconfigured rules result in ciphertext, not plaintext leaks.

Securing the AI Agent Workflow

In the CipherStash model, agents are treated as first-class identities. Rather than borrowing a human's session, an agent has its own keys and policies. Because enforcement happens at the encryption layer, an agent only sees decrypted bytes for fields it is explicitly authorized to access.

This architecture provides a critical safeguard against prompt injection. If an agent is manipulated into exfiltrating data, it cannot leak what it does not hold the keys for. While Row-Level Security might limit which rows an agent can fetch, CipherStash limits what it can actually read within those rows.

Performance and Production Scale

CipherStash claims to protect over a billion values in production across highly regulated industries, including energy (Amber Electric), healthcare (Journalia), and financial compliance (BNDRY). Performance benchmarks on a 10-million-row dataset show a median of 454μs for exact-match queries and 1.46ms for range queries, demonstrating that value-level encryption does not have to come at the cost of significant latency.

References

HN Stories