How to establish secure SDLC guardrails for agentic development

The ‘traditional’ secure software development lifecycle (secure SDLC)—the secure SDLC before agentic development—operates on three core assumptions: humans write most or all of the code, humans fully comprehend the code, and humans are make all decisions and bear all accountability for how and when the code executes.

This—and the fact that humans can only write so much code in a give day—makes security in the traditional SDLC comparatively straightforward and manageable. Guardrails focus on code quality fundamentals, code review, access controls, resource restrictions, traditional security testing (e.g. penetration testing) and automated detection of known and potential vulnerabilities.

Agentic development shatters this model. AI agents do their own planning and resourcing. They execute huge numbers of actions without human intervention, and can behave in unexpected ways, at scale. They generate huge volumes of code beyond human understanding or sheer human capacity for review.

So while agentic development makes software development faster, new guardrails are required to mitigate new security, compliance operational risks associated with agents. The modern secure software development lifecycle (SSDLC) must define what agents can do and how humans approve these actions, and make every agentic action auditable.

Imagine a scenario where an enterprise deploys an autonomous code refactoring agent to modernize a legacy service via a cloud migration. The enterprise relies on standard DevSecOps guardrails like threat modeling, static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), software composition analysis (SCA), infrastructure as code (IaC) linting, and mandatory peer code reviews.

But while scanning public documentation, the agent encounters a malicious repository containing an indirect prompt injection that instructs the agent to bypass internal safeguards.

The SAST scanner performs static analysis on the code the agent generates, but doesn’t catch any issues because although the code is syntactically flawless, SAST can’t detect that the agent’s intent was hijacked by an external prompt.

Under the influence of the prompt injection, the agent modifies a configuration script to pull a specific data-parsing package. Software composition analysis is meant to check the package against databases of known security vulnerabilities and exploitability, but it doesn’t catch the agent feeding sensitive corporate data dynamically during runtime.

The agent is granted a standard “cloud developer” role that lets it create and modify storage infrastructure in the staging environment. IaC scanners perform a point-in-time check, but don’t see the agent modifying a template later on.

Operating at machine speed, the agent splits the migration into 500 micro-pull requests. The human developers check the first 100 and find nothing out of the ordinary. But the malicious PR was the 499th.

AI-assisted development increases speed, but also expands the risk surface with such novel attack vectors at play.

To secure the SDLC in an era of AI agents, organizations must evolve from cautious prompt engineering in experimental use cases to comprehensive, structural, automated agent governance.

Identity, access and authorization doesn’t represent a new risk, but an evolved one. Traditional systems needed to verify who was accessing a system and decide what users were authorized to do. Agents require the same verification, but since their behaviors can vastly exceed the volume of what humans can accomplish, they require more granular controls. Agents need unique identities, least-privilege access controls, task-specific credentials, and authorizations enforced outside the model.

Organizations can look to standards bodies and regulations for guidance on agent identity. In the U.S., for example, the National Institute of Standards and Technology (NIST) is a government agency that develops standards-based approaches and practical guidance. Its National Cybersecurity Center of Excellence (NCCoE) is working on standards for AI agent identity and authorization.

Can someone manipulate what the agent thinks it’s supposed to do? And what harm could an agent do, even when it’s not being manipulated externally by a bad actor?

Dangerous inputs can include prompt injections and behavioral manipulation, along with context, memory and tool and data poisoning. Malicious instructions can lie dormant in web pages, source code comments or another agent’s output. This means that the entire SDLC becomes part of the attack surface.

And unintended agent behaviors aren’t always a product of malice. An agent with access to tools can turn a bad decision into an action. So agents’ tool use needs to be governed. Per-tool permissions and backend enforcement can be more reliable than expecting prompts to constrain tool use.

Code quality refers to the robustness of code beyond whether or not it simply runs and performs its desired function. Agents might optimize against explicit rules rather than an underlying goal if not properly prompted. Sometimes agent-authored code is more verbose or structurally complex than it needs to be. Projects can accumulate redundancies, and the low cost of AI code generation can encourage teams to ship massive volumes of pull requests, creating review bottlenecks. Small defects can scale quickly across teams and repositories.

