The RAILS Framework

Boards are not deciding whether members will begin using AI. Members are already using it in production work, often through general-purpose tools that sit outside a board-defined identity, permission, retention, provenance, and audit layer.

The RPR 2026 AI Adoption Survey also found that 92% use AI now or plan to, 71% identify time savings as its leading value, and 68% save at least one hour per week. The survey was self-reported by 225 U.S. NAR-member real estate professionals, so it should not be generalized as a census of every market. Read the full RPR survey .

The survey does not directly measure board oversight. The governance conclusion is an inference: when adoption is already embedded in member workflows, the practical choice is no longer AI versus no AI. It is governed, permissioned paths versus unmanaged workarounds with weaker visibility and fewer shared controls. What members can already delegate is measurable: HomieBench v5 benchmarks eight frontier models across 100 supervised realtor workflows.

The detailed answers sharpen that inference. In Q5, 38.74% reported using market analysis or pricing tools and 22.52% reported AI CMA tools. In Q7, 30.63% reported analyzing market trends and 24.32% reported running CMAs or pricing conversations. One qualitative respondent also said they use AI heavily when processing trends from MLS data. The survey does not establish how common it is for members to paste MLS, client, or transaction data into a model, but it demonstrates enough high-stakes use to make data-flow controls urgent.

Adoption is ahead of governance. Waiting does not preserve the status quo; it cedes the control surface.

Agentic AI is becoming an interface through which consumers and professionals discover information, compare options, make decisions, and initiate action. In real estate, the interface that captures the question also captures commercially valuable intent: preferences, search refinements, objections, timelines, affordability constraints, and next steps.

Boards and MLSs therefore face two risks at once. Blanket prohibition can push members toward ungoverned consumer tools and workarounds. Unrestricted access can transfer protected listing, client, and transaction data into systems that were not designed to govern it. Neither extreme is durable.

The AI may receive capabilities. It must not receive custody.

RAILS—the proposed Realtor Agentic Interoperability Layer Standard—keeps protected data in its proper system of record while exposing narrowly scoped, identity-bound, purpose-bound, auditable capabilities. Models may search, summarize, prepare, validate, or request an action. They do not receive feed credentials, become the CRM, persist a shadow listing database, create the authoritative contract in an unapproved sandbox, or apply a signature.

The result is a model-agnostic architecture that combines zero trust, least privilege, purpose limitation, split-channel secure rendering, deterministic computation, human approval for consequential actions, immutable audit events, and capability-level vendor certification.

Organized real estate was built around cooperation: competing professionals shared inventory under common rules for attribution, access, display, accountability, and data quality. That cooperative infrastructure also created an information advantage. AI and open distribution are reducing the marginal cost of basic access and interpretation.

The professional does not disappear when information becomes cheaper. The professional’s comparative advantage moves toward fiduciary alignment, judgement under uncertainty, negotiation, risk ownership, service coordination, and accountable execution. The board’s advantage changes in parallel: from information scarcity toward identity, permission, provenance, quality, interoperability, auditability, and revocation.

The market is already showing this shift. In October 2025, Zillow and OpenAI launched a conversational listing experience inside ChatGPT. Zillow says it controls the rendered experience, does not send OpenAI a raw MLS feed, and preserves MLS attribution and field controls. That architecture is a live example of a capability being made available without transferring feed custody. See the primary announcements from Zillow and Zillow’s industry explanation .

In June 2026, HouseCanary described a national expansion of Google’s mobile home-discovery program using listings from participating MLSs with broker and agent attribution. The announcement is evidence of real-estate discovery moving into a horizontal intent layer, although it should not be read as proof of any architecture beyond what the publisher describes. See the HouseCanary announcement .

Tool-connected AI is also becoming portable. OpenAI’s Apps SDK is built on the Model Context Protocol; Anthropic describes MCP as an open standard for connecting AI systems to external tools and data. These facts do not prove that every portal will integrate with every model. They do establish the interface pattern: natural-language request, controlled tool call, external system, structured result, and rendered experience. See OpenAI and Anthropic .

The choice is not “AI or no AI.” It is whether adoption happens inside a governable perimeter or outside one. Governed access creates new diligence and enforcement work, but it also gives boards a path to set requirements, certify capabilities, monitor use, revoke access, and keep professional accountability visible.

Custody exists when a model provider, agentic harness, or vendor application can persist, redistribute, train on, broadly index, or become an alternate source of truth for protected data. Capability exists when an authenticated actor can request one defined business action through a controlled service with bounded input, output, purpose, retention, and side effects.

Every capability should declare its eligible actors, allowed purpose codes, data classes, result ceilings, risk tier, human approval requirement, retention class, audit events, failure behaviour, and revocation path. Credentials remain at the gateway or system of record; they never enter model context.

• The model is never the system of record.
• Protected data is purpose-bound and minimized.
• Credentials and signing keys never enter model context.
• Deterministic services calculate and validate where correctness matters.
• Consequential actions remain attributable to an authorized human.
• Every access is observable, revocable, and auditable.
• Interfaces remain model-agnostic to reduce platform lock-in.
• Human-rights, privacy, and professional duties are enforced by design.

A workable policy must stop treating “real-estate data” as a single class. Listing, client, and transaction data carry different permissions, risks, and authoritative systems. RAILS applies the same boundary to all three while preserving those differences.

Split-channel secure rendering

Protected listing detail does not always need to enter the model’s natural-language context. The model can receive a count, an opaque widget reference, policy metadata, and a secure view URL. The user interface then retrieves the authorized listing component directly from the IDX, VOW, DDF, brokerage, or board-controlled origin. The display channel and the model channel remain separate.

