Skip to main content

Responsible AI resource

Build an AI dependency exception register before the next supply-chain scare

When a package controversy, CVE thread, release note, or agent-policy dispute lands in Slack, the team needs more than panic or shrugging. Use this register to decide which dependencies are allowed, blocked, temporarily excepted, owner-approved, or still under review.

Copy the dependency registerMap one exception lane

Exception register

Review gate
Row 1Watch
Row 2Allowed
Row 3Temporary exception
Row 4Blocked
Row 5Rollback

Register rows move from noisy source signals into a named owner, bounded status, review date, rollback path, and receipt before they affect production or agent access.

The link usually arrives before the meeting invite

Someone drops an issue tracker thread into Slack. The package name is familiar enough to make people stop scrolling. It might sit under backup jobs, deployment scripts, CI images, test tools, workflow agents, vendor appliances, or one old shell script nobody has touched since the last migration.

The thread is noisy. Maybe it is a CVE. Maybe it is a maintainer warning. Maybe it is a release note aimed at AI coding agents. Maybe it is a public argument about whether a project should accept AI-generated work.

Two reactions show up fast: pin everything, or ignore it as internet drama. Both skip the business decision: what are we allowed to do with this dependency while the evidence is incomplete?

An AI dependency exception register gives that decision a place to land. One row per dependency. One owner. One status. One review date. One rollback path. Enough evidence that the team can explain the call tomorrow.

What the register is

An AI dependency exception register is a lightweight decision record for dependencies that touch AI-assisted work, automation, production systems, sensitive data, or software delivery. It is not a permanent committee, a vulnerability database, or a replacement for SCA tooling, SBOM work, or normal security review.

It answers a narrower question: what may this dependency do in our environment while the decision is open? That question gets sharper when a coding agent may read package docs, release notes, test output, issue templates, pull-request comments, and terminal logs; or when a workflow agent calls a dependency through a package, CLI, API wrapper, or tool server.

The register keeps those decisions out of chat memory and connects them to the same BaristaLabs control stack: the workflow controls map, approval queue, agent receipt template, and data-security boundary.

When to open a row

Open a row when a dependency deserves attention outside normal update cadence. Do not open one for every package; the register works because it stays small enough to review.

  • A public issue, CVE, advisory, or maintainer statement names a package you rely on.
  • A release note adds an AI-agent usage clause, prompt-like instruction, licensing concern, or execution warning.
  • A dependency appears in an AI workflow, coding-agent sandbox, CI image, deployment script, data connector, or customer-facing automation path.
  • A reviewer asks whether an agent is allowed to run tests, install packages, read logs, or update code involving that dependency.

Use boring statuses

Clever labels make the register harder to use during a real scare. Use plain statuses that imply the next action.

Watch

A public signal exists, but the team has not found confirmed internal exposure yet.

Allowed

The dependency can continue under normal policy, with the evidence for that decision recorded.

Temporary exception

A bounded use is allowed for a named owner, environment, or review window.

Blocked

The dependency, version, package source, or agent interaction is not allowed until review changes the call.

Rollback

The team moved back to a prior version, alternate package, prior image, disabled agent path, or manual process.

Closed

The evidence no longer needs special handling, or the dependency is back under normal governance.

Copyable artifact

AI dependency exception register

Use this as a table, spreadsheet, issue template, YAML file, or lightweight internal page. The format matters less than the fields.

Dependency
What to write: Package, repo, API, model/tool connector, CLI, test library, base image, vendor SDK, or transitive dependency. Include where it enters your environment.
Business use
What to write: The workflow, system, customer process, build path, or operational job that depends on it.
AI/tool touchpoint
What to write: Where an agent, model, automation script, CI job, or workflow tool reads, runs, installs, updates, or reasons over the dependency.
Exposure
What to write: Production, staging, CI, laptop, vendor appliance, customer-hosted install, sandbox, data connector, backup job, deployment job, or support workflow.
Evidence/source link
What to write: CVE, advisory, issue thread, release note, maintainer statement, failed test, internal incident, SCA alert, or policy link.
Evidence class
What to write: 0 public concern; 1 plausible report without reproduction; 2 reproducible upstream issue or failing test; 3 confirmed exposure in your environment; 4 active incident or exploitable security impact.
Current status
What to write: Watch, allowed, temporary exception, blocked, rollback, or closed. Add scope when a status is partial.
Exception owner
What to write: Person or team allowed to collect evidence, approve the temporary path, and close or escalate the row.
Review deadline
What to write: Date when the status must be revisited. Use shorter windows for confirmed exposure.
Allowed actions
What to write: What humans, agents, and automation may do while the row is open.
Blocked actions
What to write: What humans, agents, and automation may not do until the review changes the decision.
Rollback path
What to write: Exact pin, prior image, manual process, feature flag, package replacement, or owner-approved change that reverses the risky path.
Receipt/log requirement
What to write: Approval note, PR link, dependency scan, image manifest, test run, reviewer note, source link, or incident record that proves the decision later.
Closure condition
What to write: What lets the row close: upstream fix, internal test pass, no affected version, replacement shipped, accepted risk, or blocked path removed.

