A secure SDLC supports agent-authored code when teams bind every change to a scoped workload identity and enforce controls server-side, because programmatic commits bypass client hooks and arrive faster than human review queues can absorb.
TL;DR
Every phase gate in a conventional secure SDLC assumes an accountable human account and human-paced change, and agentic authorship breaks both at once. The frameworks have not caught up: none of them defines whether a service account satisfies an individual-accountability requirement. This guide maps each phase to the control that replaces it.
Consider a hypothetical Monday queue with 40 pull requests. A coding agent running under a service account opened all 40 overnight. The pre-commit hooks that catch secrets never fired. GitHub created the commits server-side through its createCommitOnBranch GraphQL mutation, so they never touched a working tree. GitHub also marked them Verified because it automatically signs commits created through that path.
A review rota sized for six human PRs a day remains the only control still standing, and the queue overwhelms it before standup. This guide is for security engineers and platform leads whose secure SDLC controls assume a person wrote every commit.
Cosmos is Augment Code's unified cloud agents platform for coordinating work across the software development lifecycle, and it is one of the platforms that puts an agent on the authoring side of that assumption.
Why Agent Authorship Is Hard
A conventional secure SDLC encodes two assumptions in every phase gate: the committer is a person whose account represents an accountable identity, and change arrives at a rate human attention can absorb. Agentic authorship breaks both assumptions mechanically.
Teams lose reliable identity attribution first. Client-side controls live on the human's machine. Git stores hooks in the local .git/hooks directory, and Pro Git documents that cloning a repository does not copy them. The githooks reference confirms that --no-verify bypasses pre-commit entirely. An agent committing through a REST or GraphQL API skips all of it because no local Git process runs. Attribution also disappears when an agent uses a developer's credentials, since the commit log cannot distinguish the agent from that developer.
Review teams face the next failure at higher throughput, and the curl project measured the collapse. AI-generated reports reached roughly 20% of curl's vulnerability submissions by July 2025, and the confirmed-vulnerability rate fell from a historical figure above 15% to below 5%. Daniel Stenberg terminated the project's bug bounty on January 31, 2026. After the program closed, report quality recovered, but submission volume did not, and that volume is the half of the problem that transfers directly to an internal review queue.
What Has to Be Inventoried First
Before the pipeline changes, teams need an inventory of every repository where an agent can create commits, branches, pull requests, or merges. That inventory records the machine identity, credential type, permission scope, token lifetime, protected-branch rules, required checks, review policy, and deploy metadata available for each path.
Teams also need a labeled sample of agent-authored pull requests for measuring policy precision. Credential rotation and blocking-rule approval each need a named owner, because a gate without an accountable operator becomes a permanent exception or an unreviewed source of false rejections.
Why Secure SDLC Assumptions Fail
Security by design put controls at the earliest phase because the human author was the cheapest point of intervention. Teams trained developers and provided early feedback through design reviews and IDE warnings. The $80-versus-$7,600 figures come from IBM security presentations citing an unlocated 2009-10 Ponemon study. Boehm and Basili provide the defensible version at 100 times, though they qualify the factor for smaller systems. Menzies et al., in a 2016 preprint, found no consistent delayed-issue effect across 47,376 defect logs from 171 Team Software Process projects.
Agentic authorship reshapes the curve. Generation cost collapses toward zero while verification stays human-priced, and measured studies show that the author can inject defects. Veracode's report found that 45% of AI-generated code tasks across multiple languages introduced a known security flaw. Java performed worst, with a 72% security failure rate. The vendor-published report measures generated tasks, not production incident rates.
Shifting left still pays, but no security team can train or mentor this author. Teams should move machine-readable requirements and executable policy earlier in the SDLC. They should bind both controls to a workload identity the platform can verify.
A Phase-by-Phase Control Map
Teams should preserve each lifecycle phase's purpose while replacing enforcement points that programmatic commits can bypass. Every replacement or complementary control below moves the check to a point an API-created commit cannot skip, and the last column names the adoption trigger.
| SDLC Phase | Legacy Control | Failure When Agent Authors | Replacement or Complementary Control | When to Use |
|---|---|---|---|---|
| Requirements | Security requirements elicited in human workshops | Agent fills unstated requirements with its own defaults | Machine-readable security requirements and abuse cases in the repo | Any repo where agents take tickets |
| Design | Threat model listing human actors | Agent absent from the DFD; its credentials cross unmodeled boundaries | Agent modeled as an external entity with its own trust boundary | Before granting an agent write access |
| Code | Client-side pre-commit hooks and IDE warnings | API-created commits never invoke local hooks; --no-verify skips them | Server-side push protection and pre-receive enforcement | All programmatic commit paths |
| Build | CI checks assuming human-triggered pushes | Broad standing tokens; control plane generates no provenance | SLSA build provenance from the control plane and scoped short-lived tokens | Any pipeline an agent can trigger |
| Test | Human-paced review plus scanning | Review queue saturates at agent PR volume | Policy-as-code triage with measured precision plus human review | Programmatic PRs above human review capacity |
| Deploy | Human approval gates | Bot exceptions bypass two-person review | Perpetual trusted-robot exceptions per SLSA v1.2 | Protected branches receiving agent merges |
| Operate | Incident response assuming localized change | One flawed pattern ships across dozens of services at once | Provenance-keyed telemetry and revert-by-author identity | After the first agent-authored production merge |
Threat Modeling the Agent
STRIDE already models automated actors as external entities, and Microsoft's threat-modeling training defines that element as anything outside direct control. The trust-boundary and abuse-case analysis then tests whether the platform can authenticate the agent and preserve an attributable record of its actions.
The Agent as a Trust Boundary
An authoring agent holds a service-account identity on one side of a boundary and untrusted content on the other. That content combines repository and ticket text with tool output. Under STRIDE per element, external entities attract spoofing and repudiation. Those categories test whether the agent is what it claims to be and whether someone can later deny its action. Microsoft's agent architecture guidance extends the method to orchestration services, language models, tool integrations, and data sources.
Cato AI Labs' DuneSlide research documented the consequence in Cursor. Prompt injection carried in attacker-controlled content, such as an MCP server response or a poisoned web result, steered the agent into writing outside the project directory through a symlink whose canonicalization failed. Cato reported the flaws as CVE-2026-50548 and CVE-2026-50549, and Cursor patched both in Cursor 3.0 in April 2026.
Microsoft Threat Intelligence found that Anthropic's Claude Code GitHub Action could expose ANTHROPIC_API_KEY through /proc/self/environ. Anthropic mitigated it in Claude Code 2.1.128 by blocking access to sensitive /proc files. Least privilege and assume-breach therefore become architecture constraints on the agent itself: a task-scoped token without standing runtime secrets, and egress disabled by default. Where agents run on Cosmos, execution happens inside isolated Environments, not on a developer's machine.
Abuse Cases for Autonomous Authorship
Abuse cases read like security user stories with the agent in the actor slot. Trail of Bits showed that a crafted GitHub issue could steer Copilot Agent into inserting a backdoor into its own pull request. The flaw became CVE-2025-53773 at CVSS 7.8. Security teams should treat all agent-facing content as untrusted because attacker-controlled text becomes author input.
In April 2026, the prt-scan campaign opened 475+ malicious PRs in 26 hours and compromised at least two npm packages. A defender's abuse case must assume its own agents can operate at that rate, then cap blast radius per identity and hour.
Repositioning Application Security Tests
NIST SP 800-204C places static vulnerability checks in the build phase and dynamic checks against running application states. That division holds; the CI pipeline now sends the output to executable policy before assigning the PR to a human reviewer.
SAST must run on every programmatic PR, where triage economics determine whether it works. Charoenwet et al., in a peer-reviewed ISSTA 2024 paper covering 815 vulnerability-contributing commits across 92 C and C++ projects, found that a single SAST tool produced warnings in vulnerable functions for 52% of those commits, while 22% remained undetected across all five tools tested. The researchers also found that at least 76% of warnings in vulnerable functions were irrelevant. At agent volume, policy should triage that load while only high-precision rule classes block. Human reviewers still handle findings that require context or judgment.
DAST needs a running application, so it attaches after the PR gate where agent branches deploy to staging. Security teams move SCA earlier to dependency ingestion because agents install packages while completing tasks. Snyk's Clinejection report documented an issue-title injection that made an AI triage bot run npm install from an attacker-controlled commit. An unauthorized package release then went live on npm.
Agents running on Cosmos resolve and install packages inside an Environment, so dependency ingestion happens at a point the platform can observe, not on an unmonitored workstation.
Secrets detection is the earliest gate and belongs at the agent boundary. Gitleaks documents its own bypass by allowing SKIP=gitleaks before the commit command. The enforceable location is the server: GitHub's push protection API rejects a push containing a detected secret with an HTTP 409.
Measured Gates as Review Triage
The review-stage gate encodes checks a human reviewer can define precisely, including forbidden APIs, tainted data paths, dependency policy, and secret handling. It runs those checks as the executable policy modules that NIST SP 800-204C describes inside the CI/CD pipeline.
Salesforce Engineering reported that MuleSoft ran LLM-based review skills against AI-generated code 77,000 times across 14,000+ PRs in 30 days. The team kept false-positive rejections under 0.5% and required a skill to clear three conditions before it could block a merge: testing across at least five repositories, an independently audited sample of findings, and 95% precision on findings that reproduced across repeated runs. The first-party case study demonstrates one organization's thresholding process, not a general recall benchmark for policy-as-code gates.
NIST SP 800-204D still expects another developer to review a patch before merge. Policy-as-code and human review are complementary controls: the gate handles deterministic enforcement, while reviewers assess design intent and business logic.
On Cosmos, the Deep Code Review reference Expert reads programmatic PRs end to end and posts inline comments, allowing human reviewers to focus on findings that require judgment. Automated review still depends on repository policy, scoped credentials, human approval rules, and audit retention outside the agent itself.
Supply Chain Integrity
The SLSA project announced in November 2025 that SLSA v1.2 gives teams explicit structural vocabulary for agent commits. Its Source Track distinguishes a trusted person from a trusted robot, defining the latter as automation authorized by the organization to act in explicitly defined contexts, whose identity and codebase cannot be unilaterally influenced.
At Source Level 4, changes to protected branches must be agreed to by two or more trusted persons before submission, though an organization may grant a trusted robot a perpetual exception to that policy. SLSA's own threat guidance argues against taking it. It treats a robot that can submit without two-person review as an attack vector, recommends reviewing robot-authored changes while discounting the robot's own approval, and notes that control of one robot account plus one personal account lets a single actor approve their own change. The permission and the warning sit in the same specification, so granting that exception is a policy decision, not a sanctioned shortcut. SLSA also treats the builder as a platform. builder.id determines the build level, and the control plane must generate provenance without allowing a tenant to alter it.
OpenSSF guidance scopes build provenance to workload identity rather than human identity verification. CISA's 2026 Minimum Elements v2.1 adds an SBOM Generation Context field in which the SBOM producer describes how it produced a component, though it defines no distinct class for agent-authored components. The same logic applies to any platform running agents on a team's behalf. Cosmos executes work in Sessions that retain an auditable record of each run, which is the artifact a provenance claim has to point at.
| Framework | Identity Treatment | Review Requirement | Provenance or SBOM Treatment | Agent-Specific Gap | When to Use |
|---|---|---|---|---|---|
| SLSA v1.2 | Distinguishes trusted persons and trusted robots | Two trusted persons at Source Level 4; perpetual robot exceptions permitted | Control-plane build provenance tied to builder.id | Organization defines exception scope | Protected source and build pipelines |
| NIST SSDF v1.1 | Requires accountability to an individual account | Human review of tool-reported issues | PS.3 covers release provenance | Does not define service-account status | Secure development governance |
| OWASP SAMM v2.2.0 | No explicit agent identity control | Mandatory checks at Secure Build maturity 3 | Build and deployment integrity controls | Model does not explicitly reference AI | Maturity assessment and pipeline design |
| CISA SBOM v2.1 | No author identity field for agents | Not an authorship review standard | Adds SBOM Generation Context | No distinct agent-authored component class | Federal supplier SBOM programs |
Signed commits extend to agent identity, with caveats. GitHub verifies bot signatures only when the GitHub App authenticates the request and omits custom authorship fields and signature information. Copilot's cloud agent signs every commit as of April 3, 2026, and those signatures satisfy the platform's signed-commit branch protection.
NIST SP 800-218 requires accountability to an individual account without defining whether a service account qualifies, and SP 800-218A declines to treat AI-generated source code as a separate category. NIST published a concept paper on February 5, 2026, that seeks input on identification, authorization, auditing, and non-repudiation of AI agents.
Applying the Controls
Work through the changes in order because each control depends on the identity and enforcement decisions before it.
- Scope agent identity first. Inventory every credential an agent holds. Replace human PATs with GitHub App installation access tokens, which expire after one hour and carry no default permissions, or use fine-grained PATs scoped to
contents: writeandpull_requests: write. - Move enforcement server-side. Turn on branch rulesets, required status checks, secret-scanning push protection, and merge approvals. On GitLab, configure server hooks and approval policies with
prevent_approval_by_authorset. Treat every client-side hook as advisory from this point forward. - Attach a policy gate. Run the gate without blocking for two to four weeks. Measure precision against a labeled sample of agent PRs, then grant blocking authority only to rule classes that hold their threshold. Where agents run through Cosmos, the PR Author reference Expert carries approved changes through the pull-request workflow under configured human review policies.
- Extend the threat model. Add each agent to the data flow diagram as an external entity. Draw its trust boundary around untrusted repository and ticket content plus tool output. Write abuse cases for attacker-controlled author input and hostile submission volume.
- Wire telemetry to authorship. Tag every agent-authored merge in deploy metadata so an incident query returns every service carrying a given agent-introduced pattern. Feed the query with build provenance and alert when one agent identity's merge rate departs from its baseline.
Past a handful of repositories, maintaining these controls by hand becomes its own failure mode. Cosmos runs agents in sandboxed, isolated Environments with granular role-based access control, while Sessions provide an auditable record of each workflow. Platform controls still need to enforce repository permissions and merge policy independently.
Where These Controls Go Wrong
Teams that adopt the replacement controls still encounter four recurring failure modes. Each remedy restores a measurable boundary rather than adding another advisory warning.
- Policy-as-code acts as a rubber stamp. A gate receives blocking authority before anyone measures precision against a labeled PR set. MuleSoft's promotion rule applies: no automated check blocks a merge until its precision has been measured against a labeled sample and independently audited.
- Scanning runs outside the gate. Findings from agent PRs appear only as advisory comments. A gate configured as a required check on protected branches turns those comments into a merge condition, and human review stays with contextual findings.
- Agents hold standing broad credentials. An agent runs under a human PAT or an organization-wide token. In the hackerbot-claw campaign, an adversarial agent escalated to exfiltrating
GITHUB_TOKENbefore Datadog's lockdown ofpull-requests: writestopped it. Swapping that credential for a short-lived, job-scoped token removes the standing grant. - Teams stop recording audit evidence before merge. Agents run on laptops and submit PRs under human accounts. The AgenTag preprint separated agent-authored from human-authored pull requests at a balanced F1 of 0.89 across 33,580 agent and 6,618 human-authored pull requests, and found that those signatures persisted even after researchers removed explicit self-disclosed markers. Every run needs a distinct machine identity and an approval record. A platform that runs agents under its own identity closes this gap: on Cosmos, work executes in Sessions tied to an Environment, not under a developer's local account.
All four failures share one cause: the enforcement layer cannot bind an action to a scoped machine identity and a review decision.
What to Do Next
The tradeoff is control cycle time against authorship throughput. Workload identity and server-side enforcement add little merge-time delay, while broad manual review queues add delay to every change.
Choose one repository where an agent already opens PRs. Revoke its human-scoped credential and issue a one-hour app token. Then make the measured policy gate a required status check and track PR throughput plus gate precision for two weeks. The result should be a labeled precision figure for every blocking rule class and a baseline merge rate for the agent identity before the next repository adopts the model.
Frequently Asked Questions
Related Reading
Written by
Ani Galstian
Ani writes about enterprise-scale AI coding tool evaluation, agentic development security, and the operational patterns that make AI agents reliable in production. His guides cover topics like AGENTS.md context files, spec-as-source-of-truth workflows, and how engineering teams should assess AI coding tools across dimensions like auditability and security compliance