This pattern is compatible with existing permission-based distribution models. CREA describes REALTOR.ca DDF® as a managed, permission-based service in which broker owners control how listing content is shared. RESO publishes current Web API and Data Dictionary specifications that can provide common vocabulary for capability schemas. See CREA DDF® and RESO specifications .

RAILS separates probabilistic interpretation from identity, authorization, calculation, recordkeeping, and binding execution. A model may infer what a user is trying to achieve; it does not decide whether the user is entitled to achieve it.

The policy and identity plane evaluates the subject, action, resource, data class, purpose, consent, jurisdiction, time, and risk tier. The capability gateway then asks the authoritative application to perform the action. The default response is the minimum sufficient projection—not the entire underlying resource.

allow = policy(
  subject,
  action,
  resource,
  data_class,
  purpose,
  consent,
  jurisdiction,
  time,
  risk_tier
)

result = minimize(authoritative_data, purpose, role, consent, policy)

This architecture follows the same direction as zero-trust systems: no implicit trust based on location or ownership, explicit authentication and authorization, and policy focused on users, services, and resources. NIST SP 800-207A further describes granular application-level policy enforcement through gateways and service identities. See NIST SP 800-207 and NIST SP 800-207A .

Realtors and brokerages already use authorized IDX websites and applications to present listing information under applicable agreements, board rules, display requirements, and participant control. Coding agents can also modify website code. RAILS combines those facts without creating a new raw-data entitlement: the approved IDX application remains the only runtime permitted to hold credentials, query live listing data, enforce field and display rules, and render the result.

NAR’s current IDX policy describes authorized display through participant-controlled websites, mobile apps, and other approved mechanisms, requires the participant to control how listings are displayed, and states that MLS database access may not be given to an unauthorized person or entity. See NAR IDX Policy Statement 7.58 . In Canada, CREA describes DDF® as a permission-based distribution service and a Member Website Feed for listing display on a member-controlled website; see REALTOR.ca DDF® .

The coding agent changes the experience. The approved IDX application controls the data.

The model may help create a custom buyer-search page, neighbourhood experience, listing comparison, property page, or deterministic home-evaluation workflow. It can edit React components, templates, schemas, tests, mock fixtures, explanatory copy, and approved parameterized query definitions. It must not receive the raw feed, reuse feed credentials, query the live database, create a shadow index, or copy bulk listing data into model memory.

capability: idx.page.render
actor: participant_controlled_website
agent_visibility: [schema, mock_fixture, query_definition, rendered_metadata]
agent_prohibited: [feed_credential, live_database, raw_payload, bulk_export]
runtime:
  execute_query: approved_idx_application
  enforce: [field_permissions, attribution, freshness, display_rules, rate_limits]
output:
  returns: [rendered_page_ref, result_count, data_as_of, provenance]
deployment:
  tests_required: [query_bounds, prohibited_filters, attribution, stale_data, extraction]
  human_approval: required

RESO notes that its Web API can execute live queries for immediate results in web applications and defines an IDX payload as the structured fields needed for display on an IDX website. RAILS places that live query and payload handling inside the authorized application boundary—not inside model context. See the RESO Web API overview .

• The website or approved application—not the model—is the data recipient and runtime.
• The coding agent receives schemas, fixtures, and opaque result references, not feed credentials.
• Live queries execute server-side under participant identity, purpose, and policy.
• Rendered pages preserve attribution, freshness, filtering, display, and access requirements.
• Every deployed code or query-definition change is tested, reviewed, versioned, and reversible.
• Boards can audit and revoke the application capability without granting access to the model.

RAILS is not only a listing-search architecture. The same capability-without-custody boundary applies to the repetitive workflows that realtor tools are beginning to automate. Each workflow needs a named action, authorized actor, purpose, minimum data, deterministic checks, human boundary, audit event, and revocation path.

Agent-to-agent showing booking: ShowingTime API, BrokerBay API, Touchbase API, Aligned Showings API, SentriKey Showing Service API, Instashowing API, and Showingly MCP

Showing coordination is a strong candidate for a board-defined agent-to-agent profile. A buyer agent’s AI should be able to ask a listing agent’s authorized service for permitted availability, submit one traceable request, receive an approval, counter-time, or decline, and reconcile both calendars. Neither model needs the other realtor’s password, browser session, seller instructions, alarm code, lockbox data, or full client record.

The workflow crosses realtor identity and delegation, listing status, buyer context, calendars, seller or tenant approval, appointment state, secure access instructions, notifications, and feedback. That makes a normal browser session too broad and an unstructured chat between bots too weak. The system of record must authorize and execute each state transition.

Review the current publisher material for ShowingTime+ , BrokerBay , Touchbase , Aligned Showings , SentriKey Showing Service , Instashowing , and Showingly API and MCP access . Zillow’s Real-Time Touring also documents a ShowingTime-integrated consumer and agent flow; see Zillow .

1. 01

   Delegate

   Each realtor authorizes their own agent with a short-lived, tenant-bound token and explicit showing scopes.

2. 02

   Discover

   The buyer-side agent reads permitted slots without receiving seller notes, alarm data, or lockbox credentials.

3. 03

   Request once

   A create call carries buyer-context reference, requested slots, purpose, trace ID, and idempotency key.

4. 04

   Apply listing policy

   The listing-side service checks status, showing rules, calendar conflicts, and required human or seller approval.

5. 05

   Reconcile

   Both sides receive the authoritative status by webhook; calendars update from the appointment reference.

6. 06

   Reveal securely

   Only after confirmation, entitled users retrieve time-bound access instructions through a separate secure channel.

