Architecture / AIGIS resources
Field-level security for LLMs is different from field-level security in a screen or report. If a model sees a redacted field name, it can still reason about the field's existence. AIGIS removes the field before the prompt is built.
Executive read
LLM field-level security must control both values and structure.
Masking hides values but can reveal field names and relationships.
Field stripping removes inaccessible fields before the model sees context.
The same control must apply to summaries, answers, write proposals, and tool calls.
Analysis
A traditional app can show a redacted value and still be safe enough for the user's workflow. A language model is different because it can reason about the existence of the redacted field.
If the prompt contains Salary__c: [redacted], the model has learned that salary exists, that it is relevant, and that it may relate to the user's question.
AIGIS removes inaccessible fields before the prompt is assembled. The model is not asked to ignore forbidden data because the forbidden data never arrives.
That makes the LLM's reasoning boundary match the user's permission boundary.
A write proposal can leak just as much as a read. If the AI suggests changing a field the user cannot edit, the proposal itself has crossed the governance line.
AIGIS checks write permissions before proposal and again when the human confirms the write.
Comparison
Keep reading
Architecture
Why LLM field-level security should remove inaccessible fields before prompt construction instead of sending masked placeholders to the model.
Architecture
A practical architecture for enterprise AI governance middleware: identity resolution, live record checks, field stripping, model routing, write approvals, and audit provenance.
Use case
How to prevent Salesforce data leakage in AI systems with live record checks, field stripping, prompt minimization, write approvals, and permission provenance.