<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Third-Party-Credentials on Start AI Tools - Presented by Intent Solutions</title><link>https://startaitools.com/tags/third-party-credentials/</link><description>Recent content in Third-Party-Credentials on Start AI Tools - Presented by Intent Solutions</description><generator>Hugo</generator><language>en-US</language><copyright>Intent Solutions. All rights reserved.</copyright><lastBuildDate>Fri, 16 Oct 2026 08:00:00 -0600</lastBuildDate><atom:link href="https://startaitools.com/tags/third-party-credentials/index.xml" rel="self" type="application/rss+xml"/><item><title>When a Third-Party CI Credential Expires, the Deploy Fallback Has to Already Live on the VPS</title><link>https://startaitools.com/posts/when-third-party-ci-credentials-expire-the-deploy-fallback-lives-on-the-vps/</link><pubDate>Fri, 16 Oct 2026 08:00:00 -0600</pubDate><guid>https://startaitools.com/posts/when-third-party-ci-credentials-expire-the-deploy-fallback-lives-on-the-vps/</guid><description>&lt;p&gt;GitHub Actions deploys that depend on a third-party OIDC identity silently 402 deep in the run when that identity&amp;rsquo;s plan ends, and the run summary still turns green while production stays stale. What you have at the end of this post is a VPS-resident deploy script that needs no third-party key, plus a SHA-pin guard that proves the manual path can&amp;rsquo;t ship content that diverged from the merged PR, so the next expiry becomes a one-line recovery instead of a multi-day outage.&lt;/p&gt;</description></item></channel></rss>