framework_version: rails/1.4
profile_schema: rails-capability-profile/1.0
capability: showing.request_create
eligible_roles: [licensed_realtor, authorized_assistant]
required_scopes: [showing:availability_read, showing:request_create]
delegation:
  subject: realtor_id
  tenant: board_or_brokerage_id
  token_ttl: short
input:
  listing_ref: opaque
  requested_slots_max: 3
  buyer_context_ref: crm-scoped
  idempotency_key: required
policy:
  listing_status_current: required
  calendar_conflict_check: required
  agency_and_consent_state: required
output:
  returns: [request_ref, status, expiry, secure_instruction_ref]
  model_visibility: no_lockbox_or_confidential_instructions
human_review: required_on_exception
audit: signed_tamper_evident_events
revocation: immediate

• showing.availability_read
• showing.request_create
• showing.request_respond
• showing.request_reschedule
• showing.request_cancel
• showing.instructions_render_secure
• showing.feedback_submit

AI Follow Up Boss, AI GoHighLevel, AI Lofty CRM, AI kvCORE / BoldTrail, Sierra Interactive, CINC, Real Geeks, BoomTown, Wise Agent, and Top Producer

Search demand is clustering around specific realtor tools, but the governance unit should remain the capability. The 84-system integration directory maps this landscape with documented access status for every system. Follow Up Boss documents a REST API and signed webhooks. HighLevel exposes contacts, conversations, calendars, opportunities, payments, and a broad webhook catalogue. Lofty documents developer access to leads, listings, transactions, communications, and AI features. BoldTrail is the current ecosystem name associated with kvCORE. Sierra Interactive, CINC, Real Geeks, BoomTown, Wise Agent, Top Producer, HubSpot, Salesforce, and other CRMs vary in partner access, object coverage, and commercial terms.

RAILS should make those differences explicit while preserving common actions: crm.person_match, crm.note_create, crm.task_create, crm.appointment_create, crm.stage_propose, and crm.opt_out_record. See the developer materials for Follow Up Boss , HighLevel , and Lofty .

AI offer writing in SkySlope, CREA WEBForms, Lone Wolf Transactions, zipForm, TransactionDesk, dotloop, Form Simplicity, DocuSign, and Authentisign

Offer preparation is where a convenient browser workaround can become an authoritative legal-document problem. Common Canadian and U.S. systems include SkySlope, CREA WEBForms powered by TransactionDesk, Lone Wolf Transactions (zipForm Edition), Lone Wolf Transactions (TransactionDesk Edition), dotloop, Form Simplicity, Authentisign, DocuSign, Brokermint, Paperless Pipeline, Glide, and brokerage-specific compliance portals. The approved form library, brokerage rules, identity, audit, and exact document version must remain attached to the workflow.

CREA describes CREA WEBForms as an end-to-end document and transaction-management product powered by TransactionDesk. Product access through a member interface does not itself authorize an agentic browser to reuse that member’s credentials or session.

Several vendors already provide safer integration paths. SkySlope documents transaction-management APIs and an Offers API; Lone Wolf publishes partner APIs for TransactionDesk, zipForm, Transact, and Deals; dotloop documents an OAuth 2.0 public API; Form Simplicity documents scoped transaction endpoints; and DocuSign exposes its eSignature REST API. See SkySlope , SkySlope Offers , Lone Wolf , dotloop , Form Simplicity , and DocuSign .

A board or brokerage may also approve a self-hosted signing service such as DocuSeal , which documents on-premises deployment plus API and webhook support. Open source does not by itself establish legal validity, security, insurance coverage, retention compliance, or approved-form rights; those still require diligence and policy. Nano-PDF is an open-source AI PDF-editing CLI that recreates pages and restores searchable text with OCR. It may help with nonbinding presentation material, but it is not an e-signature or transaction system of record and should not generate or mutate authoritative offer forms. See the Nano-PDF project description .

• forms.template_read
• transaction.draft_create
• transaction.fields_propose
• transaction.validate
• esign.envelope_create_draft
• transaction.dispatch_approved

AI social media for realtors: OpusClip, SumoClip, Higgsfield, Zernio, and ManyChat

A governed social agent can transform approved source material with AI clipping, create disclosed synthetic assets or presenter variants, obtain exact-artifact human approval, publish through official platform APIs, manage permitted comment and DM workflows, and write qualified leads back to the CRM. It should not scrape social dashboards, invent listing facts, reuse media without rights, impersonate a realtor, or continue a conversation outside platform and consent rules.

The follow-up Homies Research paper, The Real Estate Social Media AI Agent Stack, covers OpusClip, SumoClip, Supo, Higgsfield AI clones, the Zernio API, ManyChat, CRM integration, cost, measurement, and human-review controls in detail.

A model request necessarily processes some input during inference. “No data in the model” is therefore useful shorthand but not an enforceable specification. The policy must enumerate every place protected information may persist.

A defensible vendor matrix identifies retention by endpoint and feature, training and feedback status, memory defaults, file lifecycle, cache behaviour, trace redaction, human-review exposure, subprocessors, residency, deletion verification, encryption, and incident obligations. Consumer accounts should not be used for protected workflows.

In Canada, organizations subject to PIPEDA must address accountability, identified purposes, consent, limiting collection, limiting use/disclosure/retention, accuracy, safeguards, openness, access, and challenge rights. Provincial law and sector-specific rules may also apply. See the Office of the Privacy Commissioner of Canada .

The proposed rule is precise: protected real-estate data may not be used for training, fine-tuning, model improvement, feedback, persistent memory, reusable retrieval indexes, model-managed files, or long-lived application state unless every party with the legal authority to permit that use has done so. Transient processing must be minimized, purpose-bound, encrypted, contractually protected, and subject to the shortest available retention.

