In the source system
- Company
- Example Company
- Contact
- maya@example.test
- Deal value
- €148,000
Connector replaces selected values
More control as you grow
Set rules for sensitive data.
Specify which information to keep out of model-facing connector results. Configure one Data Protection Policy for your tenant; it is included in agent instructions for projects in that tenant. Connectors can omit fields, return summaries or replace private values with placeholders.
You describe the rule. Code handles the substitution.
A policy guides the agent’s implementation. The connector’s code applies the rule before returning data to the model; Hodman’s delivery code restores supported placeholders for the human-facing reply.
- 01
Describe what to protect
For example: keep customer names, email addresses and tax IDs out of model-facing results. Allow deal totals and pipeline stages.
- 02
Build and check the connector
Agents use the policy when building, updating and reviewing connector and tool code. Ask an agent at any time to audit a specific project against the tenant policy; existing connectors may need changes.
- 03
Send placeholders to the model
In covered connector results, selected values are replaced before the model sees them. Reversible values are stored in a mapping in the project database.
- 04
Restore values for people
When showing a supported reply, the platform resolves placeholders through the project runtime and substitutes the values in code. The model-facing history keeps placeholders. Unresolved placeholders stay visible.
Illustrative example · fictional data
The model can discuss a deal using an alias.
This example keeps the deal value available for the task, while replacing the company and contact. Your policy decides which fields are appropriate to share.
In the covered model input
- Company
- Company-17
- Contact
- Person-9
- Deal value
- €148,000
Follow up with Person-9 about Company-17’s €148,000 deal.
Delivery code resolves the placeholders
In the reply shown to you
Follow up with maya@example.test about Example Company’s €148,000 deal.
The model-facing conversation retains tokens. Hodman’s human-facing delivery service receives restored values and may cache them before showing or sending the reply.
Readable aliases are used here to explain the idea; the implementation uses opaque tokens. This is reversible pseudonymization, not anonymization. Unmasked details can still identify someone.
Five approaches you can combine.
These are complementary design choices, not five switches or a security rating. The right combination depends on the task, the data and the access available to your agents.
- 1
Do not collect what the task does not need
Keep unnecessary sensitive fields out of the project entirely. A lead-counting workflow may not need customer tax IDs.
How it is implemented
Choose fields when importing or querying the source. Review local storage, logs and error messages too.
- 2
Use placeholders for private values
Replace identifying values with tokens before returning data to the model. Restore them in supported messages for the people who need to read them.
How it is implemented
A connector creates tokens and a project-owned mapping. Delivery code resolves them. The mapping and every access path to it need protection.
- 3
Return summaries when details are unnecessary
Let code count records, total amounts or group results before sending them to the model. Share the result needed for the question.
How it is implemented
Run the query in the project environment and return aggregates. Small groups, rare values and combined queries can still reveal information.
- 4
Filter data at the connector boundary
Clean text and structured fields before they enter model-facing tool results. Cover the documents and services connected to that project.
How it is implemented
Use explicit field rules and tested transformations in each connector. Review free text, attachments, logs and error paths; field masking alone does not cover them.
- 5
Give the agent explicit rules
State what it should not retrieve or forward, and when a person needs to approve an action. The policy helps the agent build and use the right tools.
How it is implemented
Add requirements to project instructions and the data policy. Instructions are guidance; they do not replace access controls or checks in code.
What this does — and what needs separate control.
Coverage depends on the connector
A policy is not a universal filter on all model inputs. A pasted message, uploaded file, raw SQL result or different tool can bypass a covered connector. Inspect these paths separately.
Policy guides the agent; code enforces the result
This is an auditable instruction-and-connector contract, not a hard runtime DLP or isolation boundary. It relies on agents following policy instructions—including not reading the alias mapping into model context—and on connector code masking protected values before model-facing output. The policy itself does not provide a separate vault, restricted database role or hard SQL access controls.
Code needs tests and review
Deterministic substitution does not ask the model to remember a secret, but code can still have bugs. Check that original values do not appear in tool outputs, logs or errors, and that delivery only restores values on appropriate human-facing paths.
Masking and on-prem solve different problems
Your server determines where the project runs. Masking controls selected connector outputs. Hodman’s hosted workspace, delivery service and your model provider can still receive data according to the workflow. This is not a guarantee that all data stays within your network.
Start with one connector and test the whole path.
- List the fields to omit, mask or aggregate and the people allowed to see original values.
- Implement the policy and inspect model-facing outputs using fictional test records.
- Check repeated tokens, missing mappings, errors, logs and free-text fields.
- Verify the displayed reply and confirm restored values do not enter the next model input.