TL;DR: With a managed model API or platform, the provider secures its infrastructure, the hosting of the model, its own data handling under its terms, and baseline platform controls. You remain responsible for identity and access to your account and keys, what data you send and under which settings (retention, training use, residency), your application's design: prompt injection exposure, tool permissions, output handling, retrieval authorization, and monitoring, abuse prevention and compliance for your use case. The model being "secured by the vendor" does not make your agent safe.
How to approach it
Recall the general cloud shared-responsibility idea, then split a managed AI service into layers and assign each. Give concrete examples of customer-side failures that the provider cannot prevent.
A strong answer
Provider
Infrastructure, model hosting
platform controls
Its data handling
under its terms
Outcome, safe: Provider secures
Check terms and attestations
You
Identity, keys, data sent
configuration
App security around the model
injection, tools, output
Never transferred
Outcome, safe: You secure
Most incidents start here
| Layer | Provider | Customer |
|---|---|---|
| Physical, network, hosting | Data centres, hardware, isolation between customers | Nothing |
| Model service | Model hosting, patching, safety training, provider-side abuse monitoring | Choosing models and versions; testing them for your use |
| Data handling | Honouring stated retention, training-use and residency terms | Choosing settings, contracts and regions; deciding what data to send |
| Identity and access | Offering IAM, key management, private networking | Configuring them: scoped keys, rotation, least privilege, private endpoints |
| Application | None | Prompt design, retrieval authorization, tool permissions, output handling, rate limits |
| Monitoring and response | Platform logs and some abuse signals | Logging your app's prompts and tool calls, detection, incident response |
| Compliance | Certifications for the service | Your use case's obligations (privacy, sector rules, AI regulation) |
Customer-side failures the provider cannot prevent.
- An agent built on a secure model API still follows instructions injected through retrieved documents and emails, and can misuse the tools you gave it.
- A RAG application that retrieves without checking user permissions leaks data regardless of where the model runs.
- API keys committed to repositories are your incident, even if the provider detects and notifies.
- Sending personal data to a service configured to retain it, or to a region you are not allowed to use, is your compliance failure.
Questions to ask a provider. Data retention and training-use terms; isolation between customers; regional processing; security certifications; how model updates are communicated and whether versions can be pinned; incident notification commitments; private networking options.
Self-hosted models move the line. Running open weights on your own infrastructure makes you responsible for the hosting layer too: serving software, patching, GPU isolation, weight protection.
What interviewers probe next
- "The provider changes the model version. Whose risk is that?" Yours to manage: pin versions where possible and re-run security and safety evaluations on change.
- "The provider offers a content filter. Are you covered for prompt injection?" No; filters reduce some risks probabilistically, and application-level controls remain your job.
- "How would you document this?" A responsibility matrix per AI service in the vendor risk review, linked to your controls.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A company uses a managed AI platform for a customer support agent and assumes the provider handles security because the model is 'secured by the vendor'.
Start here
What does the provider secure?
Where does the provider's responsibility stop?
Its infrastructure, the hosting of the model, its own data handling under its terms, and baseline platform controls. That is real and valuable, but it ends at the platform boundary.
Carry it forwardProviders secure the platform, not your use of it.
Weak answerAssuming the provider secures your application.
Constraint changes
What remains yours?
Which decisions did your team make?
Identity and access to your account and keys, what data you send and under which settings (retention, training use, residency), your application design (prompt injection exposure, tool permissions, output handling, retrieval authorisation), and monitoring, abuse prevention and compliance for your use case.
Carry it forwardAccess, data settings, app design and monitoring are yours.
Weak answerTreating injection as the vendor's problem.
Constraint changes
What if the agent can issue refunds through a tool?
Who defined the refund tool?
The provider has no idea what a refund is or who may receive one. Authorisation, limits and confirmations on the refund tool are entirely yours. A well-secured model can still be manipulated into calling your tool.
Carry it forwardTool authority is your responsibility.
Weak answerRelying on the model's safety training.
Constraint changes
What if a developer's API key leaks?
Whose credential was it?
That is your incident: rotate the key, review usage and costs, and check what data was accessible. Use workload identity or a gateway that holds keys rather than distributing them to developers.
Carry it forwardAccount credentials are your responsibility.
Weak answerWaiting for the provider to notice abuse.
Constraint changes
How would you make the split explicit?
Could each team name what it owns?
Write a responsibility matrix per AI service: provider controls, your controls, and shared items such as logging. Review the provider's terms and settings, then assign owners for each of your items.
Carry it forwardDocument the split and assign owners.
Weak answerLeaving responsibilities implied.
Now defend it
How would you correct the assumption?
Show a responsibility matrix: the provider secures infrastructure, model hosting and its data handling; you own account access and keys, data settings, application design including injection and tool authorisation, output handling, retrieval permissions, monitoring, abuse prevention and compliance, each with an owner.
How it's scored
Weak: "The cloud provider secures it."
Hire: Splits layers correctly and names application-level risks as the customer's.
Strong Hire: Covers data settings, version changes, provider due diligence and how self-hosting shifts responsibility.
Common mistakes
- Assuming provider safety training covers application security.
- Ignoring retention and training-use settings.
- No plan for model version changes.