Field-Level Security

FLS dynamically evaluates a user's security context against field-level metadata to determine visibility. Instead of blocking an entire document, the system selectively redacts or tokenizes specific fields like Social Security Numbers, salaries, or internal project codes.

• Dynamic Evaluation: Policies are evaluated at query time, not index time.
• Conditional Logic: Access can depend on user role, location, and device posture.
• Partial Exposure: A manager might see a salary field, while a peer sees a [REDACTED] placeholder.

The critical architectural placement of FLS is in the post-retrieval, pre-generation phase. After the vector store returns relevant chunks, a Policy Enforcement Point (PEP) strips unauthorized fields before the text is injected into the LLM's context window.

• Zero-Trust Context: The LLM never receives the raw sensitive data.
• Irreversible Redaction: Text is physically removed, not just hidden via CSS.
• Schema-Aware: The system understands JSON paths and XML tags to target nested fields precisely.

FLS implementation differs significantly based on the data format. For structured data (JSON, databases), field paths are explicit. For unstructured text (PDFs, Word docs), the system relies on Named Entity Recognition (NER) to identify sensitive spans.

• Structured: Uses JSONPath or XPath to target $.employee.salary.
• Unstructured: Uses regex patterns and machine learning classifiers to find PII.
• Hybrid: Combines metadata filtering with in-text redaction for maximum coverage.

In scenarios where data utility must be preserved for the LLM's reasoning, FLS can use Format-Preserving Encryption instead of simple redaction. This replaces a sensitive value with a ciphertext that maintains the original data type and length.

• Schema Integrity: A 16-digit credit card number is replaced with a 16-digit token.
• Referential Integrity: The same plaintext always maps to the same ciphertext, allowing the LLM to perform joins.
• Downstream Decryption: Authorized systems can reverse the tokenization post-generation.

FLS relies on Identity Propagation to function correctly. The end-user's authenticated context must be securely transmitted from the application layer through the retrieval pipeline to the field-level authorization engine without degradation.

• Header Forwarding: User JWTs or SAML assertions are passed to the retrieval service.
• Impersonation Prevention: The retrieval service verifies the token's integrity before applying policies.
• Contextual Attributes: Beyond identity, signals like geolocation and device risk score inform field-level decisions.

Every field-level access decision must be logged for forensic analysis. The audit trail captures not just which document was retrieved, but precisely which fields were exposed or masked for a specific user session.

• Granular Logs: Records include field_path, action (masked/revealed), and policy_id.
• Immutable Storage: Logs are written to append-only storage to prevent tampering.
• Compliance Mapping: Directly supports GDPR 'data minimization' and PCI DSS 'masking' requirements.