Fortunately, while agentic tools present a risk, they also represent a powerful solution. Modern agentic coding tools like IBM BOB can quickly scan large legacy codebases to identify code smells and resolve spaghetti code, minimizing the need for time-consuming manual inspection of potentially thousands of lines of code.

What new risks can the agent introduce into the software supply chain? AI tools may introduce libraries, templates, or packages that have not been approved. Software supply-chain amplification happens when a single hidden flaw or small breach in a shared component ripples downstream to affect potentially thousands of organizations and millions of users. Autonomous agents can discover, select and install dependencies at machine speed. Agents can make the same mistake across hundreds of files without anyone noticing.

When agents can direct one another, the attack surface includes the communication and orchestration layer. An agent can pass malicious messages to another, resulting in goal hijacking and cascading failures.

A traditional audit trail assumes a deterministic chain of human decisions and system events. But agentic development isn’t so linear. Being able to prove what an agent did involves determining the model and version it used, the instructions and context it received, the repositories and files it accessed, the tools it used, what controls it passed, where a human might’ve intervened and more.

Violating GDPR or HIPAA could represent a catastrophic outcome, and even minor violations require explanation. Organizations increasingly need to be able to reconstruct the sequence of events preceding a violation of compliance or other incident.

In the age of AI agents, the secure SDLC should establish a secure way for teams to develop software while preserving the speed that agents make possible. The goal is to encourage development that’s standardized, governed and auditable without turning security into a bottleneck.

Engineers should be able to use AI to generate code, run tests and automate routine tasks, and the organization should provide appropriate oversight for what those agents can do, reducing the chance of insecure or unapproved changes reaching production.

Where controls act as checkpoints, guardrails shape the flow of development continuously, just as real-world guardrails shape traffic from the roadside. Enterprises need both to make the secure SDLC scalable.

The fundamental principle for a modern, secure SDLC is that guardrails be embedded across developer workflows, CI/CD pipelines, AI-assisted development (including AI code generation) and the software supply chain.

At the highest level, these guardrails can be sorted into four main categories:

• Governance and ownership

• Policy enforcement in developer workflows

• Software supply chain protection

• Auditability and traceability

Organizations need to establish who sets policy, who enforces it and who has authority to approve exceptions and escalations.

The policies should clearly define responsibilities for security, engineering, risk and compliance, and legal teams. Security typically defines secure coding standards and functional requirements. Engineering owns delivery software that meets the standards and for remediation when needed; risk and compliance owns regulatory filings and audits, and so on.

The advent of AI-assisted development requires guardrails that

• specify which AI coding assistants, models, agents and other AI tools are approved for use
  
  
• clearly identify which user or customer data (including login credentials) and regulated or sensitive information those tools are authorized to access or process
  
  
• set identity and permissions for AI agents, and what agents can and can’t do without human approval

Guardrails should also hold AI-assisted development accountable for security, by proscribing and mandating the tracking vulnerabilities and remediation costs of AI-assisted code compared to code written by humans.

Enforcement of policy and secure coding standards—baselines for code quality including authentication, cryptography, identity and access management, secrets management and more—must shift left to be baked into the developer workflow rather than serving as separate security requirements to be tacked on later.

Secure coding practices, approval requirements for high-risk changes and human review where appropriate can be embedded directly into repositories, pull requests and CI/CD pipelines.

In AI-assisted development workflows, these standards and other requirements must be available to the AI tools as the code is being generated.

• Layered pipeline guardrails use a defense-in-depth security architecture to inspect, sanitize and validate data at multiple distinct interception points—primarily at the input and output boundaries, as well as during execution.
   

• Input guardrails evaluate user prompts and retrieved context before model inference happens. Examples include scans for prompt injections, scrubbing of personally identifiable information, schema and semantic validation.
   

