A safe prompt cannot repair an unsafe agent dependency

An AI agent depends on more than its model. Libraries turn messages into objects, connect tools and handle credentials. A defect there can create an exposure even when the model follows its instructions. Microsoft’s 30 January account uses LangGrinch, a vulnerability in LangChain Core, to illustrate this less visible part of the software supply chain.

Microsoft describes an injection issue in the package’s serialisation and deserialisation process. In affected conditions, improperly handled internal metadata could expose secrets or instantiate unexpected classes. The case concerns a software component, not merely a chatbot producing an undesirable answer. A team assessing exposure therefore needs to identify the actual installed dependency and where it runs. Comparing model safety scores would not answer that question.

A separate 23 January Microsoft report addresses runtime behaviour. It describes scenarios where an influenced agent performs unwanted actions through permissions it already has. In that situation, the underlying access request may look legitimate to an ordinary access-control check. The missing decision concerns whether that particular action fits the authorised task. Microsoft’s examples use checks around tool invocation in Copilot Studio.

The practical distinction is between maintaining the software that runs an agent and supervising what the deployed agent does. Dependency inventories and vulnerability remediation address the first layer. Narrow tool permissions, action checks and observable execution address the second. Neither can substitute for the other. An agent may run patched software and still be allowed to do too much, or have carefully limited tools while depending on an unsafe library. These reports describe Microsoft’s analysis and product examples. They are not a claim that every agent deployment is affected by the same flaw or that installing one vendor product guarantees protection.