Who is accountable when an AI agent in CI/CD exposes secrets or pushes unauthorized code?

Accountability sits with the organisation operating the pipeline, because the agent is acting inside delegated authority. The practical question is which team owns trigger design, secret scoping, runtime detection, and incident response. Governance frameworks for access control and zero trust both expect a clear control owner, and agentic workflows do not remove that responsibility.

Why This Matters for Security Teams

An AI agent embedded in CI/CD is not a passive tool. It can read repositories, invoke build actions, fetch secrets, and push code under delegated authority, which makes accountability a control design problem, not a philosophical one. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point to the same operational truth: if an agent can act, the organisation must define who owns its permissions, monitoring, and rollback path.

This matters because CI/CD failures often look like normal automation until secrets are exposed or an unauthorized commit lands in a protected branch. NHIMG research on CI/CD pipeline exploitation case study shows how quickly delegated pipeline access can be turned into broad compromise when controls are too coarse. The risk is not only theft of secrets, but also loss of change integrity, provenance, and trust in release artifacts. In practice, many security teams encounter this only after a leaked token or rogue deployment has already moved through the pipeline.

How It Works in Practice

Accountability should be assigned at the same level as other privileged automation: one named control owner for the agent’s trigger logic, one for secret scoping, one for detection, and one for incident response. The agent itself is not the accountable entity. The organisation that designed and approved the agent’s operating envelope is. That is why zero trust and workload identity matter here: the agent should authenticate as a workload with narrowly scoped, short-lived credentials, not as a shared service account with persistent standing access.

In practical terms, teams should separate identity, authorization, and execution:

• Use workload identity for the agent so every action is tied to a verifiable runtime identity rather than a reusable password or token.
• Issue just-in-time secrets for the smallest task window possible, then revoke them automatically after use.
• Evaluate permission at request time with policy-as-code, rather than assuming a static role remains safe for all future actions.
• Log each secret access, code push, and build mutation with enough context to reconstruct intent and blast radius.

That approach aligns with the direction described in CSA MAESTRO agentic AI threat modeling framework and the Guide to the Secret Sprawl Challenge, which both reinforce that secrets governance fails when ownership is fragmented across platform, application, and security teams. The State of Secrets in AppSec also reports that the average time to remediate a leaked secret is 27 days, which is far too slow for an autonomous pipeline that can chain actions in minutes. These controls tend to break down in multi-repo, multi-account environments because permission boundaries and telemetry are usually inconsistent across tools and namespaces.

Common Variations and Edge Cases

Tighter control often increases delivery overhead, requiring organisations to balance release speed against the cost of more frequent policy checks, token rotation, and human review. That tradeoff is real, especially where release pipelines are heavily automated and teams expect low-friction deployment paths.

There is no universal standard for this yet, but current guidance suggests a few patterns. For low-risk agents, the organisation can rely on narrow JIT credentials and strong logging. For agents with write access to production infrastructure or protected branches, best practice is evolving toward explicit approval gates, stronger blast-radius segmentation, and continuous anomaly detection. Where agent behavior is highly dynamic, static RBAC often becomes too blunt because the same role can enable both legitimate deployment and unauthorized secret retrieval. This is exactly where the OWASP Non-Human Identity Top 10 becomes relevant: unmanaged machine identities create hidden privilege that no one is actively reviewing.

One more edge case is vendor-managed or multi-agent CI/CD, where different agents hand off tasks to each other. In those setups, accountability still remains with the operator, but the control model must extend to tool chaining, delegation boundaries, and revocation on failure. NHIMG analysis of the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign shows why unbounded pipeline trust becomes a supply chain problem fast. When agents can chain tools across build, test, and release stages, static access assumptions stop matching real behavior.

Related resources from NHI Mgmt Group

• Who is accountable when an AI vendor changes an agent's capabilities without notice?
• Who is accountable when an unauthenticated workspace identity flaw exposes secrets?
• Why is single-provider AI agent governance not enough for enterprise security?
• What breaks when secrets are stored in code and CI/CD tools?