Most security teams wouldn’t dream of exposing an admin panel on a public login screen without multi-factor authentication, let alone using a password like “123456.”
But when it’s a third-party vendor? That kind of risk often slips through the cracks.
That’s precisely what happened when Paradox.ai, an AI hiring platform used by major enterprises including McDonald’s, left its backend open to the internet. As WIRED reported¹, a security researcher found the admin login embedded in the applicant page, logged in with a weak password, and gained access to sensitive candidate data across multiple customers.
McDonald’s didn’t build the platform. And like most companies, they likely didn’t apply the same threat modeling rigor to their vendor systems that they use internally. That’s not negligence, it’s the industry norm.
And that’s the problem.
Vendor Risk Isn’t Just About Compliance Anymore
In most enterprises, third-party risk management continues to rely on certifications, assessment forms, and contractual obligations. SOC 2? Check. ISO 27001? Check. Security questionnaire? Check.
But none of those things would have revealed what a basic architecture diagram could have:
- An admin login exposed on a public page
- No MFA on privileged access paths
- Weak passwords in a production environment
This wasn’t a sophisticated breach. It was a visibility failure.
And it’s a case study in why architectural security needs to extend beyond your own systems, especially when sensitive workflows are outsourced.
We Don’t Threat Model the Things We Don’t Build
And that’s understandable.
When you license a SaaS product or integrate with a third-party API, your goal isn’t to reverse-engineer their architecture. It’s to trust that their security posture is sound. You expect due diligence. You rely on contracts. You check the boxes.
But here’s the flaw in that logic:
Threat modeling isn’t just about what you build. It’s about what your users and your data depend on.
In this case, McDonald’s was relying on a vendor to handle a high-volume hiring workflow. That vendor, Paradox.ai, made architectural decisions about access, authentication, and interface design that ultimately put McDonald’s brand in the headlines.
And that’s what makes this so frustrating. A security architect inside McDonald’s would have flagged these issues from a mile away: a public admin interface, no MFA, weak credential enforcement. However, because it was a third-party app, it likely never went through their internal threat modeling process.
And that’s not a McDonald’s problem. It’s how most organizations operate today.
Model the Integration, Not the Vendor
If a system touches sensitive data, drives business-critical workflows, or connects to your environment, it should be modeled—even if you didn’t build it. That doesn’t mean you need source code or internal documentation. It means modeling from the outside in, based on how that system behaves in your environment.
The goal is to proactively model the parts of a third-party system your business relies on so you can understand where it intersects with your architecture and where it may introduce risk.
That starts by focusing on where the platform connects, what it processes, and how those pathways are secured.
In practice, this includes:
- Identifying the assets at risk (e.g., data, access, functionality)
- Mapping integration points (APIs, SSO flows, webhook callbacks)
- Documenting user roles and access patterns (e.g., who logs in and what they can reach)
- Identifying trust boundaries (where external platforms cross into internal infrastructure)
- Flagging authentication assumptions (e.g., does login enforcement depend on the vendor?)
These are foundational questions that help you assess real-world risk before it becomes real-world impact.
Model What You Depend On
ThreatModeler helps security, architecture, and procurement teams move beyond checklists and gain real visibility into the systems they build, and the ones they buy. By modeling how third-party platforms interface with your systems, users, and data, you can identify architectural risks that compliance documentation may overlook.
Because even if you didn’t build the system, you’re still responsible for what it exposes.
Footnote:
¹ Andy Greenberg, “McDonald’s AI Hiring Chatbot Left the Door Open to Hackers,” WIRED, July 9, 2025.
Learn More
If you’d like to understand how ThreatModeler helps teams revisit assumptions, identify critical dependencies, and keep threat models current as conditions change, visit our contact our team to start a conversation.
Frequently asked questions
What happened in the McDonald's AI hiring platform breach?
A security researcher found the admin login for Paradox.ai, the AI hiring platform McDonald's used, exposed on its applicant page. With a weak password and no multi-factor authentication in place, the researcher got into the backend and could see sensitive candidate data across multiple customers. WIRED reported the incident in July 2025.
Why should you threat model third-party integrations?
Because you are still responsible for what a vendor exposes, even if you didn't build the system. Certifications, questionnaires and contracts confirm a vendor's general posture, but they don't show how the platform connects to your environment, who can log in, or where your data crosses into it. A threat model of the integration does.
Can you threat model a vendor system without its source code?
Yes. You model the integration from the outside in, based on how the system behaves in your environment. You don't need source code or internal documentation, only a clear view of what the platform connects to, what data it processes, who has access and how those paths are secured.
What should a third-party integration threat model include?
Start with the assets at risk, such as data, access and functionality. Then map the integration points (APIs, SSO flows and webhook callbacks), document user roles and access patterns, identify the trust boundaries where the vendor crosses into your infrastructure, and flag any authentication controls that depend on the vendor.
Aren't SOC 2 and ISO 27001 enough to assess vendor risk?
They help, but they don't replace an architectural review. A SOC 2 report or ISO 27001 certificate would not have revealed an admin login exposed on a public page, missing MFA on privileged access, or weak passwords in production. Those are design issues, and a basic architecture diagram of the integration would have shown them.
