In this tabletop, an AI coding agent adds a dependency whose name is a near match for the one it meant to install, and nobody notices for a day. The exercise tests who reviews agent changes, what the agent's environment could reach, and how fast you can find and remove the package.
Why this scenario is worth rehearsing
Coding assistants and agents now run package manager commands as part of normal work. A person typing a name can pause and check. An agent working through a task may not. The concern is not that agents are uniquely careless. It is that dependency changes can happen faster, in bigger batches, and with less human attention per change.
The exercise is also a safe way to ask questions your team may not have answered: what access does the agent's session have, and who reads the lockfile diff?
Setup
Invent a fictional package, such as requestz-http, a near match for a well known name. Decide on a fictional agent setup. Write down the real answers to these facts before the session:
- Does the agent run on developer laptops, in CI, or in a hosted sandbox?
- Which tokens and environment variables are visible to its shell?
- Can it install from the public registry directly, or through an approved mirror?
- Does every agent pull request get human review, and does that review include lockfile changes?
The injects
| Time | Inject | Question |
|---|---|---|
| 0 min | A reviewer notices an unfamiliar package name in a merged pull request from an agent session | Who decides whether this is an incident? |
| 15 min | The package page shows a recent first publish and no linked source repository | How do you decide it is suspicious, and who checks? |
| 25 min | The merge reached a branch that auto deploys to staging | Has anything run? How do you know? |
| 40 min | The agent session had a token with write access to a package registry | Which credentials do you rotate and in what order? |
| 50 min | A teammate asks whether other agent sessions added similar packages | How do you search across repositories and sessions? |
Questions that separate strong answers from weak ones
- Can you list every dependency added by agent sessions in the last 30 days?
- Does your pipeline block a first time dependency until someone approves it?
- Would the agent have been able to install if the mirror held an allowlist?
- Are agent tokens narrower than developer tokens, and do they expire?
- Does the review checklist say anything about new packages?
What good looks like
The team removes the package, rebuilds from a clean lockfile, and checks for any execution in staging and CI. They treat any credential visible to the session as exposed until shown otherwise. The follow-up list includes approval for new dependencies, narrower agent permissions, and a way to tag changes that came from an agent so they can be searched later.
Keep records factual and blameless. The failure is a missing control, not a person who trusted a tool.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how checks sit alongside an assistant session.
Related reading
Pair this with the agent incident tabletop scenarios and the one hour shadow dependency sweep.
Quick check
Is this scenario just for teams that use agents heavily?
No. Even light use means a dependency can enter without close review. The questions about tokens and approvals apply to any team.
What control closes the most risk quickly?
Routing installs through an approved mirror or allowlist, plus review of lockfile changes. Both are cheap to test in the exercise.
Safeguard can help with the inventory side of this work. SBOM and dependency scanning show where a package and version appear across your projects, and policies and gates can stop a flagged version at the pull request. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