Traditional application security remains necessary, but an agent adds instruction interpretation, tool selection, workflow state, and cross-system action. Controls must assume that retrieved content can be hostile and that a fluent model output can still be wrong or manipulative.

The OWASP Top 10 for Agentic Applications 2026 provides a useful cross-industry baseline. NIST’s voluntary Generative AI Profile organizes risk work around governance, mapping, measurement, and management. RAILS translates those foundations into real-estate-specific data and action boundaries; it does not replace either framework.

Audit events should be append-only and include trace ID, actor, tenant, capability, purpose, risk tier, resource reference, request/response hashes, policy version, authorization result, approval reference, outcome, and retention class. Raw protected payloads should not be logged by default.

A model can help a professional reason about a result, but it should not free-form a CMA, filing deadline, disclosure decision, binding form, or protected-field determination. Deterministic services should calculate comparable filters, distances, date windows, prices, adjustments, mortgage figures, taxes, deadlines, required fields, signature completeness, and document hashes.

{
  "result_ref": "cma_01J...",
  "source": "approved-vow-service",
  "retrieved_at": "2026-07-14T14:21:08Z",
  "data_as_of": "2026-07-14T14:19:55Z",
  "policy_version": "board-agentic-policy-1.2",
  "tool_version": "cma-service-3.4.1",
  "calculation_version": "adjustments-2.0",
  "model_visibility": "metadata_only",
  "human_review_required": true
}

Agentic interfaces can amplify discrimination when they accept protected-class preferences, infer them from proxies, or translate vague language into demographic steering. The design rule is consistent even where specific protected grounds differ: do not accept, infer, optimize, or conceal protected-class criteria.

• Maintain prohibited-feature and proxy-feature catalogues.
• Log the objective criteria that include or exclude each result.
• Explain trade-offs rather than rank communities as good or bad.
• Test recommendations and ad delivery for disparate patterns.
• Escalate ambiguous requests to an authorized human.
• Apply the specific law and professional rule of each jurisdiction.

Ontario’s Human Rights Code protects equal treatment in buying, selling, and renting housing on Code-protected grounds. In the United States, HUD guidance identifies risks including denying housing information, differential terms, and steering through digital advertising. See the Ontario Human Rights Commission and HUD’s digital-platform guidance . Implementers must verify current local law rather than reuse either list as a universal rule.

A vendor may be suitable for secure listing rendering and unsuitable for transaction dispatch. A brokerage tool may be approved to create a CRM task and prohibited from bulk export. Certification should therefore attach to a capability, data class, actor, purpose, and risk tier—not to a logo.

Evidence should include architecture and data-flow diagrams, a field-level data inventory, model and subprocessor lists, retention matrices, training-use commitments, tenant-isolation tests, OAuth scopes, tool schemas, red-team results, fair-housing or human-rights testing, approval design, audit-event catalogues, incident response, business continuity, kill-switch procedures, deletion evidence, and software/AI bills of materials.

API first, MCP second, CLI for supervised operations

API, MCP, and CLI are complementary interfaces, not interchangeable security claims. Certification should follow the underlying capability and identity chain across every interface.

From feed governance to capability infrastructure

The same institutions that created permissioned distribution can expose controlled search, valuation support, statistics, geographic intelligence, rendering, compliance validation, attribution, and provenance endpoints. The strategic product is no longer only a feed. It is a governed capability platform that lets new interfaces operate on board-defined terms.

The safest adoption path increases capability only after the preceding control layer has been demonstrated. Boards should begin with inventory and a narrow read-only path, not a high-risk transaction automation showcase.

1. 0–90 daysPhase 1

   Policy and inventory

   Map systems and data classes; identify shadow AI; define prohibited uses; create legal, privacy, security, technical, and member governance.

2. 90–180 daysPhase 2

   Read-only and showing pilot

   Certify narrow search, secure rendering, and showing-availability capabilities; test injection, extraction, attribution, field permissions, and revocation.

3. 180–270 daysPhase 3

   Agent-to-agent workflows

   Add idempotent showing requests, deterministic CMA/statistics, and purpose-bound CRM tools with shared audit events and privacy-impact review.

4. 270–365 daysPhase 4

   Transaction preparation

   Integrate approved forms platforms; bind human approval to immutable document versions; keep dispatch platform-side.

5. Year 2Phase 5

   Standards and scale

   Publish an Agentic Access Profile, align schemas with RESO concepts, support multiple vendors, and operate red-team and incident-sharing programs.

Keeping the human in the loop: safe integration in one workflow

The tier progression stays abstract until it is applied to a single consequential workflow. Take the one members care about most: writing an offer.

In the first phase, the AI prepares structured field proposals inside a supervised harness. An approved form service selects the current template and runs deterministic checks; the realtor opens the draft in the system of record, reviews it, and completes the signing flow themselves. The model’s autonomy ends at a proposed draft. Nothing reaches a client that the realtor did not personally review and move.

In the second phase, the approved transaction API creates the draft from governed forms, records the AI-proposed fields, validates the instrument, and routes the exact version for signature. One rule changes: the signing order. The document goes to the realtor before the client. The realtor’s exact-version approval or professional attestation is recorded before the client ever sees it. Its legal effect depends on the instrument, the signer’s authority, and the jurisdiction; RAILS does not turn an internal approval into a signature or representation that local law does not recognize. Accountability becomes a verifiable property of the workflow rather than a procedural checkbox.

