A clear sign is that package approvals happen repeatedly during active work, with little meaningful scrutiny of what was requested. Another signal is that developers treat prompts as friction rather than a security decision, especially when packages are installed mid-session. If installs are happening faster than review can realistically occur, the process is operating as a rubber stamp.
How to tell review has become a rubber stamp
The clearest signal is not a single bad approval, but a pattern: dependency installs keep getting approved during active work with little evidence that the request was actually examined. When installs are treated as an interruption rather than a control decision, review quality drops below the pace of execution and the process starts to certify whatever the agent wants next.
A second sign is that the request itself is too vague to support scrutiny. If the agent is installing packages without a clear reason, version pinning, provenance, or a human-readable justification, reviewers have nothing meaningful to validate. At that point the process is checking for motion, not risk.
For agentic workflows, this often shows up as repeated prompts that developers dismiss instinctively because they are trying to keep momentum. That behaviour matters because dependency installs are not just convenience actions, they are a trust boundary. Once the review step is habitually bypassed, the environment can accumulate unvetted code paths faster than teams can track them, similar to the kinds of supply-chain exposure described in LiteLLM PyPI package breach and Reviewdog GitHub Action supply chain attack.
When effective review is missing, the practical symptom is usually inconsistency: the same type of install is approved in one session and waved through in another without any visible difference in risk. That inconsistency suggests the review has stopped depending on package impact and has started depending on user fatigue, time pressure, or familiarity with the workflow.
What weak review looks like in the workflow
Fast approvals are not automatically wrong, but they become suspicious when they cluster around active coding sessions and never result in follow-up questions. If approvals happen before anyone can reasonably inspect the package name, source, transitive dependencies, or intended use, the review is functionally post hoc.
Another common pattern is that the install request arrives after the agent has already moved into execution. At that point the approval is merely legitimising a decision that has effectively already been made. The risk is higher when the install unlocks code execution, new network access, or a package with broad permissions, because the review is then happening after the blast radius has expanded.
Teams should also watch for review language that becomes formulaic. Short acknowledgements, repeated one-line approvals, and no discussion of why a dependency is needed are all signs that the control is drifting from verification into ceremony. That is especially dangerous in the same way over-trusting AI-assisted tooling can produce hidden dependency risk, as seen in Gemini CLI Breach, Silent Code Execution and Amazon Q AI Coding Agent Compromised.
One useful benchmark is whether the reviewer can still explain why the package belongs in this build and why this version is acceptable. If they cannot, the approval is no longer evidence of scrutiny. It is only evidence that the workflow moved faster than judgment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Tool Misuse and Excessive Privilege | Repeated agent-driven installs can expand capability without real scrutiny. |
| A5 — Supply Chain and Dependency Risk | Dependency installs are the exact supply-chain step where weak review creates exposure. | |
| Recommendation — Require explicit approval checks before agent actions that add new runtime or build-time capabilities. Verify package provenance, version integrity, and necessity before approving dependency additions. | ||
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Dependency installs change software composition and should be governed as configuration drift. |
| Recommendation — Control software changes by enforcing approved sources and tracked dependency baselines. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Unreviewed dependencies are a classic supply-chain compromise path into builds and agents. |
| Recommendation — Hunt for unexpected dependency introductions and validate package provenance before release. | ||
Practitioner Guidance
What to verify: Reviewers should be able to confirm the package source, exact version, and stated purpose before approval. If the request arrives with no provenance, no version pin, or no explanation of why the dependency is needed now, treat that as an exception condition rather than a routine install.
Decision rule: If the agent is asking for installs repeatedly during one working session, require a stronger review threshold for each request, because repetition is a sign that the control is being used as a throughput gate instead of a security gate. If the same package family keeps appearing, assess whether a pre-approved allowlist or locked dependency set would reduce unnecessary churn.
What practitioners underestimate: The biggest failure mode is not a visibly malicious package, but approval fatigue. Once teams get used to approving installs reflexively, they stop noticing when the agent is turning the review step into a formality. That is when dependency trust expands silently.
Practitioner takeaway: The control is working only when approval changes the outcome, not when it merely records that the outcome already happened.
Related resources from NHI Mgmt Group
- Who is accountable when an AI agent or automation system installs a malicious dependency?
- What are the signs that an AI security agent is failing governance review?
- What is the difference between human access review and AI agent access review?
- What should identity teams review when an AI agent is allowed to delegate?