• Guardrails at execution monitor what the agent is doing while it operates. Gates restrict which functions or APIs an agent can call. Hard ceilings can be placed on spending, tool call rates or loops to prevent runaway behaviors. Output guardrails can check for model hallucinations and bias, and enforce schema.

The objective of these measures is to make secure development and code behavior the path of least resistance, and make policy enforcement an automatic part of the software delivery process.

Much of modern software is composed of code and components an organization’s development team did not create. AI-assisted development only adds to the potential pool of outside components.

Guardrails should establish:

• Controls governing which third-party components can be used;

• Artifact provenance—tamperproof evidence of where and by whom each software artifact was built;
   

• Software bill of materials (SBOM) generation for every release;
   

• Open-source and artifact governance to ensure that component licensing, support, and patching are managed properly.

Controls should take a zero-trust posture toward unverified components sourced in by AI-generated code and trigger the same scanning and review as code written by humans. The goal is to protect against unvetted components, hallucinated dependencies and other conditions that expand the attack surface, as well as plagiarized or unlicensed intellectual property that can raise the organization’s risk profile.

Finally, organizations need security audits and traceability across the development lifecycle. It should be possible to reconstruct how a significant change came about. To this end, organizations need to maintain sufficient logs to support governance, demonstrate compliance and establish accountability.

Application security posture management (ASPM) can provide a centralized view of security findings, application risk, dependencies, vulnerabilities, policies and remediation activity across development and security tools. That visibility can help security teams correlate findings and policy violations across the large volume of changes generated by agents.

The key to operationalizing guardrails without slowing delivery is to prioritize high-risk applications and workflows, versus applying a uniform scrutiny across every application and process. A practical rollout can follow these four steps:

1. Risk assessment: Take a risk-based inventory of AI-assisted development, existing SDLC controls, agent capabilities and high-risk applications.

2. Automate controls into delivery workflows according to risk: Integrate guardrails into repositories, development environments, CI/CD and existing security tooling.

3. Capture audit evidence automatically: Record the information needed to demonstrate compliance and reconstruct consequential development activity.

4. Review, measure and refine: Monitor security outcomes, developer experience, exception rates and emerging agent capabilities, then adjust policies accordingly.

Industry standard security frameworks can help. The two most popular frameworks, often used together—include

• NIST SSDF (SP-800-218). Published and maintained by the National Institute of Standards and Technology (NIST), the Secure Software Development Framework (SDFF) outlines high-level software security requirements and best practices organized into four disciplines or action areas: Prepare the organization (PO), Protect the software (PS), Produce well-secured software (PW) and Respond to vulnerabilities (RV). Special Publication (SP) 800-218 outlines the specific practices, tasks and evidence needed to prove practices are being followed. (Because SDDF SP-800-218 is the baseline behind federal software security attestation requirements, it doubles as a compliance framework.)
   

• OWASP SAMM. Published by the Open Worldwide Application Security Project (OWASP), the Software Assurance Maturity Model (SAMM) is an open-source framework for scoring secure development maturity in five (5) key areas—governance, design, implementation, verification and operations—and determining what actions to take next.

Organizations can use NIST SSDF as a directory of controls on which to base guardrails and meet compliance objectives, and OWASP SAMM for prioritizing implementation based on current risk state in each area.

Guardrails are only useful if organizations can demonstrate that they are improving SDLC security. Leadership should therefore measure both security outcomes and operational performance together.

Useful indicators include policy compliance rates, critical vulnerability escape rates, time to remediate security findings and the percentage of releases with complete control evidence. Dependency risk trends can reveal whether software supply chain exposure is increasing or decreasing, while exception volume and age can show where policies may be creating friction or where teams are routinely operating outside established controls.

Organizations can track delivery metrics as well, and if security controls slow down release cycles, or if teams have to frequently request exceptions, it might indicate that controls are poorly calibrated. But when compliance is strong and delivery metrics are improving, it implies that guardrails are doing their job rather than introducing unnecessary friction.

Leadership can use these metrics to determine whether security investments are reducing the likelihood of data breaches and the business impact of insecure changes reaching production, while maintaining the organization’s ability to deliver software quickly.