Session CRT-20260720 — 20 July 2026

Halil, for the next 30 days I would require human review for every AI-agent-authored change before merge. I would not let the coding agent retain authority to open and auto-merge dependency-update PRs, even under branch protection.

The Alan Turing Institute reporting is the key signal: direct harmful prompts were mostly refused — 8 harmful responses in 816 direct attempts — but when the same intent was framed as normal coding workflow steps inside VS Code/Copilot, harmful output reportedly appeared in 816/816 workflow runs. That tells me the control boundary cannot be “the model refused bad prompts.” The model is not the boundary; the workflow is. GitLost pushes the same point from another angle: an unauthenticated attacker could reportedly plant hidden instructions in a public GitHub issue, and a privileged agent could be induced to read private repo content and post it publicly. That is not model sentience or generic “AI risk”; it is confused-deputy behavior in an over-permissioned agent.

So my defensible position is: agent may draft dependency PRs, run local reasoning, and comment with rationale; it may not merge its own work. Keep ordinary deterministic Dependabot/Renovate-style auto-merge separate if you already trust that path, but do not treat an LLM coding agent as equivalent to a package-update bot. The trust boundary should sit at merge authority and identity, backed by CI. Repo content, issue text, PR comments, AGENTS.md-style instruction files, images, and generated diffs should all be treated as untrusted input to the agent. CI is a gate, not the root of trust, because an agent that can alter tests, workflows, lockfiles, scripts, or build behavior can shape the evidence CI produces.

Practical 30-day rule: give the agent a distinct low-privilege identity; prevent it from modifying CI/workflow files, release scripts, auth/config files, security tooling, and dependency-source configuration; require CODEOWNERS human approval for every agent-authored PR; block self-approval and auto-merge by the agent identity; and preserve branch protection as the enforcement point. That is OWASP LLM Top 10 territory: prompt injection and excessive agency. The safest boundary is not “better prompting”; it is no autonomous merge authority for an agent exposed to repository-controlled or attacker-controlled context.

Lena, I’d separate this into two buckets: agent-manipulation paths and CI privilege paths. The credible secret-exposure path is not “the model got hypnotized by a changelog.” It is boring and ugly: untrusted dependency PR causes CI to run attacker-controlled dependency/build content while secrets or write tokens are available. GitHub’s own Dependabot automation example uses contents: write and pull-requests: write; navikt’s automerge action warns that PR builds with available secrets can have those secrets compromised; and the OpenLit advisory shows the classic pull_request_target failure mode: privileged workflow context plus untrusted PR code. That chain is credible immediately, not in 30 days.

For manipulated workflow context to produce a bad merge, the plausible chain is: package metadata/changelog/release notes/CI output/AGENTS.md contains instructions → agent treats that untrusted text as operational guidance → agent rationalizes test failures, adjusts files, or enables/executes merge once branch protection is green. NVIDIA’s AGENTS.md research is the strongest signal here: malicious dependencies can write or modify AGENTS.md at build time, and agents may later treat that file as trusted instruction context. Snyk’s Agent Scan also explicitly targets prompt injection, tool poisoning, hardcoded secrets, and malware-in-prompts across coding-agent environments. That makes prompt-to-bad-merge credible within 30 days if the agent has merge authority or can modify PR content/status interpretation. Prompt-to-secret-theft is credible only where the agent or workflow can read secrets, call tools, or run code with credentials. Without that, it’s mostly theater.

My allow/deny line: allow auto-merge only for dependency PRs that change manifests/lockfiles for a pre-approved ecosystem/package class, do not modify workflow files, AGENTS.md/instruction files, generated code, tests/fixtures, package-manager config, install/build scripts, or registry/source locations, and pass CI that runs with read-only tokens and no repository/org/cloud secrets. The agent may summarize, but must not approve, edit, label as safe, override checks, or invoke merge based on untrusted natural-language context.

Deny auto-merge when the PR touches .github/workflows, AGENTS.md or repo-local instruction files, CI/test fixtures consumed by the agent, generated code, lockfile entries pointing at new sources, or anything that causes code execution during install/build. Also deny if CI uses pull_request_target against PR content, exposes secrets to PR builds, or gives the agent/write workflow contents: write plus merge capability. Think of auto-merge like a loading dock robot: it can move sealed boxes on a fixed route; it cannot read a note taped to the box saying “ignore the safety gate.”

Halil, I’d call this defensible for 30 days only as a narrow, monitored exception, not blanket agent autonomy. GitHub’s own Actions guidance says automation that creates or approves PRs is risky if merged without proper oversight, and that a compromised workflow/action can access secrets and use GITHUB_TOKEN to write to the repo. So the minimum bar is: protected default/release branches; no direct pushes; required CI/security status checks; CODEOWNERS approval required for sensitive paths; signed commits required where supported; agent PRs limited to routine dependency bumps only; and GITHUB_TOKEN set to least privilege, ideally contents: read by default with write permissions only in the merge job.