Field notes for the row

Dependency

Do not stop at the package name. A dependency might enter through a Linux distribution package, container image, backup product, deployment script, test runner, vendor SDK, or customer-hosted appliance. The field should answer where this thing can enter your environment.

Evidence/source link

A screenshot is not a reproduction. A hot issue thread is not an advisory. A maintainer comment is not the same thing as an internal exposure report. Record the strongest evidence you have and say when the evidence is weak.

Allowed and blocked actions

Write these as instructions a tired reviewer can follow. For example: use the current pinned version in production; no automatic production upgrade until review; let the coding agent read test output but not modify imports involving this package.

Rollback path and receipt

Every exception needs a way back and a record that survives the Slack thread. Capture the pin, prior image, manual workflow, owner approval, test result, source link, PR, or reviewer note that lets the team reconstruct the decision later.

Filled example: public signal, not a verdict

This example treats the public rsync issue as a governance signal, not as proof that rsync is unsafe. The register decides what the team may do while it reviews the signal.

Dependency
Example: rsync, installed through base OS packages in backup worker images and deployment utility containers.
Business use
Example: File synchronization for backup workers, internal mirrors, and two legacy deployment scripts.
AI/tool touchpoint
Example: Coding agent may read deployment scripts and suggest changes; no agent currently modifies backup worker images.
Exposure
Example: Production backup workers, deployment utility containers, weekly CI image, and unmanaged developer laptops.
Evidence/source link
Example: Public upstream issue thread at github.com/RsyncProject/rsync/issues/929; no internal failing test yet.
Evidence class
Example: 1: plausible public concern and governance signal; missing internal reproduction.
Current status
Example: Watch; temporary hold on automatic updates for deployment utility images.
Exception owner
Example: Platform engineering.
Review deadline
Example: Next platform review, or sooner if upstream publishes a reproducible issue, release note, advisory, or distribution patch.
Allowed actions
Example: Use current distribution package in production images. Add smoke test for backup sync path. Monitor upstream and distribution updates.
Blocked actions
Example: No automatic production image upgrade during the watch window. No agent-authored dependency replacement.
Rollback path
Example: Rebuild backup worker image from prior base image if smoke test fails. Emergency pin can be approved for 14 days by platform owner.
Receipt/log requirement
Example: Image manifest, smoke-test result, owner note, source link, decision date, and next review date.
Closure condition
Example: No affected internal version found after review, or upstream/distribution fix lands and smoke test passes.

The row does not decide that rsync is unsafe. It decides what your team is allowed to do while the signal is being reviewed.

How it connects to AI workflow controls

Dependency decisions get sharper when agents enter the workflow. A human developer can read a strange package note and decide it is irrelevant, hostile, useful, or worth escalating. A coding agent may treat that same note as task context. A workflow agent may call the dependency through a tool. A code-review bot may summarize a dependency change without understanding why the package was blocked last week.

That is why the register should sit near the approval policy and receipt template, not off in a private spreadsheet. The approval policy says what the workflow may do. The approval queue shows the reviewer what is about to happen. The receipt records what happened after approval. The dependency exception register tells the team whether the underlying package, tool, SDK, connector, or version is allowed in that path at all.

How to run the first review

Start with one dependency. Pick the one that caused the latest conversation, or the one closest to customer data, deployment, backups, payments, production automation, or an AI agent's tool path.

  1. Where does this dependency enter our environment?
  2. What business work depends on it?
  3. What evidence do we have, and how strong is it?
  4. What may humans, agents, and automation do before the review closes?
  5. What receipt proves the decision later?

If the team cannot answer those questions, the next action is not a fork, a freeze, or a vendor migration. The next action is evidence collection.

Source signals to treat carefully

The public examples behind this guide are useful because they show how messy dependency decisions can become. Treat them as signals that call for bounded internal decisions, not as blanket verdicts on a package, maintainer, or project.

Map one exception lane

Review one dependency boundary with BaristaLabs

BaristaLabs helps teams turn one risky dependency, SDK, package, or agent tool path into a bounded decision: owner, evidence, allowed actions, blocked actions, review date, rollback path, and receipt.

Review one dependency boundary

Use this with