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 | What to write |
|---|---|
| Dependency | Package, repo, API, model/tool connector, CLI, test library, base image, vendor SDK, or transitive dependency. Include where it enters your environment. |
| Business use | The workflow, system, customer process, build path, or operational job that depends on it. |
| AI/tool touchpoint | Where an agent, model, automation script, CI job, or workflow tool reads, runs, installs, updates, or reasons over the dependency. |
| Exposure | Production, staging, CI, laptop, vendor appliance, customer-hosted install, sandbox, data connector, backup job, deployment job, or support workflow. |
| Evidence/source link | CVE, advisory, issue thread, release note, maintainer statement, failed test, internal incident, SCA alert, or policy link. |
| Evidence class | 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 | Watch, allowed, temporary exception, blocked, rollback, or closed. Add scope when a status is partial. |
| Exception owner | Person or team allowed to collect evidence, approve the temporary path, and close or escalate the row. |
| Review deadline | Date when the status must be revisited. Use shorter windows for confirmed exposure. |
| Allowed actions | What humans, agents, and automation may do while the row is open. |
| Blocked actions | What humans, agents, and automation may not do until the review changes the decision. |
| Rollback path | Exact pin, prior image, manual process, feature flag, package replacement, or owner-approved change that reverses the risky path. |
| Receipt/log requirement | 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 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.
| Field | Example |
|---|---|
| Dependency | rsync, installed through base OS packages in backup worker images and deployment utility containers. |
| Business use | File synchronization for backup workers, internal mirrors, and two legacy deployment scripts. |
| AI/tool touchpoint | Coding agent may read deployment scripts and suggest changes; no agent currently modifies backup worker images. |
| Exposure | Production backup workers, deployment utility containers, weekly CI image, and unmanaged developer laptops. |
| Evidence/source link | Public upstream issue thread at github.com/RsyncProject/rsync/issues/929; no internal failing test yet. |
| Evidence class | 1: plausible public concern and governance signal; missing internal reproduction. |
| Current status | Watch; temporary hold on automatic updates for deployment utility images. |
| Exception owner | Platform engineering. |
| Review deadline | Next platform review, or sooner if upstream publishes a reproducible issue, release note, advisory, or distribution patch. |
| Allowed actions | Use current distribution package in production images. Add smoke test for backup sync path. Monitor upstream and distribution updates. |
| Blocked actions | No automatic production image upgrade during the watch window. No agent-authored dependency replacement. |
| Rollback path | 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 | Image manifest, smoke-test result, owner note, source link, decision date, and next review date. |
| Closure condition | 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.
- Where does this dependency enter our environment?
- What business work depends on it?
- What evidence do we have, and how strong is it?
- What may humans, agents, and automation do before the review closes?
- 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.
- The rsync issue titled “Please Do Not Vibe Fuck Up This Software” is a public upstream thread. It is not, by itself, an internal exposure report.
- jqwik 1.10.1 was published as the “Anti-AI Release”, and its user guide says the project is not meant to be used by AI coding agents.
- The NIST AI Risk Management Framework is useful light framing for govern, map, measure, and manage; the register is the practical row where one decision gets recorded.
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