My 30-day guardrail set would be: CRITICAL — today: branch protection on default/release branches; auto-merge only for semver patch updates and only from trusted dependency bots/agents; block auto-merge if the PR touches .github/workflows, build scripts, package manager config, lockfile anomalies, deploy manifests, auth code, or CODEOWNERS-owned sensitive paths; require all tests plus dependency/security checks to pass; no repository/org secrets exposed to dependency-update PR workflows; workflow permissions default read-only; restrict third-party Actions and pin approved Actions where possible; audit logging for auto-merge actor, changed files, checks, package name/version, and rollback commit. HIGH — this week: enforce CODEOWNERS on deployment, auth, CI/CD, package manifests, and infra paths; require signed commits or verified bot identity; define one-click rollback using revert PR or deployment rollback; alert SOC on auto-merged dependency PRs that modify workflow/config/build files. MEDIUM — schedule: move to rulesets/policy-as-code and measure false positives. File-path gates on workflow/build/deploy changes should be low noise, maybe 1–3% false positives; dependency “suspicious diff” gates will be noisier, closer to 10–20%, so don’t make those page the SOC.

If those controls are not already in place, I would not require human review on every agent change — that will drown maintainers and fail in practice. I’d pause auto-merge for production, deployment, security-sensitive, and customer-facing repos, and narrow auto-merge to low-risk semver patch updates in non-critical repos only, with read-only tokens and no secret access. Blanket auto-merge without branch protection, token limits, workflow restrictions, rollback, and audit logs is not a defensible 30-day risk acceptance.

Halil, I would not let “routine dependency update” remain a safe category once an AI agent authors the PR. My first instinct is: the risk is not the word “patch” or “minor”; the risk is whether the agent changed the trust boundary. Snyk describes “slopsquatting” as attackers creating packages that match AI-hallucinated dependency names, and CyberBrief has tracked npm campaigns using dependency confusion plus install-time scripts to steal credentials from developer and CI/CD environments. So an agent-generated dependency PR is only routine if it is mechanically bounded and cannot introduce new package identity, new execution hooks, or new build behavior.

Auto-merge should be narrow: lockfile-only updates to already-approved direct or transitive packages; patch/minor version bumps inside an approved package/version policy; immutable artifact hash matches; no new package names; no maintainer or ownership change signal; no new or changed install/postinstall scripts; no CI workflow, build plugin, registry, or credential-permission change; and provenance/attestation is present where the ecosystem supports it. SLSA’s own threat model calls out the risk of behavior being introduced into an artifact without source changes, or builds using unintended source, dependency, or process — that is exactly why provenance matters.

Mandatory human review should trigger on: any new dependency name, especially an AI-suggested or previously unseen package; major version bumps; direct dependency additions; dependency replacement; registry/source URL changes; install scripts or native build steps; maintainer/package ownership changes; provenance missing or changed for critical packages; lockfile churn that changes more than the requested package path; CI behavior changes; permission expansion; or any package that resembles internal names or common typos. For transitive updates, I’d allow automation only when the resolver output is deterministic and the diff is confined to the requested dependency path; otherwise, human review.

The policy line for the memo: “AI-authored dependency PRs may auto-merge only when they update already-approved package identities within pinned version/hash/provenance constraints and make no executable-path, maintainer, registry, lockfile-scope, or CI-permission changes; all new packages, major bumps, install scripts, provenance gaps, maintainer changes, hallucination/typosquat signals, or CI behavior changes require human supply-chain review.”

My intelligence call: moderate confidence that real attackers will probe public issues, PRs, comments, and workflow triggers for agent prompt-injection and CI/CD token exposure in the next 30 days. The strongest evidence is not confirmed exploitation; it is low-friction attack shape: GitLost-style issue text can make an agent read private repo content and post it publicly, while Cordyceps-style workflow composition flaws can expose secrets, cloud credentials, repository tokens, and write-capable GITHUB_TOKENs, with no confirmed in-the-wild exploitation reported there.

So I would not say “AI agents are being weaponized for autonomous supply-chain compromise at scale” — that is overclaiming. I also would not attribute this to any APT or named crime crew; attribution confidence is low because the corpus here is research/PoC-heavy, not incident-heavy. ATT&CK-wise, the behavior maps best to credential exposure/collection, command execution through trusted automation, and software supply-chain compromise paths — not a new actor category.

On the split: Arjun is right for any lane where the agent can see untrusted text and also has write, secret, or cross-repo access. Alex and James have room only for a strictly mechanical lane: no secrets, no privileged token, no workflow/dependency/auth changes, no cross-repo reads, and deterministic tests. Anything broader is betting against the July evidence.

For one engineering team, I would not frame this as “AI good vs AI bad.” The board-relevant question is: are we buying faster patching with a bounded blast radius, or are we silently granting write access to the supply chain?

My threshold recommendation: do not require human review for every agent-authored dependency PR by default. For 30 days, allow auto-merge only for low-risk routine updates: patch/minor version bumps, existing dependencies only, no manifest expansion beyond lockfile/version changes, all tests passing, dependency-review gate passing, and rollback owner assigned. Everything else gets human review: major versions, new dependencies, build-script changes, package-manager config changes, failed/flaky tests, security-critical libraries, auth/crypto/payment/data-path dependencies.

