Lockfiles fuer AI Agents: Abhilfe gegen stille Abhaengigkeitsdrift
Ein AI Agent kann sich unerwartet anders verhalten, ohne dass Prompt oder Code geaendert wurden. Ursache sind verschobene Paketversionen, aktualisierte Tool-Beschreibungen von MCP-Servern oder neue Modell-Aliase. Dependency Lockfiles sollen solche stillen Aenderungen verhindern.
Ein Agent kann sich am Dienstag anders verhalten, obwohl niemand seinen Prompt oder den Anwendungscode geaendert hat. Ein Paket wird zu einer neueren Version aufgeloest, ein MCP-Server aktualisiert eine Tool-Beschreibung, ein Modell-Alias verschiebt sich oder ein Tool-Image wird neu gebaut. Der Workflow startet weiterhin. Die Tests sind moeglicherweise weiterhin gruen. Aber der Agent ist nicht mehr die Laufzeit, die du geprueft hast.
Deshalb ist eine normale package-lock.json notwendig, aber unzureichend fuer ein KI-Feature. Sie pinnt einen Teil der Anwendung, waehrend der Agent zusaetzlich von Modellen, Prompts, Tool-Servern, Policy-Buendeln, Retrieval-Konfigurationen und externen Paketen abhaengt. Behandle all diese Elemente als einen gemeinsamen Abhaengigkeitsgraph. Halte dann den aufgeloesten Graphen in einer AI-Agent-Dependency-Lockfile fest.
Das ist keine Behauptung, dass eine Lockfile einen Agenten sicher macht. Sie liefert dir eine konkrete, ueberpruefbare Antwort auf eine wesentlich nuetzlichere Frage: Mit was genau ist dieser Agent gelaufen? Diese Antwort macht schlechte Aenderungen leichter erkennbar, reproduzierbar und rueckgaengig machbar.
Beginne mit den Abhaengigkeiten, die Verhalten oder Berechtigungen aendern koennen, ohne den Geschaeftsworkflow zu veraendern. Eine nuetzliche Lockfile haelt sowohl den angeforderten Selektor als auch die aufgeloeste Identitaet fest.
Es geht nicht darum, jede Entscheidung fuer immer einzufrieren. Es geht darum, Absicht von Aufloesung zu trennen. latest kann weiterhin als Eingabe fuer einen Update-Job dienen, aber es sollte nicht die einzige Aufzeichnung dessen sein, was in der Produktion ausgefuehrt wurde.
Teams pruefen Quellcode-Aenderungen oft sorgfaeltig und akzeptieren eine Umgebungsvariable wie MODEL=fast-model oder TOOLS_URL=https://tools.internal als harmlose Verkabelung. In einem Agentensystem kann diese Verkabelung die Ausgabequalitaet, Tool-Verfuegbarkeit, Berechtigungen, Latenz oder Datenverarbeitung veraendern.
Dasselbe Problem tritt bei agenteninstallierten Abhaengigkeiten auf. Wenn ein Coding-Agent ein Paket hinzufuegt, weil er einen vertrauten Namen erkennt, kann der Pull Request hinter einem einzelnen Import einen neuen transitiven Abhaengigkeitsbaum verbergen. Wenn ein Agent einen Tool-Server ueber ein veraenderliches Tag abruft, kann ein Image-Rebuild die Laufzeit nach der Pruefung veraendern. Die aktuelle oeffentliche Leitlinie zu Agent-Supply-Chains nennt ausdruecklich Modelle, Agenten, Bibliotheken, Entwickler-Tools und MCP-Server-Pakete als Teil des Umfangs. Die Grenze ist weiter gezogen als requirements.txt.
Verwende ein Format, das deine Tools parsen und deine Pruefer lesen koennen. JSON ist fuer CI praktisch, obwohl auch YAML oder TOML funktionieren. Dieses Beispiel speichert bewusst keine Zugangsdaten und keine rohen Kundendaten.
{ "lockVersion": 1, "agent": { "name": "refund-assistant", "workflowCommit": "8e9b1f2", "policy": { "selector": "refund-policy", "resolvedDigest": "sha256:6b4d..." } }, "model": { "selector": "support-fast", "provider": "example-provider", "resolvedId": "support-fast-2026-10-18" }, "prompts": [{ "path": "prompts/refund.md", "gitCommit": "8e9b1f2", "sha256": "f18c..." }], "tools": [{ "name": "get_order", "serverImage": "registry.example/tools@sha256:a91d...", "serverVersion": "2.4.1", "schemaSha256": "ce33...", "scopes": [ "orders.read" ] }], "packages": { "agent-sdk": { "version": "4.2.3", "integrity": "sha512-..." } }, "retrieval": { "indexRevision": "kb-2026-10-23-04", "embeddingModel": "embed-small-r17", "chunkerDigest": "sha256:9d70..." } } Enter fullscreen mode Exit fullscreen mode Zwei Details sind hier wichtig. Erstens bewahrt der Selektor die menschenlesbare Absicht, waehrend die unveraenderliche ID oder der Digest festhaelt, was tatsaechlich aufgeloest wurde. Zweitens erfasst die Lockfile nur Referenzen und Hashes.
Eine Lockfile sollte niemals zu einem zweiten Secret-Speicher werden.
Erstelle einen einzelnen Befehl, der Eingaben aufloest, sie validiert und eine kanonische Lockfile schreibt. Ein minimales TypeScript-aehnliches Geruest sieht so aus:
type ResolvedTool = { name: string; serverImage: string; schemaSha256: string; scopes: string []; }; async function lockTool ( name: string ): Promise < ResolvedTool > { const server = await registry. resolveImmutableImage ( name ); const schema = await mcp. inspect ( server. digest ); if (! schema. tools. every ( tool => allowedTools. has ( tool. name ))) { throw new Error ( `Unexpected tool exposed by ${ name } ` ); } return { name, serverImage: server. digest, schemaSha256: sha256 ( stableJson ( schema )), scopes: minimalScopes ( schema ) }; } Enter fullscreen mode Exit fullscreen mode Kanonische Serialisierung ist wichtig. Wenn aequivalentes JSON unterschiedliche Bytes erzeugen kann, wird ein Hash-Diff zu Rauschen. Sortiere Schluessel, normalisiere Zeilenumbrueche und schreibe die generierte Datei deterministisch.
Committe sie neben der Workflow-Definition, genau wie du eine gewoehnliche Paket-Lockfile commitest.
Eine Lockfile hilft nur, wenn eine veraenderte Aufloesung Aufmerksamkeit erhaelt. Erzeuge in der CI eine Kandidaten-Lockfile, vergleiche sie mit der committeten Version und klassifiziere den Diff.
Vermeide ein einziges Kontrollkaestchen namens „Lockfile hat sich geaendert“. Ein neues Nur-Lese-Tool und ein Tool, das Rueckerstattungen ausloesen kann, sind nicht gleichwertig. Der Klassifizierer soll einen mechanischen Diff in einen passenden Pruefpfad uebersetzen.
agentctl lock --config agent.yaml --out agent.lock.next.json agentctl lock verify --file agent.lock.next.json agentctl lock diff agent.lock.json agent.lock.next.json --format json > diff.json agentctl lock policy-check diff.json agentctl test contracts --lock agent.lock.next.json agentctl eval run --suite refund-safety --lock agent.lock.next.json Enter fullscreen mode Exit fullscreen mode Der policy-check-Befehl sollte bei verbotenen Aenderungen fehlgeschlagen und damit dicht sein, etwa bei einem veraenderlichen Image-Tag, einer nicht genehmigten Registry, einem neu schreibfaehigen Tool oder einem fehlenden Integrity-Digest. Er sollte fuer erlaubte Aenderungen einen lesbaren Bericht erzeugen, nicht nur ein Pass/Fail-Bit.
Lass einen Produktionsprozess niemals stillschweigend neue Abhaengigkeiten beim Start aufloesen. Verwende stattdessen einen zweistufigen Weg:
Das ist absichtlich weniger magisch, als einer Laufzeit zu erlauben, „das neueste kompatible Tool“ zu holen. Das Ziel ist eine vorhersagbare Aenderung. Wenn schnelle Sicherheitspatches noetig sind, kann derselbe Weg mit einer expliziten Notfallfreigabe und einer kurzen nachtraeglichen Pruefpflicht beschleunigt werden.
Haenge agent_lock_digest an Traces, Entscheidungsprotokolle und Evaluationsergebnisse. Wenn ein Support-Team fragt, warum ein Agent begann, ein anderes Tool zu waehlen, kannst du Fehler nach dem exakten Abhaengigkeitssatz gruppieren, statt aus Deployment-Zeitstempeln zu raten.
Das verkleinert auch die Arbeit bei Vorfällen. Du kannst einen betroffenen Lauf in einer Sandbox mit dem Workflow-Commit plus Lockfile reproduzieren und ihn dann mit dem vorherigen Digest vergleichen. Ein Release-Manifest sagt dir die Identitaet des Bundles; die Dependency-Lock sagt dir, welche veraenderlichen Oekosystem-Referenzen zu konkreten Artefakten wurden.
Einen Namen sperren, nicht den Inhalt. tools: 2.4.1 ist besser als latest, aber eine Paketversion allein identifiziert moeglicherweise nicht das exakte Artefakt. Verwende wo moeglich einen Integrity-Wert, einen unveraenderlichen Image-Digest oder einen von der Registry bereitgestellten Content-Hash.
Tool-Schemas als Dokumentation behandeln. Ein Schema kann Pflichtfelder, Standardwerte, Beschreibungen oder Nebeneffekte veraendern, waehrend der Servername gleich bleibt. Erstelle einen Snapshot des geprueften Schemas und fuehre Contract-Tests dagegen aus.
Nur Abhaengigkeiten sperren. Ein Modell-Alias, eine Prompt-Datei, ein Retrieval-Index und ein Policy-Buendel koennen jeweils das Verhalten eines Agenten veraendern. Nimm die Komponenten auf, die fuer dein Bedrohungsmodell und deinen Debugging-Pfad relevant sind.
Updates unmoeglich machen. Eine Lockfile, die niemand aktualisiert, wird zur veralteten Theaterinszenierung. Fahre einen geplanten Job zur Kandidatenaufloesung, sende begrenzte Diffs an die Verantwortlichen und halte eine getestete Schnellspur fuer Sicherheitspatches bereit.
Zufaellig Secrets loggen. Speichere die erlaubten Scopes und die Identitaet eines Tools, nicht ein Access-Token, einen Endpoint-Query-String oder eine Kunden-Payload. Scanne generierte Lockfiles vor dem Commit.
Beginne mit einem Agenten, der meaningful externe Wirkungen hat. Inventarisiere sein Modell, seine Prompts, Tool-Server, Pakete, Policies und die Retrieval-Konfiguration. Fuege fuer die zwei oder drei Komponenten, die am ehesten abdriften, unveraenderliche IDs hinzu. Mache dann eine einzige CI-Regel sichtbar: Jedes neu schreibfaehige Tool erfordert eine menschliche Freigabe.
Danach ergaenze Schema-Snapshots und Trace-Korrelation. Erst wenn diese Bausteine funktionieren, solltest du die Sperre auf alle Laufzeit-Abhaengigkeiten ausweiten. Das Artefakt soll Mehrdeutigkeit fuer Ingenieure reduzieren, nicht eine riesige Metadatendatei schaffen, die niemand mehr pruefen kann.
Eine Lockfile beantwortet die Frage: „Was hat dieses Release aufgeloest?“ Ein Inventar beantwortet die Frage: „Welche Agenten-Komponenten existieren organisationweit?“ Behalte beides. Das Inventar ist nuetzlich fuer Verantwortlichkeiten, Patch-Benachrichtigungen und das Auffinden eines nicht mehr gepflegten Tool-Servers; die Lockfile ist nuetzlich fuer die exakte Laufzeit-Reproduktion. Die Vermischung beider erzeugt ein Dokument, das fuer ein Deployment zu breit und fuer den Sicherheitsbetrieb zu veraltet ist.
Denk dir die Lockfile als Snapshot auf Release-Ebene und das Inventar als Karte auf Portfolio-Ebene. Ein Tool kann im Inventar mit einem Verantwortlichen, einer Risikoklassifizierung und einer genehmigten Registry erscheinen. Jede Agenten-Lockfile nennt dann das unveraenderliche Tool-Artefakt, den Schema-Digest und die Scopes, die sie tatsaechlich verwendet hat. Diese Unterscheidung gibt einem Security-Pruefer eine kurze Antwort waehrend eines Release-Reviews und gibt einem Ops-Team eine umfassendere Antwort, wenn eine Schwachstellen-Meldung eingeht.
Wenn eine Abhängigkeitswarnung auftaucht, sollte zunächst das Inventar abgefragt werden, um potenzielle Besitzer und Workloads zu identifizieren. Anschließend fragt man die Deployment-Aufzeichnungen nach Lockfile-Digests ab, die auf das betroffene Artefakt verweisen. So bleibt die Reaktionsarbeit evidenzbasiert: Es ist nicht nötig, jeden Agenten neu zu starten, nur weil ein ähnlich benanntes Paket irgendwo in einem Repository existiert.
Reviewer sollten aus dem Pull Request vier Fragen beantworten können: Was hat sich geändert? Welche Fähigkeit oder welches Verhalten könnte sich ändern? Welche Tests haben die neue Auflösung geprüft? Wie kehren wir zum vorherigen als funktionierend bekannten Digest zurück? Diese Antworten sollten in die generierte Diff-Zusammenfassung aufgenommen werden.
Zum Beispiel benötigt ein Tool-Image-Update mit unverändertem Schema Integrationstests und einen Schwachstellen-Scan. Ein Schema-Diff, der issue_refund hinzufügt, erfordert eine Freigabe durch den Capability-Owner, selbst wenn das Image keine bekannten CVEs aufweist. Eine neue Modell-Revision braucht eine Evaluierung mit repräsentativen Aufgaben, weil ihre Schnittstelle stabil sein kann, während sich ihre Entscheidungen verschieben. Das Lockfile macht diese verschiedenen Arten von Änderungen an einem Ort sichtbar, ohne so zu tun, als trügen sie dasselbe Risiko.
Ja. Ein Paket-Lockfile löst Sprachabhängigkeiten auf. Ein Agent-Lockfile erweitert dieselbe Idee auf verhaltensrelevante Abhängigkeiten wie Modelle, Prompts, MCP-Tools, Policies und Retrieval-Revisionen.
Für Produktions-Workflows, bei denen Reproduzierbarkeit wichtig ist, sollte die aufgelöste Deployment- oder Revisions-Identität festgehalten werden, wenn der Provider eine bereitstellt. Falls nur ein Alias existiert, sollten der Alias, die zum Zeitpunkt der Auflösung verfügbaren Provider-Metadaten und die für den Rollout verwendeten Evaluierungsnachweise dokumentiert werden.
Pinne den unveränderlichen Integrity-Wert des Images oder Pakets, erfasse den geprüften Tool-Schema-Digest, teste die Tool-Verträge und verlange eine Freigabe, sobald die exponierten Tools oder Scopes erweitert werden.
Nein. Es hilft dabei zu wissen und zu reproduzieren, was ausgewählt wurde. Kombiniere es mit vertrauenswürdigen Registries, Integritätsprüfung, Schwachstellen-Scanning, Least-Privilege-Credentials, Code Review und Laufzeitkontrollen.
Erzeuge einen Kandidaten in einem vorhersehbaren Rhythmus und immer dann, wenn sich deklarierte Abhängigkeiten ändern. Wende Updates erst nach den entsprechenden Prüfungen an; Dringlichkeit kann die Geschwindigkeit der Freigabe ändern, nicht aber den Umfang der aufzubewahrenden Nachweise.
Vergleiche die neuen und die vorherigen aufgelösten Identitäten, ordne Fehler dem Lockfile-Digest zu, fahre bei Bedarf das letzte als funktionierend bekannte Lockfile aus und bewahre dann das Diff und die Testergebnisse für die weitere Analyse auf.
Starte klein: Pinne Paket- und Tool-Identitäten, commite eine generierte Datei und prüfe Capability-Änderungen. Diese Gewohnheit lässt sich besser skalieren, als später eine veränderte Agent-Runtime aus verstreuten Umgebungsvariablen rekonstruieren zu müssen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
An agent can behave differently on Tuesday even when nobody changed its prompt or application code. A package resolves to a newer release, an MCP server updates a tool description, a model alias moves, or a tool image is rebuilt. The workflow still starts. The tests may still be green. But the agent is no longer the runtime you reviewed.
That is why a normal package-lock.json is necessary but incomplete for an AI feature. It pins part of the application, while the agent also depends on models, prompts, tool servers, policy bundles, retrieval configurations, and external packages. Treat those as one dependency graph. Then record the resolved graph in an AI agent dependency lockfile.
This is not a claim that a lockfile makes an agent safe. It gives you a specific, reviewable answer to a much more useful question: what exactly did this agent run with? That answer makes bad changes easier to spot, reproduce, and roll back.
Start with dependencies that can change behavior or permissions without changing the business workflow. A useful lockfile records both the requested selector and the resolved identity.
The point is not to freeze every choice forever. The point is to separate intent from resolution. latest can remain an input to an update job, but it should not be the only record of what production executed.
Teams often review source changes carefully and accept an environment variable such as MODEL=fast-model or TOOLS_URL=https://tools.internal as harmless wiring. In an agent system, that wiring can change output quality, tool availability, permissions, latency, or data handling.
The same issue appears with agent-installed dependencies. If a coding agent adds a package because it recognizes a familiar name, the pull request can hide a new transitive tree behind one import. If an agent fetches a tool server by a mutable tag, an image rebuild can change the runtime after review. Current public guidance on agent supply chains explicitly includes models, agents, libraries, developer tools, and MCP-server packages in scope. The boundary is wider than requirements.txt.
Use a format your tools can parse and your reviewers can read. JSON is convenient for CI, though YAML or TOML works too. This example deliberately avoids storing credentials and raw customer data.
{ "lockVersion": 1, "agent": { "name": "refund-assistant", "workflowCommit": "8e9b1f2", "policy": { "selector": "refund-policy", "resolvedDigest": "sha256:6b4d..." } }, "model": { "selector": "support-fast", "provider": "example-provider", "resolvedId": "support-fast-2026-10-18" }, "prompts": [{ "path": "prompts/refund.md", "gitCommit": "8e9b1f2", "sha256": "f18c..." }], "tools": [{ "name": "get_order", "serverImage": "registry.example/tools@sha256:a91d...", "serverVersion": "2.4.1", "schemaSha256": "ce33...", "scopes": [ "orders.read" ] }], "packages": { "agent-sdk": { "version": "4.2.3", "integrity": "sha512-..." } }, "retrieval": { "indexRevision": "kb-2026-10-23-04", "embeddingModel": "embed-small-r17", "chunkerDigest": "sha256:9d70..." } } Enter fullscreen mode Exit fullscreen mode Two details matter here. First, the selector preserves the human-facing intent, while the immutable ID or digest preserves what actually resolved. Second, the lockfile captures only references and hashes.
A lockfile should never become a second secret store.
Create one command that resolves inputs, validates them, and writes a canonical lockfile. A minimal TypeScript-style sketch looks like this:
type ResolvedTool = { name: string; serverImage: string; schemaSha256: string; scopes: string []; }; async function lockTool ( name: string ): Promise < ResolvedTool > { const server = await registry. resolveImmutableImage ( name ); const schema = await mcp. inspect ( server. digest ); if (! schema. tools. every ( tool => allowedTools. has ( tool. name ))) { throw new Error ( `Unexpected tool exposed by ${ name } ` ); } return { name, serverImage: server. digest, schemaSha256: sha256 ( stableJson ( schema )), scopes: minimalScopes ( schema ) }; } Enter fullscreen mode Exit fullscreen mode Canonical serialization is important. If equivalent JSON can produce different bytes, a hash diff becomes noise. Sort keys, normalize line endings, and write the generated file deterministically.
Commit it next to the workflow definition just as you commit an ordinary package lockfile.
A lockfile only helps if a changed resolution gets attention. In CI, generate a candidate lockfile, compare it with the committed version, and classify the diff.
Avoid a single “lockfile changed” checkbox. A new read-only tool and a tool that can issue refunds are not equivalent. The classifier should turn a mechanical diff into an appropriate review path.
agentctl lock --config agent.yaml --out agent.lock.next.json agentctl lock verify --file agent.lock.next.json agentctl lock diff agent.lock.json agent.lock.next.json --format json > diff.json agentctl lock policy-check diff.json agentctl test contracts --lock agent.lock.next.json agentctl eval run --suite refund-safety --lock agent.lock.next.json Enter fullscreen mode Exit fullscreen mode The policy-check command should fail closed for prohibited changes, such as a mutable image tag, an unapproved registry, a newly write-capable tool, or a missing integrity digest. It should produce a readable report for permitted changes, not merely a pass/fail bit.
Do not let a production process silently resolve new dependencies at startup. Instead, use a two-step path:
This is deliberately less magical than allowing a runtime to “get the newest compatible tool.” Predictable change is the goal. If fast security patches are needed, the same path can be accelerated with an explicit emergency approval and a short retrospective requirement.
Attach agent_lock_digest to traces, decision records, and evaluation results. When a support team asks why an agent started choosing a different tool, you can group failures by the exact dependency set instead of guessing from deploy timestamps.
That also makes incident work smaller. You can reproduce an affected run in a sandbox using the workflow commit plus lockfile, then compare it with the previous digest. A release manifest tells you the bundle identity; the dependency lock tells you which mutable ecosystem references became concrete artifacts.
Locking a name, not content. tools: 2.4.1 is better than latest, but a package version alone may not identify the exact artifact. Use an integrity value, immutable image digest, or registry-provided content hash where possible.
Treating tool schemas as documentation. A schema can alter required fields, defaults, descriptions, or side effects while the server name stays the same. Snapshot the inspected schema and run contract tests against it.
Locking only dependencies. A model alias, prompt file, retrieval index, and policy bundle can each change an agent’s behavior. Include the components that matter to your threat model and debugging path.
Making updates impossible. A lockfile that nobody refreshes becomes stale theater. Run a scheduled candidate-resolution job, send bounded diffs to owners, and maintain a tested fast lane for security patches.
Logging secrets by accident. Store a tool’s allowed scope and identity, not an access token, endpoint query string, or customer payload. Scan generated lockfiles before commit.
Begin with one agent that has meaningful external effects. Inventory its model, prompt, tool servers, packages, policy, and retrieval configuration. Add immutable IDs for the two or three components most likely to drift. Then make one CI rule visible: any newly write-capable tool requires a human approval.
After that, add schema snapshots and trace correlation. Only when those pieces work should you expand the lock to every runtime dependency. The artifact should reduce ambiguity for engineers, not create a giant metadata file nobody can review.
A lockfile answers “what did this release resolve?” An inventory answers “what agent components exist across the organization?” Keep both. The inventory is useful for ownership, patch notifications, and discovering an unmaintained tool server; the lockfile is useful for exact runtime reproduction. Mixing the two creates a document that is too broad for a deploy and too stale for security operations.
Think of the lockfile as a release-level snapshot and the inventory as a portfolio-level map. A tool may appear in the inventory with an owner, risk classification, and approved registry. Each agent lockfile then states the immutable tool artifact, schema digest, and scopes it actually used. This distinction gives a security reviewer a short answer during a release review and gives an operations team a larger answer when a vulnerability advisory arrives.
When a dependency advisory appears, first query the inventory to identify candidate owners and workloads. Next, query deployment records for lockfile digests that reference the affected artifact. That keeps response work evidence-based: do not restart every agent merely because a similarly named package exists somewhere in a repository.
Reviewers should be able to answer four questions from the pull request: What changed? Which capability or behavior could change? What tests exercised the new resolution? How do we return to the previous known-good digest? Include those answers in the generated diff summary.
For example, a tool image update with an unchanged schema may need integration tests and a vulnerability scan. A schema diff adding issue_refund requires a capability-owner approval even if the image has no known CVEs. A new model revision needs representative task evaluation, because its interface can be stable while its decisions move. The lockfile makes these different kinds of changes visible in one place without pretending they carry the same risk.
Yes. A package lockfile resolves language dependencies. An agent lockfile extends the same idea to behavior-relevant dependencies such as models, prompts, MCP tools, policies, and retrieval revisions.
For production workflows where repeatability matters, record the resolved deployment or revision identity when your provider exposes one. If only an alias exists, record the alias, provider metadata available at resolution time, and the evaluation evidence used for the rollout.
Pin its immutable image or package integrity value, capture the inspected tool-schema digest, test its tool contracts, and require approval when the exposed tools or scopes expand.
No. It helps you know and reproduce what was selected. Combine it with trusted registries, integrity verification, vulnerability scanning, least-privilege credentials, code review, and runtime controls.
Generate a candidate on a predictable cadence and when declared dependencies change. Apply updates only after the appropriate checks; urgency can change the approval speed, not the evidence you retain.
Compare the new and previous resolved identities, correlate failures with the lockfile digest, deploy the last known-good lockfile if justified, then preserve the diff and test results for follow-up.
Start small: pin package and tool identities, commit one generated file, and review capability changes. The same habit scales better than reconstructing a changed agent runtime from scattered environment variables later.