The pattern generalizes across every tier in this framework. As autonomy increases, the human checkpoint does not disappear; it moves earlier and its consequences get heavier. The AI may earn more of a workflow only where the accountable human’s commitment is captured by a mechanism that cannot be skipped: a signature order, a document hash, a step-up approval. Section 14 shows the hash-bound version of the same idea, where approval binds to the exact document version and any later mutation invalidates it.

Phase two does not remove the human. It records the licensee’s exact-version approval before the client ever sees the AI-prepared instrument.

Success metrics should be operational: policy violations prevented, field-minimization rate, attribution correctness, tool-call failure rate, human-review completion, revocation time, incident detection time, unauthorized extraction resistance, and member time saved—not raw prompt volume.

The following clauses are starting points for jurisdiction-specific drafting. They are deliberately technology-neutral and preserve existing duties.

Natural-language policies are necessary but insufficient. Each approved capability should have a machine-readable profile that certification tests can exercise.

framework_version: rails/1.4
profile_schema: rails-capability-profile/1.0
capability: cma.prepare
risk_tier: 2
eligible_roles: [licensed_realtor]
required_scopes: [cma:prepare]
purpose_codes: [seller_evaluation, buyer_analysis, brokerage_review]
input:
  schema: cma-request/2.1
  max_records: 50
output:
  model_visibility: metadata_only
  returns: [cma_ref, secure_view_url, expiry, provenance]
human_review: required_before_share
retention_class: audit_metadata_only
revocation: immediate

For transactions, approval must bind to an immutable artifact. A later mutation must invalidate the approval and force a new review.

function dispatchApproved(documentBytes, approval) {
  assert(approval.expiresAt > now())
  assert(sha256(documentBytes) === approval.documentSha256)
  assert(currentActor.id === approval.reviewerId)
  assert(policyAllows("transaction.dispatch", approval.purpose))

  // The approved platform holds the signing credential.
  return transactionPlatform.dispatch(documentBytes, approval.id)
}

Production implementations should use asymmetric signatures or a managed key service, short-lived tokens, replay protection, step-up authentication, and explicit audience and tenant binding. Samples in this paper illustrate control shape; they are not production security code.

A login proves that someone authenticated. It does not prove which human authorized an agent, which legal entity operates it, which runtime executed the call, or whether it could delegate the work again. RAILS therefore treats the human principal, brokerage, agent application, runtime workload, vendor, and downstream agent as distinct actors. No agent may collapse that chain into the realtor’s identity or pass the same bearer credential through multiple services.

framework_version: rails/1.4
profile_schema: rails-delegation-profile/1.0
delegation_id: del_opaque
issuer: board_authorization_service
human_principal: realtor_opaque
accountable_organization: brokerage_opaque
agent_client: registered_app_opaque
runtime_workload: attested_workload_opaque
tenant: board_or_mls_opaque
audience: https://showing.example/capabilities
capabilities: [showing:availability_read, showing:request_create]
purpose: buyer_showing
jurisdiction_profile: ca-on/1.0
consent_ref: consent_opaque
parent_delegation: null
subdelegation: prohibited_by_default
issued_at: 2026-07-22T14:00:00Z
expires_at: 2026-07-22T14:10:00Z
proof: issuer_signature_and_sender_binding

This profile adopts the direction of the MCP authorization specification , which binds tokens to a target resource and forbids token passthrough, and the IETF’s OAuth token exchange and DPoP mechanisms. RAILS adds the real-estate principal, tenant, purpose, consent, license, jurisdiction, and subdelegation fields needed for professional accountability.

Agent-to-agent interoperability requires both sides to agree on what happened when a request pauses, conflicts, expires, retries, or partially succeeds. RAILS maps its real-estate lifecycle to the base task model in the Agent2Agent protocol and defines domain outcomes that generic agent protocols do not decide.

• Idempotency keys are scoped to the tenant, actor, capability, and normalized request; reusing one with different content fails closed.
• Every mutable resource carries a version or ETag. A stale reschedule, cancellation, offer, or instruction update returns a conflict instead of overwriting newer state.
• Retries declare whether the prior attempt committed, use bounded exponential backoff, and never turn a transport timeout into an assumed business failure.
• Push events and webhooks are signed, timestamped, replay-protected, ordered or explicitly sequence-numbered, and recoverable through authoritative status polling.
• Deadlines, approval expiry, slot holds, timezone, cancellation policy, and compensation ownership are machine-readable.
• The platform publishes a reconciliation operation so both agents can recover after partial delivery, disconnection, or webhook loss.

Property entry is a separate, higher-risk capability

A confirmed appointment establishes eligibility to request entry; it does not deliver entry authority to the model. Lockbox, alarm, occupancy, access-note, and door-event data remain outside prompt, memory, trace, screenshot, and browser-replay surfaces.

framework_version: rails/1.4
profile_schema: rails-property-access-profile/1.0
capability: showing.entry_instruction_redeem
requires:
  appointment_state: confirmed
  appointment_ref: exact
  recipient: authenticated_entitled_human_or_bound_device
  property: exact_listing_ref
  time_window: just_in_time
  step_up_authentication: required
delivery:
  channel: outside_model_context
  forwardable: false
  reveal_to_agent_runtime: false
  screenshot_and_log_capture: prohibited
controls:
  one_appointment_one_credential: required
  door_event_audit: required_when_supported
  emergency_revoke: immediate
  offline_fallback: board_approved_human_process
retention: access_metadata_only

Safety ceilings also apply to scale. Each tenant sets per-task and daily limits for bookings, cancellations, messages, signatures, exports, compute, and paid calls. Abnormal velocity, fan-out, repeated denials, resource exhaustion, and denial-of-wallet patterns pause the capability before a financial or operational limit is crossed.

