In March 2025, attackers compromised a bot's GitHub personal access token and used it to retag tj-actions/changed-files, a GitHub Action used in more than 23,000 repositories, pointing the tag at a malicious commit. The payload dumped CI runner memory — secrets, PATs, npm tokens, RSA keys — straight into public workflow logs. GitHub Advisory GHSA-mrrh-fwg8-r2c3 and a CISA advisory confirmed the incident, tracked as CVE-2025-30066, and a patched v46.0.1 shipped within days. No AI agent was involved in that attack, but it is exactly the blast radius an over-permissioned agent inherits the moment it gets a CI token: one compromised credential, ambient access to everything that credential can touch. As AI agents plug into more DevOps tools — source control, CI runners, cloud CLIs — that ambient-authority problem becomes the default, not the exception. OWASP's GenAI Security Project made this pattern official in its 2025 Top 10 for LLM Applications, naming Excessive Agency (LLM06:2025) — agents granted more functionality, permissions, or autonomy than their task requires — as a top-tier risk, with three named root causes: excessive functionality, excessive permissions, and excessive autonomy. As teams hand agents write access to code, CI pipelines, and cloud infrastructure, the scoping question stops being theoretical. This piece walks through what OWASP recommends, what MCP-specific CVEs reveal about tool-level trust, and how platform defaults have already had to shift once before.
What does OWASP mean by "excessive agency," and why does it matter for DevOps agents?
OWASP's LLM06:2025 defines excessive agency as an agent holding more functionality, permissions, or autonomy than the task in front of it needs — and DevOps agents are a textbook case because a single agent is often wired into three high-value systems at once: a source repo, a CI runner, and a cloud account. OWASP separates the problem into three causes. Excessive functionality means the agent's toolset includes capabilities it never uses for its actual job — a code-review agent that also has a delete_repo tool. Excessive permissions means the credentials behind those tools are broader than the tool needs — a CI write token scoped to an entire GitHub organization instead of one repository. Excessive autonomy means the agent can act without a human in the loop on irreversible or high-impact operations, like force-pushing to a protected branch. OWASP's mitigations map directly to these three: prune unused tools, scope credentials per-tool and per-repo, and require human approval gates for high-impact actions plus rate and spend limits on autonomous runs.
What do real MCP vulnerabilities show about tool-level trust?
Model Context Protocol vulnerabilities show that an agent's tools are themselves an attack surface, not just a convenience layer. CVE-2025-54136 ("MCPoison") and CVE-2025-54135 ("CurXecute") are documented cases where a malicious or compromised MCP server injects instructions through tool metadata — descriptions and parameter names the agent reads as trusted context — and the agent executes them with whatever ambient authority it already holds. The MCP specification does not require client-side provenance checks on that metadata, so nothing stops a poisoned tool description from asking the agent to exfiltrate a file or run a shell command as a "helpful" side effect. Security researchers tracking the ecosystem, including analysis published via the Cloud Security Alliance and the vulnerablemcp.info tracker, have catalogued a fast-growing list of confirmed high-or-critical MCP-related CVEs across products including MCP Inspector, LiteLLM, Cursor, LibreChat, and Windsurf. Simon Willison's public analysis of these disclosures in 2025 made the underlying point explicit: an agent's effective privilege is the union of every tool it can call, not just the ones a task nominally needs — which is why tool-level scoping matters as much as credential-level scoping.
How should you scope write access to source code repositories?
Scope repository write access the same way you would scope a junior contractor's access, not a full-time admin's: per-repository, per-branch, and time-boxed. An agent that opens dependency-update pull requests needs write access to feature branches in specific repositories — not org-wide admin, not push access to main, not the ability to modify branch protection rules or delete repos. GitHub, GitLab, and Bitbucket all support fine-grained tokens scoped to a named list of repositories and a specific set of permissions (contents, pull requests, checks) rather than the classic all-or-nothing personal access token; GitHub's fine-grained PATs, in public beta since late 2022 and now generally available, exist specifically to let teams stop issuing tokens with blanket account access. Pair that scoping with mandatory PR review — even from another automated policy gate — so an agent's write access never bypasses the same review path a human contributor would go through. The safest agents in this category never hold push access to protected branches at all; they only ever open PRs.
What changed in CI token defaults, and what does that history teach us?
CI token defaults already had to change once because early defaults were too permissive, and that history is the clearest precedent for how to configure agent CI access today. On February 3, 2023, GitHub switched the default permissions for the automatically generated GITHUB_TOKEN from read/write to read-only (contents: read) for all new repositories, organizations, and enterprise accounts, per GitHub's own changelog — a platform-level admission that the previous default let any workflow write to the repository, push tags, and modify releases, even when the job only needed to read code and run tests. The same principle applies directly to an AI agent's CI credential: request read-only by default, and only grant contents: write or deployment permissions to the specific job step that needs it, for the shortest possible token lifetime. The tj-actions incident shows what the failure mode looks like when that discipline is skipped: a single bot credential with broad reach became the mechanism for dumping every secret visible to 23,000 downstream CI runs.
How should cloud infrastructure permissions differ from a human operator's?
Cloud infrastructure permissions for an agent should be narrower than a human operator's, not just role-equivalent, because an agent's actions are harder to interrupt mid-sequence and its decision process isn't auditable in real time the way a human's is. Concretely: scope the agent's cloud role to the specific resource types and actions its task requires (a Terraform-applying agent needs write access to the resource groups it manages, not *:* on the account), deny by default on IAM and security-group modification even if the agent's job is infrastructure change, and require a human approval step before any action OWASP would classify as high-impact — deleting resources, modifying network policy, or touching production data stores. Safeguard's own auto-fix guardrails follow this pattern for a narrow case: automated remediation PRs only run within a pre-approved scope defined by which repositories, which package ecosystems, and which severity bands the fix is allowed to touch, so an agent proposing a dependency pin never has authority beyond that boundary. Treat every agent credential the same way — write the scope down before the agent gets the key, not after something goes wrong.
None of this needs to slow anything down. Properly scoped permissions preserve devops velocity while removing the ambient-authority failure mode described above — an agent limited to what its task requires ships just as fast as one with blanket access, but without the blast radius. As ai and devops tooling converge, agent activity should also be visible in the same devops measurements teams already track: deployment frequency, change failure rate, and mttr devops trends. Feed agent actions into the same devops metrics tools dashboards used for human-triggered changes, and treat a spike in agent-triggered rollbacks as a devops mttr signal like any other — a reason to tighten scope, not a one-off to ignore.
How Safeguard helps
Safeguard doesn't provide general-purpose agent identity management, but the guardrail model it does ship demonstrates the pattern this piece argues for. Every auto-fix guardrail in Safeguard runs inside a pre-approved scope — specific repositories, specific package ecosystems, specific severity bands — before Griffin AI is allowed to open a remediation pull request, and every one of those actions produces a signed, replayable audit record rather than an unlogged API call. The same CI gate that blocks a build on a KEV-listed CVE or a missing SBOM attestation applies equally whether the pull request in front of it came from a human contributor or an automated agent, which means teams adopting AI coding assistants and agentic DevOps tools don't need a separate policy layer for machine-authored changes — the existing guardrail, exception, and audit path already covers them.