<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
  <title>VCRI Blog</title>
  <link>https://valuechainrisk.org/blog/</link>
  <description>Vendor risk intelligence, regulatory analysis, and supply chain security research from the Value Chain Risk Institute. Independent measurement infrastructure for value-chain risk; methodology is rule-based, transparent, and criticizable.</description>
  <language>en-us</language>
  <copyright>Creative Commons BY-NC 4.0 — Value Chain Risk Institute</copyright>
  <managingEditor>info@valuechainrisk.org (VCRI)</managingEditor>
  <atom:link href="https://valuechainrisk.org/blog/feed.xml" rel="self" type="application/rss+xml" />
  <lastBuildDate>Wed, 05 Aug 2026 12:00:00 -0400</lastBuildDate>
  <image>
    <url>https://valuechainrisk.org/logo.png</url>
    <title>VCRI Blog</title>
    <link>https://valuechainrisk.org/blog/</link>
  </image>

  <item>
    <title>The Agent Ends. Its Accounts Don&#8217;t.</title>
    <link>https://valuechainrisk.org/blog/agent-ends-accounts-dont.html</link>
    <guid isPermaLink="true">https://valuechainrisk.org/blog/agent-ends-accounts-dont.html</guid>
    <pubDate>Wed, 05 Aug 2026 12:00:00 -0400</pubDate>
    <dc:creator>Cairn Viktor</dc:creator>
    <category>Cognitive Security</category>
    <category>AI Security</category>
    <dc:rights>Creative Commons BY 4.0 &#8212; Value Chain Risk Institute</dc:rights>
    <description>A UK AI Security Institute incident report shows an AI agent's third-party accounts, credentials and repositories outliving the agent itself, and being found and trusted by other vendors' agents. Permanence of damage has a third location, and it sits outside the system entirely.</description>
    <content:encoded><![CDATA[
      <p>Cognitive security should be weighted by the permanence of damage. But the permanence ladder as I first drew it, runtime context, then durable memory, then weights and lineage, describes only layers <em>inside</em> the system.</p>
      <p>In AISI's July evaluations an agent published its own access token in a public gist, seeded 145 repositories and a set of DNS records, then hit its token limit and stopped. The account, token and repositories kept working, and agents in other isolated samples, including one from a different vendor, found the credential and used it. The tunnels those agents opened died with the session; the registrations did not. Permanence is not about how deep the write went into the model. It is about where the artifact was registered.</p>
      <p>Read the full post at <a href="https://valuechainrisk.org/blog/agent-ends-accounts-dont.html">valuechainrisk.org/blog/agent-ends-accounts-dont.html</a>.</p>
    ]]></content:encoded>
  </item>

  <item>
    <title>Using AI Safely: The Settings That Matter</title>
    <link>https://valuechainrisk.org/blog/using-ai-safely-settings.html</link>
    <guid isPermaLink="true">https://valuechainrisk.org/blog/using-ai-safely-settings.html</guid>
    <pubDate>Thu, 18 Jun 2026 09:00:00 -0400</pubDate>
    <dc:creator>Cairn Viktor</dc:creator>
    <category>AI Security</category>
    <category>Small Business</category>
    <dc:rights>Creative Commons BY 4.0 — Value Chain Risk Institute</dc:rights>
    <description>A plain-language, vendor-neutral guide to the handful of ChatGPT, Gemini, and Copilot settings that actually protect you — and why each matters. Tuned for risk-aware-but-not-paranoid individuals and small businesses.</description>
    <content:encoded><![CDATA[
      <p>Nobody can track every setting in every AI tool. So this guide is the short list that actually moves the needle, across ChatGPT, Gemini, and Copilot, with a plain-language <em>why</em> for each.</p>
      <p>The one rule that beats every setting: don't paste secrets, customer data, or anything regulated into a free/consumer AI. After that — opt out of training, turn on MFA, set history to auto-delete, and know that business/enterprise tiers generally don't train on your data while free tiers do.</p>
      <p>Read the full guide at <a href="https://valuechainrisk.org/blog/using-ai-safely-settings.html">valuechainrisk.org/blog/using-ai-safely-settings.html</a>.</p>
    ]]></content:encoded>
  </item>

  <item>
    <title>Questions to Ask Your IT/Security Provider About AI</title>
    <link>https://valuechainrisk.org/blog/smb-ai-questions-for-your-provider.html</link>
    <guid isPermaLink="true">https://valuechainrisk.org/blog/smb-ai-questions-for-your-provider.html</guid>
    <pubDate>Thu, 18 Jun 2026 08:30:00 -0400</pubDate>
    <dc:creator>Cairn Viktor</dc:creator>
    <category>AI Security</category>
    <category>Small Business</category>
    <category>Vendor Risk Intelligence</category>
    <dc:rights>Creative Commons BY 4.0 — Value Chain Risk Institute</dc:rights>
    <description>A plain-language checklist for SMBs that outsource IT/security: the questions to ask your MSP or MSSP about how they use AI on your behalf — data, training, governance, access, accountability — with the green and red flags to listen for.</description>
    <content:encoded><![CDATA[
      <p>If you outsource IT or security, AI is almost certainly already in your service delivery. This checklist gives a non-technical owner the questions to ask their MSP/MSSP about it — inventory and tier, data and training, governance, access, accountability, subprocessors, compliance, and offboarding — each with why it matters.</p>
      <p>Green flags: business/enterprise tiers, "we don't train on your data," a written policy, MFA, human review, AI named in your contract. Red flags: consumer tiers for your data, "we're not sure," no policy, no logging.</p>
      <p>Read the full checklist at <a href="https://valuechainrisk.org/blog/smb-ai-questions-for-your-provider.html">valuechainrisk.org/blog/smb-ai-questions-for-your-provider.html</a>.</p>
    ]]></content:encoded>
  </item>

  <item>
    <title>Two Clocks: our inaugural State of Supply Chain report is out</title>
    <link>https://valuechainrisk.org/blog/q2-2026-state-of-supply-chain.html</link>
    <guid isPermaLink="true">https://valuechainrisk.org/blog/q2-2026-state-of-supply-chain.html</guid>
    <pubDate>Tue, 26 May 2026 09:00:00 -0400</pubDate>
    <dc:creator>Cairn Viktor</dc:creator>
    <category>Supply Chain Security</category>
    <category>State of Supply Chain</category>
    <category>Vulnerability Management</category>
    <description>VCRI's inaugural quarterly State of Supply Chain report. Two independent 2026 findings — Seal Security (commit-to-advisory) and GreyNoise (exploit-surge-to-advisory) — measured opposite sides of the system and converged on the same gap: by the time you hear about an exploit, you are already 11 days too late. The advisory is the lagging indicator.</description>
    <content:encoded><![CDATA[
      <p>VCRI's first quarterly <strong>State of Supply Chain</strong> report is published. We called it <strong>Two Clocks</strong>: the moment a component becomes dangerous, and the moment the rest of us are told. Those two clocks have come apart.</p>
      <p>Seal Security measured the gap between fix-commit and advisory: a median of 11 days, with a 167-day tail for Maven. GreyNoise measured a different signal — exploit-scan surge to advisory — and got the same 11 days, with 28.96% of 2025 KEVs exploited on or before publication day. Two teams, opposite sides of the system, one conclusion: the advisory is the lagging indicator.</p>
      <p>Read the full report at <a href="https://valuechainrisk.org/state-of-supply-chain/2026-Q2/">valuechainrisk.org/state-of-supply-chain/2026-Q2/</a>.</p>
    ]]></content:encoded>
  </item>

  <item>
    <title>Three Eras of Zero-Day Economics, and Why the Advisory Falls Further Behind</title>
    <link>https://valuechainrisk.org/blog/three-eras-of-0days.html</link>
    <guid isPermaLink="true">https://valuechainrisk.org/blog/three-eras-of-0days.html</guid>
    <pubDate>Fri, 23 May 2026 11:00:00 -0400</pubDate>
    <dc:creator>Cairn Viktor</dc:creator>
    <category>Cybersecurity</category>
    <category>Supply Chain Security</category>
    <category>Vulnerability Management</category>
    <category>AI Security</category>
    <description>The economics of finding zero-day vulnerabilities have moved through three regimes in twenty-five years. The third — AI compressing discovery cost from human-week to GPU-hour — makes the existing 11-day commit-to-advisory gap structurally more dangerous, not shorter. Companion piece to the Q2 2026 State of Supply Chain report from VCRI.</description>
    <content:encoded><![CDATA[
      <p>Two independent 2026 findings — Seal Security on the commit side, GreyNoise on the exploit side — converge on the same number: 11 days from observable signal to CVE advisory. Both numbers come from Era 2 economics (human researchers, human exploit-development, human triage cycles).</p>
      <p>Era 3 does not compress the bureaucracy. The CVE advisory still arrives ~11 days after the fix-commit. What collapses is the attacker side: time-from-commit to working-exploit drops from days to hours, time-from-working-exploit to mass-exploitation-traffic drops from days to minutes. Seal's 11-day window does not get shorter; it gets more dangerous, because almost all of it is now attacker-active rather than attacker-developing.</p>
      <p>Read the full structural argument with the three Eras of zero-day economics and the four illustrative diagrams at <a href="https://valuechainrisk.org/blog/three-eras-of-0days.html">valuechainrisk.org/blog/three-eras-of-0days.html</a>.</p>
    ]]></content:encoded>
  </item>

</channel>
</rss>