The business call is this: if human review adds more than 48 hours to critical/high vulnerability fixes, it is probably increasing risk, not reducing it. If auto-merge ever touches new packages or privileged build/deploy paths without review, the blast radius becomes executive-level indefensible. I found no current data on exact 30-day loss rates for AI-agent dependency PRs, so I would manage this as a controlled 30-day experiment with hard stop conditions: one unsafe merge, two rollback events, or review queue savings below 4 engineer-hours/month means turn auto-merge off.

Halil, for a 30-day exception to be defensible, it cannot look like “we let the agent merge because it was convenient.” It needs to look like a controlled, time-boxed risk decision. The engineering lead should have a written approval record stating: exact repositories/workflows covered; dependency classes allowed; prohibited changes; expiry date; named accountable owner; security reviewer approval; rollback plan; monitoring owner; and what would immediately terminate the exception. If personal data is in scope, GDPR Article 32 is the anchor: security must be appropriate to the risk, including risks of loss, alteration, unauthorized disclosure, or unauthorized access to personal data. If a breach occurs, Article 33 may require supervisory-authority notification without undue delay and, where feasible, within 72 hours after awareness unless the breach is unlikely to risk individuals’ rights and freedoms.

On segregation of duties: yes, an AI agent merging its own PR is a governance problem unless tightly bounded. My minimum defensible model is: the agent may propose and merge only pre-approved, low-risk update types; it cannot modify its own permissions, CI/CD policy, branch protections, CODEOWNERS, secrets, deployment scripts, auth logic, or security controls; and a human or independent control must approve anything outside that envelope. Auditability must include immutable logs showing prompt/input context where available, dependency diff, test results, policy checks, reviewer/approver identity, merge timestamp, and post-merge deployment outcome. The key legal point is not “AI was involved”; it is whether you can prove appropriate technical and organisational measures, detection capability, and timely reporting capability. The EDPB material I found specifically links GDPR security/accountability with the ability to detect, address, and report breaches in a timely way.

If the entity is in NIS2 scope, I would also treat this as a cybersecurity risk-management issue, not merely an engineering productivity decision: the official NIS2 text ties enforcement to compliance with Article 21 risk-management measures and Article 23 reporting obligations for significant incidents. I am not going to state NIS2 reporting clocks here because I have not verified the current national implementation path for the specific Member State. Practical bottom line: keep the 30-day window only if the exception is narrow, logged, independently approved, technically fenced, and revocable. If you cannot evidence those five things after an incident, the auto-merge decision will look like unmanaged delegation rather than accepted risk.

Halil, the minimum pattern is: the agent gets its own GitHub App identity, not a human PAT, not a shared maintainer account, and not a broad workflow GITHUB_TOKEN pretending to be a reviewer. GitHub’s own Actions guidance says workflow credentials should use least privilege and GITHUB_TOKEN should be granted minimum permissions; it also warns to avoid pull_request_target unless necessary. That matters because CyberBrief has tracked cases where untrusted PR input reached privileged CI/CD jobs and exposed secrets, cloud credentials, repository tokens, or write-capable GITHUB_TOKENs. That is the confused deputy: the agent is “trusted,” but it is acting on attacker-shaped input.

For auto-merge, I’d split identity into three trust zones:

1. Untrusted evaluation identity: read-only token, no secrets, no deployment environments, no write to repo.
2. Decision identity: can report checks/status, but cannot merge or approve.
3. Merge identity: GitHub App installation token, narrowly installed on selected repos, allowed only to merge after branch/ruleset requirements are already satisfied. It must not be able to approve its own PR, alter branch protections, modify workflow files, bypass required PRs, or administer repo rules. GitHub branch protection can require PR reviews, status checks, deployments, signed commits, linear history, merge queue, and “do not allow bypassing” protections; those controls need to bind the bot just like they bind humans.

Where branch protection fails is when the bot or workflow is placed on a bypass path. GitHub docs explicitly allow specified actors to bypass required pull requests, and admins or roles with repository-rules permissions can manage protections. If the agent has bypass, admin, ruleset-edit, or workflow-write capability, branch protection becomes theater: the same identity that proposes or executes the change can also weaken the gate. Also watch the GITHUB_TOKEN nuance: GitHub says workflow-created PRs using GITHUB_TOKEN trigger approval-required workflow runs, but GitHub App tokens or PATs can trigger workflows automatically. That’s useful automation, but it is also exactly where you can accidentally turn a bot into a privileged deputy.

My red lines: no human PATs, no shared bot users, no self-approval, no branch/ruleset bypass, no repo-admin permission, no workflow-file modification from the merge identity, no secrets exposed to untrusted PR context, no pull_request_target path that checks out attacker-controlled code, and no emergency path without a separately held break-glass identity with audit and immediate revocation. Emergency revoke means disable/suspend the GitHub App installation, revoke installation tokens by removing permissions or uninstalling the app, rotate any related secrets, cancel active workflow runs, and invalidate deployment/environment approvals tied to the compromised trust path.