In May 2026, InfoQ published How GitHub Is Securing Agentic Workflows in Modern CI CD Systems, detailing GitHub's defense-in-depth architecture designed to safely operate autonomous agents inside CI/CD pipelines. Based on the three pillars of Isolation, Constrained Execution, and Auditability, this architecture mitigates prompt injection, privilege escalation, and unintended behaviors.
At our firm, we are seeing an increasing number of inquiries from clients seeking to “introduce AI agents into production repositories.” Drawing on GitHub's defense-in-depth model, this article breaks down practical implementation patterns, contract clauses, and common pitfalls for custom development engagements. Cost optimization is covered in Token Efficiency in GitHub Agentic Workflows, while reviewing agent-generated pull requests is discussed in Standard Flow for Agent PR Reviews; this article serves as their security counterpart.
Why focus on “agent defense in CI/CD” now?
The integration of agents into CI/CD pipelines has accelerated dramatically over the past year, but security incidents have increased in tandem.
| Incident category | Scenarios that can occur in custom development |
|---|---|
| Prompt injection | Confidential secrets leaked via external PR descriptions |
| Privilege escalation | Agent using GITHUB_TOKEN to write to repositories it should not have access to |
| Unintended behavior | “Auto-fix” pushing directly to the production branch, breaking features |
| Supply chain contamination | Auto-merge pulling in malicious dependencies |
These incidents inevitably occur in designs that “let agents do everything.” GitHub's defense-in-depth approach takes the straightforward and robust stance of “clearly cordoning off areas where agents are forbidden to operate.” This extends the same philosophy of supply chain defense covered in Arbitrary Execution with npm install and DevSecOps directly into the agent operations layer.
Translating the three pillars of defense-in-depth to custom development
Translating GitHub's model into custom development practices yields the following three tiers.
Pillar 1: Isolation
Agents must never run on host runners; instead, confine them inside ephemeral containers or Firecracker MicroVMs.
| Isolation level | Implementation | Application in custom development |
|---|---|---|
| Process isolation | Docker | Simple implementation, compatible with existing Actions |
| Kernel isolation | gVisor / Kata | Standard for business SaaS projects |
| Hardware isolation | Firecracker | Finance, healthcare, and publicly traded enterprises |
In particular, jobs triggered by external PRs must always run under Firecracker-level isolation. Never run them on the same runners as internal push jobs as an ironclad rule.
Pillar 2: Constrained Execution
Restrict the APIs an agent can call, the shell commands it can execute, and the secrets it can access using an explicit allowlist.
| Target of constraint | Implementation method |
|---|---|
| GitHub API | OIDC + ephemeral tokens + repository-scoped permissions |
| Shell commands | seccomp profile + AppArmor |
| Network | Restrict egress to permitted hosts only |
| secrets | Retrieve on demand from Secrets Manager rather than via environment variables |
When combined with the “ephemeral identities + on-demand retrieval” discussed in Agent Secrets Integration with HashiCorp Vault 2, this approaches an architecture where “even if a leak occurs, no actual harm is done.”
Pillar 3: Auditability
Comprehensively log “what the agent saw, what it reasoned, and what it did,” maintaining full post-hoc reproducibility.
| Logging target | Storage destination | Retention period |
|---|---|---|
| Input prompt + context | Immutable storage (S3 Object Lock, etc.) | 7 years |
| Agent reasoning logs | Same as above | 1 year |
| Executed commands + outputs | SIEM | 1 year |
| Impact scope (modified files / API calls) | Git logs + CloudTrail | Permanent |
In particular, "storage in immutable storage" is designed to "produce tamper-proof evidence in the event of an incident," making it a mandatory requirement in custom development for regulated industries.
The four stages of agent operations in custom development
Reflecting GitHub's defense-in-depth principles, the following phased roadmap offers a practical blueprint for introducing agents into client projects.
[Phase 0: 観察モード]
├ エージェントは提案のみ、実行はしない
├ PR コメントで「こうします」と言うだけ
└ 1 〜 2 ヶ月、誤検知率を計測
[Phase 1: 限定実行モード]
├ Lint 修正・フォーマット・コメント生成のみ自動実行
├ ブランチは feature/* に限定
└ main / release への書き込み禁止
[Phase 2: PR 自動作成モード]
├ 依存更新・テスト追加の PR を自動作成
├ マージは必ず人間レビュー
└ 自動修正 PR にラベル付与
[Phase 3: 限定マージモード]
├ 特定条件（緑のテスト + 影響範囲小）で自動マージ可
├ ただし即時ロールバック手段を確保
└ 月次でロールバック発生率をレビューBecause rushing the transition from Phase 0 to Phase 1 frequently results in failure, explicitly include “a minimum observation period of four weeks” in the contract. This shares the same philosophy of graduated approvals covered in Approval Gates in Claude Code Auto Mode.
“Agent operation clauses” to include in client contracts
When entering into custom development contracts that deploy agents into client repositories, explicitly define the following clauses.
| Clause | Details | What the client should verify |
|---|---|---|
| Isolation level | Adoption of process, kernel, or hardware isolation | Alignment with industry regulations |
| Permission scope | Repositories, branches, and files the agent may modify | Repository-level authorization |
| Secrets access | List of secrets accessible by the agent | Labeling based on sensitivity levels |
| Execution log retention period | Years of retention for prompt, reasoning, and output logs | Alignment with industry regulations |
| Incident response SLA | Time elapsed from anomaly detection to shutdown | Selection between 24h, 4h, or immediate response tiers |
| Rollback procedures | Recovery steps during agent-induced failures | RPO / RTO |
| Demarcation of responsibilities | Party liable for agent malfunctions | Presence or absence of insurance and indemnity |
In particular, unless you clearly define the "division of responsibilities" upfront, you will be left bearing the blame when a client complains that 'the AI broke it.' You need concrete contractual language stating that "our company is responsible for actions outside the whitelist, while the client bears responsibility for decisions made within the whitelist."
Five common pitfalls
Here are common pitfalls when operating CI/CD agents in custom development.
Pitfall 1: Running agents on the same runners as existing Actions
Treating an agent as “just another Action” completely breaks isolation. Separate them physically using dedicated runner labels and dedicated networks.
Pitfall 2: Granting full permissions to GITHUB_TOKEN
The default GITHUB_TOKEN possesses overly broad permissions. Minimize permissions on a per-workflow basis, and issue separate App Tokens when necessary.
Pitfall 3: Neglecting prompt injection testing
Vulnerabilities executed via external PR descriptions will go unnoticed unless you deliberately run attack simulations in staging environments. Incorporate monthly red teaming exercises into the contract.
Pitfall 4: Treating audit logs as “nice to have”
Logs that nobody reviews effectively do not exist. Include monthly sampling audits of logs in the contract and turn the anomaly detection rate into a tracked KPI.
Pitfall 5: Advancing to Phase 3 without establishing rollback mechanisms
Before proceeding to automatic merge mode, always implement "tooling and training for immediately reverting any PR." Deploying to production without drills is a breeding ground for incidents.
Conclusion — moving from “making agents work” to “running them safely”
GitHub's defense-in-depth architecture is the official answer to the phase of CI/CD agent operations where "we know it works, but running it safely is difficult." On the custom development frontline, an architectural design that explicitly defines the boundaries of responsibility when "introducing agents into client repositories" is absolutely essential.
When integrating agents into CI/CD, the required standards for isolation design, permission scoping, and audit logging vary widely based on repository structure and regulatory demands. Whether you “want to boost in-house engineering productivity with AI but have security concerns” or find that “agents were introduced but operations are stalling,” we offer tailored consultations and estimates based on your current setup. Feel free to contact us via our contact form.
Sources
- How GitHub Is Securing Agentic Workflows in Modern CI CD Systems（InfoQ）
- Token efficiency in GitHub Agentic Workflows (GH Media)
- Standard flow for agent PR reviews (GH Media)
- Arbitrary execution with npm install and custom DevSecOps (GH Media)
- Agent secrets integration with HashiCorp Vault 2 (GH Media)
- Safely Operating Claude Code Auto Mode in Custom Development (GH Media)