An append-only log is useful but not sufficient. A certifiable event must be portable, tamper-evident, privacy-minimized, and understandable without access to the vendor’s internal prompt history. Evidence follows the business action across API, MCP, CLI, queue, webhook, and agent-to-agent boundaries.

{
  "specversion": "rails-evidence/1.0",
  "event_id": "evt_opaque",
  "event_type": "showing.request.completed",
  "occurred_at": "2026-07-22T14:04:12Z",
  "trace_id": "w3c_trace_context",
  "task_id": "task_opaque",
  "tenant": "board_or_mls_opaque",
  "human_principal": "realtor_opaque",
  "accountable_organization": "brokerage_opaque",
  "agent_client": "registered_app_opaque",
  "runtime_workload": "attested_workload_opaque",
  "capability": "showing.request_create",
  "purpose": "buyer_showing",
  "policy_version": "board-policy/4.2",
  "delegation_id": "del_opaque",
  "approval_ref": "approval_opaque",
  "input_digest": "sha256:...",
  "output_digest": "sha256:...",
  "model_and_tool_versions": ["model:registered", "mcp:2.1"],
  "authoritative_result_ref": "appointment_opaque",
  "outcome": "completed",
  "previous_event_digest": "sha256:...",
  "issuer_signature": "jws:...",
  "sensitive_payload_logged": false
}

Continuous authorization, incident response, and change control

Short-lived credentials reduce exposure but do not solve a compromise that occurs during their lifetime. Issuers need a signed security-event channel for account disablement, license or employment change, consent withdrawal, device compromise, vendor suspension, and emergency property-access revocation. The OpenID Shared Signals Framework offers a standards-based model for continuously communicating such changes.

Capability controls protect systems. They do not by themselves protect a person who receives a wrong message, inaccessible recommendation, discriminatory outcome, missed deadline, or document they did not understand. RAILS adds a consumer-rights layer to every consequential profile.

Responsibility must be allocated before failure

Contracts should assign incident investigation, consumer remediation, missed-deadline handling, defence, indemnity, cyber coverage, errors-and-omissions coverage, evidence production, and regulatory cooperation. A generic statement that every party remains responsible is not an allocation model.

Jurisdiction profiles—not one North American rule

The core standard remains technology-neutral, while signed jurisdiction profiles bind capabilities to locally reviewed rules. A profile identifies the applicable privacy, human-rights or fair-housing, electronic-signature, recording-consent, forms-licensing, agency, advertising, recordkeeping, anti-money-laundering, sanctions, and unauthorized- practice-of-law requirements. Canadian profiles should explicitly map applicable federal and provincial privacy rules and FINTRAC duties; United States profiles should map federal and state privacy, fair-housing, e-signature, recording, OFAC, licensing, brokerage, and forms rules.

jurisdiction_profile: ca-on/1.0
facts:
  participant_license_jurisdiction: CA-ON
  brokerage_jurisdiction: CA-ON
  property_jurisdiction: CA-ON
  consumer_residence: collected_only_if_required
  communication_parties: [CA-ON]
  instrument_type: offer_to_purchase
  recording_or_transcription: false
decision:
  allowed_capabilities: policy_engine_result
  required_disclosures: policy_engine_result
  required_human_roles: policy_engine_result
  retention_and_hold: policy_engine_result
  decision_source_version: counsel_approved_ruleset

This is a policy-routing structure, not legal advice. Counsel must approve each profile, legal claims must be re-verified, and the technical system must fail closed when the required jurisdiction or authority cannot be determined.

The research paper explains the architecture. The standard package defines compliance. RAILS v1.4 therefore separates the framework version from independently versioned capability, delegation, task, property-access, evidence, jurisdiction, and test profiles. A prose-aligned product must not market itself as certified.

framework: rails/1.4
implementation: vendor_product_and_version
conformance_class: C3
profiles:
  capability: rails-showing/1.0
  delegation: rails-delegation-profile/1.0
  task: rails-task-profile/1.0
  evidence: rails-evidence/1.0
  jurisdiction: ca-on/1.0
test_pack: rails-conformance/1.0.0
tested_build_digest: sha256:...
certifier: independent_or_board_approved
issued_at: 2026-07-22
expires_at: defined_by_certification_policy
limitations: machine_readable
evidence_url: public_verification_record

The v1.4 standards package

• RAILS Delegation Profile: principal, workload, audience, purpose, subdelegation, token exchange, sender binding, and continuous revocation.
• RAILS Task Profile: lifecycle states, concurrency, idempotency, deadlines, signed events, retries, cancellation, reconciliation, and compensation.
• RAILS Property Access Profile: appointment-to-entry separation, just-in-time human delivery, device binding, emergency revocation, and access evidence.
• RAILS Evidence Profile: canonical event envelope, trace propagation, tamper evidence, privacy minimization, export, retention, correction, and legal hold.
• RAILS Conformance Kit: schemas, registries, test vectors, adversarial fixtures, reference adapters, certification classes, and public verification records.
• Accountability and Jurisdiction Annexes: consumer notice and recourse, responsibility allocation, contract controls, insurance evidence, and counsel-approved local rule profiles.

The preceding sections set the architectural guardrails, policy language, and adoption path. Several practical layers remain underspecified. Boards, MLSs, and vendors that adopt RAILS early will need to fill these gaps before certification can be enforced consistently and before consequential workflows can be trusted at scale.

Schemas, certification, and accreditation mechanics

