Retrieval ignores the person
A search finds relevant records, but relevance alone does not establish whether this user and purpose are allowed to use them.
Benefit / Trust & Control
Your data reaches a model
only when it’s allowed to.
An authorized question is not permission to send an entire customer record to any available model. Frozion governs retrieval, context, tool responses and model routing so the data path follows the purpose of the work.
Allowed for this person. Needed for this task. Approved for this model.
FROZIONExecution FabricGoverned from request to outcome
- Retrieve within permission
Identity, tenant and resource scope determine the eligible records.
- Prepare only the needed inputs
Declared context and tool-response policies limit what enters the model request.
- Route within the boundary
Classification, region and handling rules determine the eligible model.
If no approved model is available, the request waits or follows its configured exception path.
01 / The challenge
Data exposure starts
before the model answers.
The final answer can look harmless even when the request sent unnecessary or unauthorized information to a provider. Control the inputs and the destination, not just the words returned.
The whole record becomes context
An agent needs a refund status and receives the customer’s wider account history. A tool response adds even more fields than the task requires.
Fallback crosses the boundary
An approved model is busy. A fallback that considers only availability can send the same context to a provider or region the data was never cleared for.
02 / How it works
Four checkpoints.
One governed data path.
The controls work together: permission determines what can be retrieved, context determines what is needed, tool policies govern returned data and routing determines where the resulting request may go.
1 / Permission-aware retrieval
Scope retrieval to the initiating identity, tenant, resource permissions and business purpose. A useful match still has to be an authorized match.
2 / Declared context
Supply the fields and facts the task expects. Keep their source, scope and freshness attached so the next step can distinguish a usable input from missing or stale information.
3 / Governed tool responses
Apply configured response policies at the governed tool boundary, including redaction of designated sensitive fields. A tool’s ability to return a field does not mean the model needs it.
4 / Eligible model routes
Filter model routes by data classification, provider, region and handling requirements before applying availability or cost preferences. Keep those constraints on fallback routes too.
03 / In practice
A refund question.
Only the context it needs.
A support representative asks why a refund is pending. Follow the sample request from retrieval to the approved model boundary.
Support case CS-5102 · sample data
Follow each checkpoint before a model receives the request.
Checkpoint 1 / permission
Relevant is not the same as authorized.
Of 40 candidate records, six match the user’s permitted customer and case scope. The model receives no permission to inspect the other records simply because the search found them.
Retrieval scope
- Identity
- Assigned support representative
- Tenant & case
- Customer organization · CS-5102
- Candidates
- 40
- Eligible records
- 6
- Remaining records
- Excluded from the task’s retrieval result
Checkpoint 2 / purpose
Answer the refund question.
The task requires refund status, the recorded reason and the applicable policy. The declared input leaves unrelated account details out of this model request. Source and freshness information stay connected to the facts.
Task inputs
- Included
- Refund status and recorded reason
- Included
- Applicable refund-policy version
- Not requested
- Home address and full payment history
- Freshness
- Required status checked before use
Checkpoint 3 / response policy
A returned field is not automatic model context.
The refund lookup returns a designated sensitive field. The configured tool-response policy redacts it before the response is passed into model context. Policies must identify the fields and transformations needed for this integration.
Governed response
- Tool
- Refund case lookup
- Response policy
- Restricted-field redaction
- Useful case facts
- Retained for the task
- Designated sensitive field
- Redacted before model input
Checkpoint 4 / destination
A busy approved route does not justify an unapproved one.
This request is restricted to an approved private model in the EU. That model is temporarily unavailable; the managed route does not meet the request’s rules. The case waits. An answer can be produced after an eligible route becomes available.
Routing decision
- Data requirement
- Restricted · approved EU handling
- Private route
- Eligible · temporarily unavailable
- Managed route
- Ineligible for this request
- Current state
- Held · no model answer yet
- Next step
- Resume on an eligible route
04 / By role
Give every data decision
an accountable boundary.
Security, privacy and data teams can review where information enters the process and which rules govern its use.
CISO
Inspect the path from an authorized identity to retrieval, tools and model destinations. Keep fallback behavior inside the same policy boundary.
Control the path to the model.Privacy & compliance
Connect the business purpose to the fields used and the approved handling requirements. Review the available evidence with appropriate access.
Explain why this data was used.Data owners
Define useful task inputs with sources, scope and freshness. Stop treating the largest available record as the best possible context.
Share the right facts for the task.05 / Scope and questions
Keep the boundary explicit.
Keep the task useful.
Data minimization, response policies and eligible model routes are application decisions that can be inspected and maintained as the work changes.
Deployment and routing work together
Running in your cloud gives you placement control. Separately approve model endpoints, connected systems and evidence destinations. Hosting location alone does not determine every data flow.
Useful context still needs evaluation
Removing fields can change the answer a model can produce. Define the required inputs and evaluate the task with its permitted context, including the path for missing information.
It governs the retrieval, context, tools and model calls integrated with Frozion. Begin with the paths that handle sensitive work and make their coverage explicit.
No. A task may need a different permitted input or may have to pause for missing information. Evaluate the answer and its business purpose within the allowed data boundary.
Yes. Define which routes are eligible for each task and data classification. Availability and price preferences operate within those eligibility constraints.
No. Evidence contracts and retention settings determine what is retained, referenced and visible. A protected reference is different from retaining the full original payload, and access remains permissioned.
Start with one business process
Map the path
your sensitive data takes.
Bring one agent or application that handles sensitive records. We’ll define what it may retrieve, what the task needs and which model destinations are allowed.