Treat the delegation path as a governed identity relationship and require explicit approval boundaries between trust levels. Separate untrusted content ingestion from privileged workflow execution, and make downstream triggers dependent on machine-verifiable provenance rather than agent-generated comments or labels. That keeps automation from becoming a hidden escalation channel.
How agent-to-agent delegation should be treated in CI/CD and repo automation
When one automated actor can trigger another in build or repository workflows, the delegation itself becomes part of the security design, not a convenience detail. The right question is not whether the automation is useful, but whether each hop has a clearly bounded trust level, a defined approval boundary, and a verifiable source of authority before it can cause privileged work to run.
In practice, that means separating content ingestion, such as pull request text, issue comments, labels, or generated artifacts, from execution paths that can deploy, sign, publish, or change secrets. If a workflow is allowed to react to agent-produced output, it should do so only after provenance checks and policy validation, not because an agent asserted that a task is ready.
Repo automation is especially sensitive because the same control plane often spans code review, build orchestration, release signing, and cloud access. A delegated action that seems harmless in one repository can become a hidden escalation channel if it crosses environment boundaries or inherits broader credentials than the original task required.
Why delegation chains become risky in automated pipelines
Delegation chains fail when they are treated as opaque workflow glue. An agent can be perfectly legitimate in one role, yet unsafe once it can influence another agent or trigger a downstream job that holds stronger permissions. That is why Multi-Agent and A2A Security Guide is most useful when the concern is not just communication, but containment across hops, signed assertions, and cross-agent trust.
The main failure pattern is confused authority. A low-trust ingestion step can create a label, comment, or status signal that a privileged workflow interprets as approval. Once that happens, the control boundary has shifted from policy to content, which is easy to spoof, hard to audit, and often invisible to the reviewer who only sees the final job starting.
Another risk is over-broad delegation. If an upstream agent can mint a token, request a secret, or invoke a release action on behalf of another principal, the organisation has effectively created a chain of implied trust. Agentic AI Identity Guide is relevant here because it frames delegation, ownership, and lifecycle as the controls that determine whether the acting principal is actually allowed to speak for someone else.
Controls that make agent-to-agent approval boundaries enforceable
The most effective control is to make the privileged workflow depend on machine-verifiable provenance, not on agent-authored narrative. For CI/CD, that usually means signed artifacts, trusted build attestations, and policy checks that evaluate the object being promoted rather than the text that asked for promotion. SLSA is a good fit when the real issue is build provenance and release integrity.
Where delegation is unavoidable, the approval step should be explicit, scoped, and revocable. The delegated principal should have the minimum access needed for that task, and the workflow should distinguish between task initiation, task approval, and task execution. RFC 8693: OAuth 2.0 Token Exchange is useful because it formalises token exchange for on-behalf-of flows instead of relying on ad hoc impersonation.
For organisations running agentic automation in repositories and pipelines, the practical design rule is to keep untrusted inputs in a non-executing lane. An agent may triage, summarise, or propose actions, but the workflow that can merge, release, or rotate secrets should require separate policy evaluation and a fresh trust decision at the point of execution. When token scope, provenance, and approval are aligned, agent delegation becomes auditable instead of latent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Delegated automation depends on trustworthy machine auth and token handling. |
| NHI-05 — Overprivileged NHI | Agent delegation in CI/CD often fails through excessive permissions on workflow principals. | |
| NHI-07 — Long-Lived Secrets | Repo automation becomes easier to abuse when delegation relies on durable secrets. | |
| Recommendation — Use step-up trust checks and scoped credentials before allowing delegated actions. Reduce workflow privilege to the minimum required for each delegated step. Replace durable secrets with short-lived, exchange-based credentials wherever possible. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | This question is about agents influencing privileged downstream automation. |
| ASI07 — Insecure Inter-Agent Communication | Agent-to-agent delegation in pipelines hinges on whether inter-agent signals can be trusted. | |
| Recommendation — Separate approval from execution and enforce per-action policy for delegated agent requests. Authenticate inter-agent messages and reject unauthenticated control signals. | ||
| SLSA | Supply-chain Levels for Software Artifacts | CI/CD delegation should depend on provenance and build integrity before promotion. |
| Recommendation — Require verifiable provenance for artefacts before any privileged release step. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Delegated machine-to-machine flows need strong authentication for the acting principal. |
| AC-6 — Least Privilege | Delegated workflows should not inherit broad access beyond the task at hand. | |
| AU-2 — Audit Events | Delegated approvals and downstream triggers must be observable for review and detection. | |
| Recommendation — Authenticate each automation principal with a verifiable machine identity. Limit each workflow identity to the minimum access needed for its current action. Log approval, trigger, and execution events for every delegated automation hop. | ||
Practitioner Guidance
What to verify: Confirm that the workflow cannot turn an agent-generated comment, label, or status update into an execution trigger without a separate policy decision. If the same signal can both communicate intent and authorise action, the boundary is too weak.
Decision rule: If the delegated action can reach production, secrets, signing keys, or deployment credentials, treat it as privileged automation and require provenance-backed approval. If it only prepares context or drafts changes, keep it outside the execution path.
What good looks like: Each hop in the chain has a named actor, a bounded scope, an audit trail, and a verifiable artefact or token exchange that explains why the next step was allowed to proceed.
Practitioner takeaway: The safest pattern is not “agents can ask agents to do things”, but “every delegated step must prove who asked, what was approved, and why the downstream system should trust it.”