Something new at Opendoor

Give agents access to repairs without handing over the purchase

Published Nov 8, 2026

You’re the security / reliability engineer. Your team is in the room.

The setting

buys homes from sellers, prepares them, and resells them. Its offers those homes through online listings, with licensed real estate professionals who work with buyers' agents from offer to closing.

An invitation to help with repairs leaves the agent's authority unsettled.

Direct participation protects the buyer's time, while a narrow grant protects decisions the buyer expects to keep.

Who you’d be doing this for

“I forwarded the terms during my lunch break, then my agent asked whether she could answer for me. I hadn't agreed to that.”

Ritva Holmberg · Home buyer · a character in this brief

A pilot participant who wants an agent to review repair terms while retaining control over accepting them.

What is at stake

Nine of 12 buyers want their agents involved in repairs, but disagree about what those agents should control. You must weigh useful delegation against authority buyers may never intend to give away.

Why it isn’t already fixed

Every obvious fix costs something else. That’s the part you’d have to decide.

  • useful agent participation vs buyer control
  • prompt revocation vs dependency availability
  • shared gateway consistency vs distinct access rules
  • a narrow first launch vs learning about delegated action

Why Opendoor

Repair negotiations on company-owned homes bring buyers, their agents, and internal operations into the same purchase without giving them the same authority.

Written with these in mind

Application security buildersIdentity-focused reliability engineersSecurity engineers embedded with product engineering

Not your kind of problem? 18 more at Opendoor, or browse every organization.

Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.

The organization context comes from public information. The situation and characters are written for the brief.

Job postings it was written from

Public descriptions of the work at Opendoor. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.

  • Application Security Engineer (opens in a new tab)
    • Partner with engineering teams to harden authentication, authorization, and input validation across our codebase and production services, including the GraphQL gateway (Apollo) and our Kubernetes workloads - while driving a shift-left strategy that catches vulnerabilities before they ship.
    • Define, build and operate Opendoor’s application vulnerability identification capability - the tooling, triage workflow and remediation techniques across our consumer products, internal admin tools and GraphQL API powering home acquisition, resale, mortgage, title and escrow.
  • Infrastructure Security Engineer (opens in a new tab)
    • Cloud or infrastructure security experience, with deep AWS expertise - you can read a CloudTrail event, write a service control policy, and explain why a particular identity trust policy is dangerous, all in the same conversation.

This is the setup. The work is inside.

Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.

Other live briefs connected to this one, and what connects them.

Similar problems at other organizations

Like this one, each of these is about people starting something and never quite finishing it.