Popular Lesson
1.11 – Open Source, Third Party APIs, and Contributing Parties (Know What You’re Shipping) Lesson
What you'll learn
Assign clear ownership: Designate one accountable person for each third party component and define what they must monitor.
Set an approval path: Create a standard review process that matches risk level, from low friction approvals to deeper legal and security checks.
Maintain an SBOM: Build a software bill of materials with exact versions, sources, and digital signatures where possible.
Control change with version pinning: Pin versions and avoid unexpected updates that can break production or change behavior overnight.
Enforce least privilege: Scope tool and MCP credentials to only the access required, with expiry and monitoring in place.
Operate with awareness: Monitor for vulnerabilities, vendor deprecations, policy and pricing changes, and have exit plans ready.
Lesson Overview
Modern AI systems are assembled, not handcrafted. Most teams mix foundation models, open source libraries, internal and external databases, APIs, MCP connections, and tools. This saves time, but it also means code and data from outside your organization become part of your product. You need to know exactly what you are using and whether it is safe.
This lesson shows a practical people, process, and technology approach for selecting, approving, operating, and retiring third party components. On the people side, you will see why a single accountable owner per component works better than vague team ownership. For process, you will learn how a standard approval flow supports both speed and safety, with deeper review for anything touching sensitive data. On the technology side, you will learn how an SBOM, version pinning, automated scanning, and least privilege for tools and MCP connections reduce risk day to day.
You will also see how to monitor what runs in production, respond to vulnerabilities, track vendor changes, and keep vendor contracts and support paths ready. Two examples illustrate the approach in context, from adopting an open source embedding model to granting a workflow bot read only access to a finance MCP. The lesson closes with why every major dependency needs an exit plan.
Who This Is For
If you are assembling AI features using external components, this lesson will help you ship safely and stay in control as things change.
- Product managers deciding which models, APIs, or MCPs to adopt
- Engineering leads responsible for third party libraries and integrations
- Security and legal partners reviewing licenses and data exposure
- Data and analytics teams evaluating open source models
- Operations teams running AI systems in production
- Founders and solo builders who need a light but reliable safety net
- Comprehensive, Business-Centric Curriculum
- Fast-Track Your AI Skills
- Build Custom AI Tools for Your Business
- AI-Driven Visual & Presentation Creation
Where This Fits in a Workflow
Use this lesson when you are planning to add or change any external component in your AI stack. The approach applies when selecting a new library, adopting a model, wiring a tool to a database, or connecting a bot to an MCP.
For example, when a team proposes an open source embedding model, route it through the standard approval path, document it in your SBOM with exact version and source, and set automated scans. Or, when a workflow bot needs financial data, grant read only credentials with an expiry, monitor usage, and log actions for review. These steps protect build speed during development and protect stability once you are live.
Technical & Workflow Benefits
The old way is ad hoc: teams add libraries or APIs, ownership is unclear, versions float, and updates land overnight. This leads to unexpected behavior changes, security gaps, and rushed fixes when a vendor deprecates an endpoint.
The approach in this lesson replaces guesswork with clarity. A named owner tracks maintenance status, vulnerabilities, and license terms. A standard approval process gets low risk items through quickly, while high risk items receive legal and security review. An SBOM lists every component with exact versions and sources, and artifacts are digitally signed where possible. Version pinning prevents surprise changes. Tool and MCP connectors run with least privilege using scoped, expiring credentials. Production monitoring catches new vulnerabilities and deprecations early, and vendor contract details are on hand when things break. In practice, this means faster, safer adoption of an open source model and safer automation when a bot reads from your finance MCP.
Practice Exercise
Scenario: Your team wants to add a new open source embedding model and connect a workflow bot to your finance MCP for read only account data.
Steps:
- Ownership and approval
- Assign one accountable owner for the embedding model and one for the finance connection.
- Run both through your standard review. Flag the MCP connection as higher risk due to financial data.
2. Technology controls
- Add both components to your SBOM with exact versions, sources, and signatures if available.
- Pin versions and disable automatic updates for the model.
- Create scoped, read only credentials for the MCP connection with a 90 day expiry.
3. Operations
- Set automated scans for vulnerabilities and licenses on the model
- Create alerts for vendor deprecations and API or MCP policy changes.
- Define an exit plan for both items, including how to revoke access and a backup option.
Reflection: If the model is deprecated or the MCP vendor changes pricing, how quickly can you switch, and what steps have you already prepared to make that change safe?
Course Context Recap
This lesson focuses on knowing what you are shipping when you use open source, third party APIs, MCP connections, and tools. You learned how to assign ownership, run a clear approval process, keep an SBOM, lock versions, enforce least privilege, monitor production, and plan exits. These practices support your broader AI risk work and help you keep systems safe as they evolve. Continue through the course to see how these controls connect to day to day operations and how to respond when vendors change features, policies, or costs.