Capability manifests need a published schema, a conformance test suite, and a clear accreditation body or bodies. RAILS should not become a single-vendor seal. The goal is a portable, reviewable profile that a board’s technical, legal, privacy, and security reviewers can audit independently.

• Publish a JSON/YAML capability-manifest schema with typed fields for actor, purpose, data class, input/output bounds, retention class, and revocation.
• Require architecture diagrams, a field-level data inventory, model and subprocessor lists, retention matrices, and training-use commitments.
• Define re-certification triggers: model changes, subprocessor additions, scope expansions, incidents, or material policy updates.
• Make revocation immediate and granular so a board can disable one capability without disabling an entire vendor.
• Publish conformance tests for schema bounds, permission denial, field leakage, bulk extraction, and audit completeness.

vendor: example-cma-vendor
capability: cma.prepare
rails_profile: 1.0
evidence:
  - architecture_diagram.pdf
  - data_flow_diagram.pdf
  - field_inventory.csv
  - model_and_subprocessor_list.csv
  - retention_matrix.csv
  - training_use_commitment.pdf
  - tenant_isolation_test_report.pdf
  - oauth_scopes.yaml
  - tool_schema.yaml
  - red_team_results.pdf
  - fair_housing_test_results.pdf
  - incident_response_plan.pdf
  - deletion_evidence.pdf
  - sbom.json
  - aibom.json

Liability, insurance, and enforcement

The framework states that the model is not the accountable actor, but it does not yet map accountability onto errors-and-omissions coverage, vendor indemnification, or disciplinary enforcement. A realtor who signs an AI-prepared offer needs to know whether their E&O policy covers the AI’s mistake and whether the vendor stands behind its validation logic.

Enforcement should be described as a process: complaint intake, evidence preservation, capability suspension, notice, appeal, and public revocation where warranted. The audit trail described in Section 8 is what makes that process fair and fast.

Fair-housing proxies and consumer disclosure

Section 10 prohibits protected-class criteria, but it does not yet catalogue the proxies that commonly replace them. A request for a “family neighbourhood” or “good schools” can steer by household composition or ethnicity if the system lets those phrases pass through to ranking or ad targeting.

• Maintain a public catalogue of prohibited features and proxy features, with examples: school-quality-only filters, crime-rate steering, ‘family-friendly’ as a ranking signal, and inferred household composition.
• Reject or transform vague criteria into objective, legally appropriate housing attributes: budget, commute, property type, accessibility, lot size, transit, and proximity to named amenities.
• Log the objective criteria that include or exclude each result so the recommendation is auditable.
• Disclose to consumers when they are interacting with an AI, when they are being shown AI-generated content, and how to escalate to a licensed human.
• Test ad delivery and recommendation outputs for disparate impact before and after launch.

Consumer disclosure is not a footnote. If a buyer searches on an AI-powered portal and the model ranks or excludes communities, the consumer should see that the ranking is AI-generated, the criteria used, and a clear path to a human realtor.

Appraisal, valuation, and finance regulation

CMA preparation and market analysis sit close to appraisal and mortgage underwriting. RAILS needs explicit boundaries so that a governed CMA tool does not drift into unlicensed appraisal or automated underwriting advice. In the United States, appraisal independence rules and the appraisal standards regulated by USPAP and FIRREA create bright lines that an AI must not cross. In Canada, provincial appraisal legislation and lender requirements vary.

• Label every CMA or valuation support output as a realtor-prepared opinion, not an appraisal, and show the assumptions and data-as-of date.
• Prohibit the model from representing itself as an appraiser, automated valuation model, or lender underwriter.
• Keep mortgage pre-qualification, rate advice, and financing recommendations inside licensed mortgage channels.
• Document jurisdiction-specific review: USPAP/FIRREA in the U.S., provincial appraisal acts and lender rules in Canada, and local MLS valuation policies everywhere.

Accessibility, language access, and small-brokerage equity

Governance programs can become a tax on small brokerages and solo agents. If certification is expensive, integration is complex, and documentation is only in English, the framework will advantage well-resourced incumbents and lock out the long tail of the profession.

• Provide model policy clauses and certification checklists in plain language and, where possible, in the languages spoken in the board’s market.
• Offer a reference open-source capability gateway, conformance tests, and sample manifests so smaller vendors and self-managed brokerages can participate.
• Publish a small-brokerage cost model: minimum viable controls, phased adoption, and free or low-cost audit tooling.
• Require accessibility conformance (WCAG, AODA, ADA) for consumer-facing agentic interfaces and for the approval UX used by Realtors.
• Mandate data portability for audit logs, capability manifests, and member settings to reduce vendor lock-in.

Incident response, model evaluation, and RAG controls

Section 8 lists threats; Section 14 lists tests. The missing layer is the operational playbook: who is paged, what is preserved, how a capability is frozen, and how the board is notified. Long-term memory and retrieval-augmented generation also need their own controls.

• Maintain a runbook for suspected prompt injection, data exfiltration, tool misuse, model drift, and connector compromise.
• Define a kill switch that disables a capability or vendor without disabling the member’s core systems.
• Run recurring red-team exercises against the real capability surface, not just the chat interface.
• Benchmark models on real estate tasks under the RAILS harness; do not rely on generic leaderboards for consequential work.
• Isolate per-tenant retrieval indexes, set expiry and re-indexing rules, and prohibit protected data from entering shared vector stores.

trigger:
  condition: unauthorized_extraction_detected
response:
  - revoke_capability(capability_id, reason)
  - preserve_audit_trail(trace_id)
  - notify_security_team(tenant, actor, capability, timestamp)
  - notify_board_liaison_within(policy.incident_sla)
  - freeze_related_sessions(actor_id, capability_id)
  - open_incident_record(reference: trace_id)

