Data-in-use protection: beyond the database firewall

What a database firewall does well

Database activity monitoring and database firewalls sit between clients and the database. They inspect queries, block dangerous statements, alert on unusual access and produce an audit trail that many regulations ask for. For direct access by administrators and legacy applications, they remain useful. Rules that block, mask or alert by operation, table and role are a sensible baseline.

Their limitation is position. A database firewall sees a query from an application service account. It does not see which end user asked for the data, which API returned it, which partner received it or which AI tool summarised it. Once rows leave the database through a legitimate query, the firewall’s view of them ends.

Where data actually flows

Modern applications rarely let people query databases directly. Data moves through services, internal APIs, partner integrations, reporting pipelines and, increasingly, AI assistants and agents that call tools on a user’s behalf. Each hop is a place where a sensitive field can be over-exposed: an API that returns a full customer record when only a name was needed, an export job that copies identity numbers into a less protected store, an AI tool that receives more context than its task requires.

From the database’s point of view, every one of these is a normal, authorised query. The exposure happens later, in use. That is why protecting data at rest and watching queries at the perimeter, while necessary, is not sufficient.

Protecting data in use, field by field

Field-level protection starts from a different question: not "may this query run?" but "what should this field look like to this caller, for this purpose?". A support agent may see the last four digits of an account number. An analytics job may need a consistent token it can join on, without the real value. A matching service may need to search on an identifier without ever reading it. A regulator export may need the full value under strict audit.

Several established techniques serve these needs: role-based masking, tokenisation, format-preserving and authenticated encryption, searchable encryption such as blind indexes, and, for some computations, homomorphic encryption that lets certain operations run on encrypted values. The choice depends on what the field is used for. The common thread is that the protection follows the field, rather than stopping at the database edge.

This depends on knowing which fields are sensitive. Classification of columns, ideally done locally so that samples of personal data never leave the environment, is the foundation that every policy builds on.

Governed APIs over raw database access

The most effective change is often architectural: stop handing out raw database access and expose data through governed APIs instead. Good governed data APIs share a few traits:

• Read-only by default, with write operations added deliberately.
• Parameterised queries only, never built by joining strings.
• Mandatory paging and row limits, so a single call cannot dump a table.
• Field-level policies applied to both requests and responses.
• Clear ownership, purpose and sensitivity recorded for each endpoint.
• Every call logged with caller, purpose and fields returned.
• Credentials held in a secrets manager and referenced, never pasted inline.

Compliance and data sovereignty

Data protection regulations generally ask organisations to limit personal data to what is necessary, control who can access it, and show evidence that they do. Field-level policies map naturally to these principles: they express minimisation and purpose limitation in a form that can be enforced and audited, rather than only described in a policy document.

Sovereignty adds another dimension. Many organisations must keep sensitive data, and the keys that protect it, within a country or within their own infrastructure. Protection that runs on-premises, with keys under the organisation’s control and classification that does not send samples to an external cloud, makes that easier to demonstrate. As AI tools become new consumers of data, the same controls decide what those tools are allowed to see.

How ApexAI approaches it

ApexAI Data Gate is designed as next-generation data security rather than another database firewall. The platform already supports secure database onboarding with referenced credentials, local column classification and field-level protection policies, including masking, encryption, blind indexes and homomorphic encryption, with per-tenant access rules that start in dry run and log every decision. Turning databases into governed, protected APIs on the ApexAI API Gateway, with field policies on requests and responses, is in development. Data and keys stay in your environment.

Questions