Open Data Infrastructure
Data Modeling for Identity Resolution in Agentic Systems
How agents need models that separate person, account, device, permission, consent, and confidence evidence before they act on identity.
Identity resolution gets dangerous when an agent treats a matched record as permission to act.
Identity is not one column
Identity models often collapse person, account, household, device, email, consent, and permission into a single operational view. That may work for reporting. It is not enough for agentic systems that choose actions.
FHIR Patient documentation shows how healthcare systems model identifiers and links around a patient resource. W3C PROV separates entities, activities, and agents. Those are reminders that identity is contextual evidence, not only a row key.
Separate the things agents will confuse
An agent-ready identity model should separate the real-world party, account, credential, device, contact method, consent record, permission, confidence score, and resolution method. It should also state which actions each identity link can support.
A high-confidence match for personalization may be unacceptable for a financial action. A device match may support fraud review but not consent. A shared email may identify a household, not a person.
Core idea: agentic identity models need action boundaries, not only better matching.
Resolution needs confidence and consent
Open Data Infrastructure should connect identity resolution to catalogs, lineage, policy, consent records, and audit evidence. The model should let an agent retrieve not only who the system thinks someone is, but why that match is allowed for the requested action.
For adjacent context, read data modeling for multi-agent workflows, data modeling for tool-calling agents, and privacy and consent control in ODI.
What breaks first
- A customer ID is treated as a person identity across unrelated systems.
- Confidence scores are calculated but not exposed to agent tools.
- Consent is modeled as a profile attribute instead of a policy constraint.
- Identity links lack lineage, so bad matches cannot be explained or unwound.
Questions to ask
Ask what entity type the agent is resolving, which evidence supports the match, and which action the match permits. Ask whether consent and confidence travel with the resolved identity.
Sources to start with
These primary sources anchor the technical claims in this guide.
- HL7 FHIR Patient resource documentation
- W3C PROV overview
- Open Policy Agent policy language documentation
- NIST AI Risk Management Framework
Identity resolution is not safe for agents until the model knows what the agent is allowed to do with the match.