Human-review UX and realtor training

A signature bound to a document hash is strong only if the licensee actually read and understood the instrument. Approval UX must make manipulation, fatigue, and click-through signing structurally difficult. Realtors also need training on what to verify when an AI prepares a CMA, offer, disclosure, or social post.

• Show the exact artifact, its provenance, and a diff against any earlier version at the approval moment.
• Require explicit confirmation of key facts: data-as-of date, comparable set, form version, parties, price, deposit, and conditions.
• Use step-up authentication for Tier 4 and Tier 5 actions so the approval is attributable.
• Publish a training module on AI-assisted review: how to spot hallucinated comparables, wrong form selection, and missing disclosures.
• Track human-review completion rates, override reasons, and error catches as operational metrics.

Governance is not finished when the policy is published. It is finished when the controls are testable, the liability is allocated, and the human checkpoint is designed so it cannot be skipped.

Consumers will choose convenient interfaces. Professionals will choose tools that save time. Portals and model providers will continue competing for the point at which intent becomes workflow. The durable response is not to pretend that shift can be stopped. It is to define the trust infrastructure through which it operates.

The useful boundary is custody versus capability; persistent storage versus controlled transient processing; autonomous action versus accountable approval; probabilistic explanation versus deterministic calculation; and ungoverned distribution versus auditable access.

Better interfaces should operate through board-defined trust—not around it.

Boards that define identity, permission, provenance, quality, interoperability, auditability, certification, and revocation can protect data while improving member capability. Boards that focus only on yesterday’s interface may preserve the feed while losing influence over tomorrow’s consumer journey.

Product claims are factual only to the extent supported by the linked publisher. The RAILS architecture, tiers, policy language, and roadmap are proposals by the authors. Legal requirements vary and must be re-verified before adoption.

1. 01

   Zillow

   Zillow debuts the real estate app in ChatGPT (Oct. 6, 2025)
2. 02

   Zillow

   How the app preserves listing reach and industry rules (Oct. 9, 2025)
3. 03

   OpenAI

   Introducing apps in ChatGPT and the Apps SDK (Oct. 6, 2025)
4. 04

   Anthropic

   Introducing the Model Context Protocol (Nov. 25, 2024)
5. 05

   A2A Project

   Agent2Agent Protocol specification and task lifecycle
6. 06

   Model Context Protocol

   Authorization specification (Nov. 25, 2025)
7. 07

   Model Context Protocol

   Security best practices and token-passthrough prohibition
8. 08

   IETF

   RFC 8693: OAuth 2.0 Token Exchange
9. 09

   IETF

   RFC 9449: OAuth 2.0 Demonstrating Proof of Possession
10. 10

    IETF

    RFC 9700: Best Current Practice for OAuth 2.0 Security
11. 11

    OpenID Foundation

    Shared Signals and Continuous Access Evaluation
12. 12

    W3C

    Trace Context: distributed trace propagation
13. 13

    OpenTelemetry

    Semantic conventions for traces, logs, metrics, and events
14. 14

    HouseCanary

    Google Home Discovery national expansion (June 11, 2026)
15. 15

    RPR

    2026 AI Adoption Survey: 82% of real estate agents use AI
16. 16

    OpenAI

    How data is used to improve model performance
17. 17

    OpenAI

    ChatGPT Search
18. 18

    Anthropic

    Consumer data-use choices for Claude
19. 19

    Anthropic

    Enabling and using web search
20. 20

    Zillow

    Real-Time Touring and ShowingTime-integrated booking
21. 21

    ShowingTime+

    Real-Time Availability API for brokers
22. 22

    BrokerBay

    MLS-wide showing-management ecosystem
23. 23

    Touchbase

    Showing availability, confirmation, instruction, and feedback workflows
24. 24

    Aligned Showings

    Scheduling, approvals, calendars, messaging, and routing
25. 25

    SentriLock

    SentriKey Showing Service scheduling links
26. 26

    Instashowing

    Showing-management workflow
27. 27

    Showingly

    REST API and remote MCP access for AI agents
28. 28

    SkySlope

    Transaction-management APIs
29. 29

    SkySlope

    Offers API reference
30. 30

    CREA

    CREA WEBForms powered by TransactionDesk
31. 31

    Lone Wolf

    TransactionDesk, zipForm, Transact, Deals, and WolfConnect API documentation
32. 32

    dotloop

    OAuth 2.0 public API
33. 33

    Form Simplicity

    Scoped transaction API
34. 34

    DocuSign

    Agreement and eSignature APIs
35. 35

    DocuSeal

    Open-source self-hosted signing with API support
36. 36

    Nano-PDF

    Open-source AI PDF-editing CLI
37. 37

    Follow Up Boss

    REST API and webhook documentation
38. 38

    HighLevel

    CRM, conversation, calendar, opportunity, and webhook API
39. 39

    Lofty

    Real estate CRM developer API
40. 40

    NIST

    SP 800-207: Zero Trust Architecture
41. 41

    NIST

    AI 600-1: Generative AI Profile
42. 42

    OWASP

    Top 10 for Agentic Applications 2026
43. 43

    RESO

    Current specifications and supporting materials
44. 44

    RESO

    Web API, IDX payloads, and live web-application queries
45. 45

    NAR

    Internet Data Exchange Policy Statement 7.58 (Jan. 1, 2026)
46. 46

    CREA

    REALTOR.ca DDF®
47. 47

    OPC Canada

    PIPEDA requirements in brief
48. 48

    OHRC

    Freedom from discrimination in housing
49. 49

    HUD

    Guidance on housing advertising through digital platforms