Treat every external dependency, context source, and tool as part of the agent’s trust boundary. If an agent can read from issue trackers, support systems, or remote includes, those systems can steer execution. Governance should therefore cover what the agent can read, what it can call, and what it can do without approval.
How to govern what an agent can read, call, and change
Agentic dependencies are not just implementation detail. They define the agent’s effective trust boundary. If an agent can consume tickets, documents, prompts, remote includes, or SaaS data, those sources can influence execution just as surely as code can. Governance has to treat each dependency as a potential control point, not a passive input.
The practical question is not only whether the agent is allowed to act, but whether the surrounding systems are allowed to shape that action. That is why teams should classify every dependency by sensitivity, provenance, and whether it can introduce instructions, credentials, or operational changes into the agent’s decision path.
In CI/CD, that means governing source repositories, build steps, package registries, secrets stores, and automation credentials as part of one chain of authority. AI Coding Agents Security Guide is a useful companion for the build and pipeline side of this problem, because it treats secrets, over-scoped tokens, and sandboxing as first-class concerns.
Why context sources create governance risk
External context sources can become hidden control inputs when teams assume they are “just data”. A support queue, issue tracker, or remote document can steer an agent toward unsafe tool use, data exposure, or an unintended change request if the agent is allowed to trust that content without mediation. The larger the integration surface, the easier it is for stale, poisoned, or low-integrity content to influence automated action.
CI/CD adds a second risk layer because delivery systems already have reach. A dependency that can alter build behavior, inject configuration, or influence release logic is not merely informative, it is operational. Governance should therefore distinguish read-only context from actionable context, and actionable context from authority to change code, secrets, or deployment state.
For teams that want a broader agent-security lens, Agentic AI Security Guide helps connect inputs, tools, identity, and orchestration into one threat model. MCP Security Guide is also relevant where external context or tools are brokered through protocol-based connectors, because it focuses on authorisation, token handling, and tool poisoning risks.
What good governance looks like in practice
Good governance starts with inventory, but it must end with control design. Teams should maintain an explicit register of agent-readable sources, tool-call targets, and approval-gated actions, then assign an owner for each one. The source owner should be able to answer why the dependency exists, what it may influence, and what review is required before the agent can use it in production.
Policy should be path-specific, not just identity-specific. A single agent may be allowed to read an internal wiki, query a ticketing system, and propose a patch, while being blocked from merging, deploying, or retrieving secrets. That difference matters because agent governance is about bounding effect, not only authenticating the actor. AI Agent Authorisation Guide is a strong fit here because it centres task-scoped access, per-action policy decisions, and approval gates.
Teams should also define what requires human review when context quality is uncertain. A remote include, third-party knowledge source, or low-trust SaaS integration should trigger stricter review than a curated internal source with clear provenance and logging. The governance model should be able to say, in advance, which dependencies are trusted for retrieval, which are trusted for execution, and which are not trusted at all.
Risk and Threat Considerations
When agents can read from many systems and act on what they see, the main risk is trust expansion without corresponding control expansion. Poisoned context, compromised upstream systems, and over-broad tool access can cause an agent to make a harmful action look like a routine workflow step.
Failure mechanism: A low-integrity dependency supplies misleading instructions, altered data, or hidden operational cues, and the agent treats that input as authoritative enough to call tools, alter artifacts, or move work forward without sufficient review.
Impact: The result can be incorrect code, unauthorized changes, secret exposure, release corruption, or a wider blast radius than the original dependency should ever have been allowed to influence.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent trust boundaries and approval-gated actions hinge on identity and privilege separation. |
| ASI02 — Tool Misuse | External context sources and tools can steer unsafe agent execution. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | CI/CD and external context sources create supply-chain style dependency risk for agents. | |
| Recommendation — Enforce per-action authorization and approval gates for agent actions. Restrict tool use to approved, task-scoped actions and inputs. Validate provenance and integrity for agent inputs, dependencies, and pipelines. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agents and their dependencies must not retain broad standing authority. |
| NHI-02 — Secret Leakage | CI/CD and context sources often expose secrets to agents if not controlled. | |
| Recommendation — Remove standing privilege and scope agent access to each task. Keep secrets out of agent context and rotate any exposed credentials. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Governance requires limiting what the agent can read, call, and change. |
| AU-2 — Event Logging | Dependency governance needs traceability over reads, tool calls, and changes. | |
| SA-11 — Developer Testing and Evaluation | CI/CD agent paths should be tested for unsafe dependency behavior before release. | |
| Recommendation — Limit agent permissions to the minimum needed for each workflow. Log agent reads, tool calls, and privileged actions for review. Test agent-driven workflows for unsafe dependency and approval bypass paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Agent governance depends on controlling accounts, access paths, and lifecycle. |
| Recommendation — Review and disable unnecessary agent-linked accounts and access paths. | ||
| SLSA | Supply-chain Levels for Software Artifacts | CI/CD dependencies need provenance and integrity controls to resist tampering. |
| Recommendation — Apply provenance checks to builds, dependencies, and release artifacts. | ||
Practitioner Guidance
What to prioritise: Separate read access, call access, and commit or deploy authority into distinct approval paths. If a source can affect execution, treat it as part of the control plane and review it with the same seriousness as a privileged integration.
What to verify: Check that each dependency has an owner, a trust level, and a documented failure mode. If the team cannot state what the agent is allowed to do after consuming that source, the governance model is incomplete.
Common mistake: Teams often secure the agent identity but leave context sources, webhooks, and build inputs unclassified. Practitioner takeaway: the safest design is not “trusted agent plus trusted inputs”, it is bounded input, bounded action, and explicit approval for anything that can materially change software or state.
Related resources from NHI Mgmt Group
- How should security teams govern open source dependencies in CI/CD pipelines?
- How should security teams govern MCP tools that can inspect repositories and CI/CD pipelines inline with agentic coding workflows?
- How should teams govern agentic CI systems that retain workflow context?
- How should security teams govern non-human identities at scale?