The most expensive property-data incidents are not breaches. They are successful releases — content shipped to a wider audience exactly as designed, where the design never asked whether that audience was allowed to see it.
- Business problem
- The most expensive property-data incidents are not breaches. They are successful releases — content shipped to a wider audience exactly as designed, where the design never asked whether that audience was allowed to see it.
- Why it matters
- Going from one market to fifty, or from licensed participants to the public, is a rights event rather than a scaling event. Free text carries what the field-level review missed, derived data does not inherit clearance, and nationwide means N sets of terms rather than one.
- Architecture response
- A repeatable audit built as a pipeline, not a review meeting: inventory every field and artifact, classify at field granularity against a precise audience model, detect what free text and media actually carry, deny derived data any inherited clearance, test each audience including the negative cases, and gate the release so it fails closed and loudly.
- What Databright Cloud Solutions does
- We design content inventories, field-level clearance matrices, free-text and media detectors, derived-data restriction inheritance, per-audience test harnesses, and the release gates and drift monitoring that keep a wider audience safe.
The previous article looked at the legal regimes that govern property data.1 This one is narrower and more practical: the engineering work of clearing content for an audience it was not originally collected for.
Widening the audience changes the question being asked
Most content in a property platform arrives under terms scoped to a specific audience and purpose. The data was licensed for participants in one market, or for a broker’s own clients, or for internal analytics. Nothing about copying it to a new region or exposing it through a public API changes those terms — it only changes how visible the mismatch is.
Three expansions each raise a different question:
One market to many. Each additional MLS or data source brings its own agreement, its own local rules, and its own field conventions. Coverage grows linearly; term variation grows with it.
Licensed participants to licensed non-participants, registered consumers, or the anonymous public. Each step removes a contractual relationship that the original terms may have assumed.
Human-viewed pages to APIs, bulk exports, model inputs, and AI agents. Content that was cleared for display was not necessarily cleared for extraction at scale.
Model the audience precisely, because the rules do
“Public” and “agents” are not audience definitions. The operative distinctions in this industry are finer than most systems represent, and conflating them is how content leaks.
A precision point worth encoding: a real estate licensee, an MLS participant or subscriber, and a REALTOR® member are three different things. Someone can hold an active license and have no MLS access. MLS data rights generally flow from participant or subscriber status under an MLS’s rules, not from licensure alone, and REALTOR® is a membership designation rather than a synonym for either. A permission model keyed on “is an agent” cannot express any of that.
Has a direct relationship with the MLS and access under its rules, including confidential fields.
Holds a license but no MLS relationship in that market. Not automatically entitled to participant-level content.
Has an established broker relationship and has accepted terms — the audience contemplated by VOW rules.
No registration, no relationship. The narrowest content envelope.
Receives data to use in their own product, governed by whatever your agreement permits you to pass on.
API clients, crawlers, and AI agents. Volume and retention characteristics differ from a human reading a page, even when the content is identical.
IDX and VOW are two different envelopes
The industry already encodes an audience distinction that many platforms flatten. Under NAR’s IDX policy, participants may display other participants’ listings on their own consumer-facing sites, subject to the policy’s conditions and seller opt-outs.2 The VOW policy governs a different arrangement: delivery of MLS data through a participant’s virtual office website to consumers with whom a broker relationship has been established, with registration and terms-of-use requirements attached.3
The practical consequence is that the same listing supports different content depth depending on which envelope the request falls into. A platform that stores one “public” boolean per listing cannot serve both correctly. The envelope is a property of the request, not of the record.
Inventory before you classify
Audits fail at the first step more often than the last. You cannot clear what you have not enumerated, and most platforms do not have a current, complete list of what they actually hold.
Not the canonical schema — the source fields, including local extensions and fields nobody maps but everybody stores.
Public remarks, private remarks, agent-to-agent notes, showing instructions, directions, disclosures.
Photos, floor plans, video, tours, documents, and their captions, filenames, and embedded metadata.
Scores, estimates, normalized metrics, model outputs, and the features behind them.
Public records, consumer data, and vendor enrichments attached to the listing.
Search indexes, tiles, exports, snapshots, and training corpora that predate the audit.
The last one is the one teams skip and later regret. Clearing the serving path while an old index still answers queries is not clearing anything.
Classify at field granularity, not dataset granularity
The output of the audit should be a matrix, not a verdict. For each field, for each audience tier, for each action, there is an answer — and the answers genuinely differ.
Facts the source permits broadly, with attribution and refresh obligations honoured.
Releasable to participants or registered consumers, not to anonymous public.
Confidential operational content whose exposure is a security problem, not merely a compliance one.
Depends on listing status, seller election, market, or elapsed time since close.
Category D is the one that breaks naive implementations. A field that is releasable while a listing is active and restricted after close is not a static classification — it is a rule that has to be evaluated at request time against current state.
Free text is where the leaks actually are
Structured fields get audited because they are visible in a schema. Free text does not, and it is routinely carrying content that must never reach a wider audience.
This is not hypothetical. NAR’s own lockbox FAQ confirms the practice directly: asked whether combinations or codes required for lock box access may be published in confidential “agent remarks” fields in the MLS, the answer is yes — making them available to participants and subscribers through the MLS satisfies the access requirement.4
There is a text field in your ingest that is designed to contain physical access codes for real houses. If your public surface renders agent remarks, or your search index tokenizes them, or your retrieval layer embeds them, you have published door codes.
Local MLS rules commonly separate public remarks from confidential fields precisely because of this, and prohibit showing instructions, security codes, and occupancy details from appearing in publicly displayed text.5 Those rules govern what agents should enter. They do not guarantee what your ingest actually contains.
So the audit needs detectors, not assumptions:
Lockbox combinations, gate codes, alarm codes, CBS codes, key locations — numeric and phrase patterns.
“Vacant,” “seller traveling,” “tenant occupied until” — a safety issue when public.
Owner, tenant, or occupant names and phone numbers appearing in text meant for agents.
Seller circumstances that were shared agent-to-agent, not to the market.
Content that belongs in a confidential field appearing in a public one — the error the rules exist to prevent.
Filenames, captions, and embedded EXIF that travel with an image and are rarely inspected.
Detectors should quarantine rather than silently strip. A stripped value is an undetected upstream problem; a quarantined one is a work item with a source, a market, and a count.
Derived data does not inherit clearance
A common failure is to audit inputs, clear the outputs by association, and ship. Derivation can move restricted content across the boundary in a form that no field-level check will catch.
An AI-generated property summary built partly from private remarks is a derivative of restricted content. A retrieval index that embedded confidential text can surface it through similarity even if the raw field is never returned. The rule to enforce is that a derived value carries the most restrictive classification of its inputs until someone deliberately and demonstrably decides otherwise.
Enforcing that requires knowing the inputs, which is why provenance is a prerequisite for this audit rather than a nicety.6
Nationwide means N sets of terms, not one
Geographic expansion multiplies the audit. Fifty markets can mean fifty agreements, fifty local rule sets, and fifty field conventions that are similar enough to lull you and different enough to hurt.
There are two coherent strategies, and one incoherent one that teams drift into:
Publish only what every source permits. Simple, defensible, and leaves value unrealised in permissive markets.
Evaluate terms per source at request time. Realises full value, requires real policy infrastructure and per-market test coverage.7
The default: the first market’s terms become the implicit global rule because that is how the code was written. Neither safe nor complete.
Start restrictive, expand per market as terms are modeled and tested. The practical path for most teams.
Whichever you choose, market must be an explicit input to the decision. If a reviewer cannot answer “which market’s terms produced this response,” the system is guessing.
Make the audit a pipeline, not a review
A one-time clearance exercise is obsolete the moment a source adds a field. The audit has to run continuously, on every ingest, as code.
Two properties make it useful. It must fail closed — an unclassified field is withheld, not released, so that the cost of an unmapped field is a support ticket rather than an exposure. And it must be versioned, so a release decision can be reconstructed as of the date it was made.
Test per audience, including the negative cases
Most teams test that content appears. Far fewer test that content does not appear, which is the property that actually matters here.
Fixtures exercising local quirks, confidential fields, and conditional rules.
Explicit tests that a confidential field is absent from every anonymous-tier response — API, HTML, export, sitemap, and search index alike.
Records deliberately seeded with a fake lockbox code and owner phone number. If any surface renders them, the build fails.
Confirm summaries and embeddings built from restricted inputs are not reachable by the wrong tier.
Conditional rules exercised across active, pending, closed, and withdrawn.
An unmapped source field fails the build rather than flowing through unnoticed.
The poisoned-fixture pattern is the highest-value item on that list. It converts a policy question into a deterministic test that a build can fail, and it catches exposure paths nobody thought to enumerate — which is precisely the category that causes incidents.
Gate the release, then watch it
Clearance is not a switch. Treat a distribution expansion the way you would treat any risky deploy.
Roll out by market rather than all at once, so the blast radius of a mis-modeled term is one jurisdiction. Keep a documented rollback that removes content from every surface, including caches and indexes, not just the origin. And instrument the release: field-level counts by audience tier make an unexpected exposure visible as a step change rather than as a phone call.
After release, the risk shifts to drift. New fields appear, lookup values change, agents start using a field differently, and a source revises its terms. Each is a new exposure vector against an audit that has already passed.
New or renamed source fields are quarantined pending classification.
Detector hit rates by source and field — a spike means a market changed its practice.
Agreement updates trigger reclassification, not just a filing.
Re-run the full clearance against current data, not the sample from launch.
Keep the evidence, because you will be asked
The audit’s durable output is not a green light. It is a record that can answer a question months later from a partner, a regulator, or an MLS compliance officer.
For a given field, on a given date, at a given audience tier: what was the classification, which agreement version produced it, which detectors ran, what did they find, who approved the exception, and what did the system actually return? A platform that can answer that is in a materially different position from one that can only say the review was done.
Do not ask whether content can be distributed more widely. Ask which audience, under which agreement, as of which date — and make the system refuse to answer until it can answer precisely.
Sources and industry references
- Databright Cloud Solutions — Three Regimes, One Property Record: How MLS Licensing, Copyright, and State Privacy Law Constrain Property Data
- National Association of REALTORS® — Internet Data Exchange (IDX) Policy, Policy Statement 7.58
- National Association of REALTORS® — Virtual Office Websites (VOW) Policy: use of MLS data in connection with internet brokerage services
- National Association of REALTORS® — FAQ on Mandatory Placement of Lock Boxes: access combinations in confidential agent remarks
- Charlottesville Area Association of REALTORS® — MLS Rules and Regulations: a representative local rule set covering remarks and confidential fields
- Databright Cloud Solutions — The Source Provenance Problem: Can You Explain Where Every Property Fact Came From?
- Databright Cloud Solutions — The Usage Rights Problem: Making Real Estate Data Governance Machine-Readable
This article is an engineering perspective and is not legal advice. MLS rules, participation agreements, and vendor terms vary by market and change over time; the policies and local rule set referenced above are illustrative examples, not a complete or authoritative statement of what applies to any particular platform. Verify requirements against your own agreements and the rules of each MLS or data source involved, and consult qualified counsel and the relevant MLS before expanding distribution.