Field-Level Security

Unlike Document-Level Security, which blocks entire files, FLS operates at the attribute level. This allows a single document to serve multiple audiences by dynamically hiding sensitive columns or fields.

• Mechanism: The system checks the user's clearance against an Access Control List (ACL) for each field.
• Example: A medical record displays 'Name' and 'Blood Type' to a nurse, but masks 'HIV Status' and 'Genetic Markers' unless the viewer has a specific OAuth 2.0 Scope.

FLS often utilizes Dynamic Data Masking to obfuscate data in real-time without altering the stored value. The original data remains intact in the database, but the presentation layer redacts it based on the user's session.

• Static Masking: Permanently alters the data copy (used in non-production).
• Dynamic Masking: Masks data at query time (used in production).
• Example: A Social Security Number (SSN) stored as 123-45-6789 is rendered as XXX-XX-6789 for a customer service agent, enforced by the Policy Enforcement Point (PEP).

In structured data systems, FLS is often defined at the schema level. Administrators configure permissions on specific columns in a table or keys in a JSON document.

• Role-Based Access Control (RBAC): Permissions are bundled into roles (e.g., 'Payroll Admin' can see salary; 'Manager' cannot).
• Attribute-Based Access Control (ABAC): Access is granted if user attributes (department, clearance) match the field's sensitivity tag.
• Implementation: This is critical for Retrieval-Augmented Generation (RAG) systems, where the retriever must filter vector metadata fields before passing context to the LLM.

In search and AI retrieval pipelines, FLS can be applied at two distinct stages to prevent data leakage:

• Pre-Retrieval Filtering: The user's security credentials are attached to the query. The index only searches documents where the user has access to the specific fields requested. This is highly efficient.
• Post-Retrieval Filtering: The system retrieves all relevant documents first, then redacts unauthorized fields from the results. This is easier to implement but risks leaking metadata or wasting compute on inaccessible data.
• Best Practice: Pre-Retrieval Filtering is preferred for Zero Trust Architectures (ZTA).

For highly sensitive fields like credit card numbers, FLS can be combined with Tokenization. The original value is replaced with a non-sensitive equivalent (a token) that retains the original data format.

• Format-Preserving Encryption (FPE): Encrypts data while keeping the length and character set identical to the plaintext.
• Use Case: A billing system can process a tokenized credit card number without the application logic ever touching the real Primary Account Number (PAN).
• Compliance: This is essential for reducing PCI DSS scope.

Every access or denial of a specific field must be recorded in an Immutable Audit Trail. This provides forensic visibility into who viewed sensitive attributes.

• Log Content: Timestamp, User ID, Document ID, Field Name, Access Decision (Granted/Denied).
• Insider Threat Detection: Anomalous access patterns (e.g., an HR employee suddenly viewing executive salary fields) trigger alerts.
• Regulatory Compliance: Proves adherence to Data Sovereignty laws and Least Privilege Principle during audits.