Software engineering was built around a simple constraint: skilled human engineering capacity was scarce.
Writing code took time. Debugging took time. Creating tests took time. Reviewing changes took time. Specialist work moved between developers, QA, security, operations, and product because human attention was the limiting resource.
That constraint shaped much of the modern software development lifecycle: backlogs, Jira tickets, sprint planning, pull-request reviews, separate QA phases, security gates, bug stories, and release cycles. These were rational mechanisms for managing scarce human throughput and expensive handoffs.
Coding agents change that assumption.
The new bottleneck is increasingly not how quickly we can produce code.
It is whether we can clearly define what should exist, establish the constraints under which it should operate, and prove that the resulting system is correct and secure.
That changes secure software development fundamentally.
The interface to software is becoming intent
The important breakthrough in large language models is not autocomplete.
It is their ability to understand and act on human intent.
At its simplest, this gives us what has come to be called vibe coding:
Make this work.
Move that button.
Add an endpoint.
Fix this error.
That can be extraordinarily useful for exploration and prototyping.
But it is not a production security model.
Production software needs a stronger contract:
Intent → Plan → Change → Test → Repair → Prove
An agent should be able to understand a repository and its architecture, decompose the requested outcome, implement changes across multiple layers, test the result, identify failures, repair them, and continue until the defined constraints are satisfied.
The unit of work changes from:
“Write these lines of code.”
to:
“Deliver this outcome within these constraints.”
That distinction matters enormously for security.
The engineering discipline changes with it
This does not mean developers, security engineers, QA teams, DevOps engineers, or product people disappear.
It means the boundaries between those disciplines become less useful.
Developers increasingly define intent, architecture, and constraints while orchestrating agents.
QA moves toward executable acceptance criteria and continuous evaluation.
Security moves from late-stage review toward policy and automated verification throughout the development loop.
DevOps increasingly manages policy-driven systems capable of producing evidence and, eventually, performing controlled remediation.
The scarce skill becomes judgment: domain expertise, systems thinking, architecture, risk framing, and knowing what “good” actually looks like.
This is a much bigger change than simply producing code faster.
Manual code review cannot remain the primary security control
If an agent can modify dozens of files across an application in seconds, making a human read every generated line creates exactly the bottleneck the agent was introduced to remove.
Humans should still review code when appropriate. But line-by-line inspection cannot be the primary scalable control for machine-generated software.
Machines are better suited to repeatable questions:
- Did we commit a secret?
- Did we introduce a vulnerable dependency?
- Did we violate an infrastructure policy?
- Did the change create a known dangerous data flow?
- Are required tests present?
- Did the application’s externally reachable attack surface change?
Human attention should move toward questions where context and judgment matter:
- Did a trust boundary change?
- Is this authorization model correct?
- Should this user ever be allowed to perform this operation?
- Is sensitive information being retained appropriately?
- Is the residual risk acceptable?
- Should the product behave this way at all?
The goal is not to remove humans.
It is to stop spending expensive human judgment on work that machines can perform deterministically.
Production software needs a contract
The difference between vibe coding and secure agentic engineering can be reduced to five things:
Intent. Policy. Evidence. Independence. Feedback.
Intent defines the outcome and the non-negotiable constraints.
Policy turns those expectations into reusable rules.
Evidence requires the system to prove that those rules were satisfied.
Independence prevents the system that built something from being the only system asked whether it is correct.
Feedback continuously tests the software after it is merged and deployed.
That is the foundation of a secure agentic operating model.
“Looks right. Ship it.” is not enough.
Neither is:
“The agent said the task was complete.”
Completion and correctness are different things.
Give every coding agent a security constitution
Secure coding should start before generation.
Every repository should provide coding agents with persistent instructions defining how software in that environment is expected to behave.
These instructions might specify that:
- authorization is enforced server-side and denies by default;
- new endpoints are private unless explicitly approved as public;
- secrets must never be committed to source control;
- untrusted input must be validated;
- output must be encoded for its destination context;
- approved cryptographic mechanisms must be used;
- unnecessary dependencies should be avoided;
- negative authorization and tenancy tests must accompany sensitive changes;
- changes to trust boundaries require corresponding security-test and threat-model updates.
Think of this as the security constitution the agent reads every time it works.
But natural-language instructions alone are not enough.
They establish the rules.
The rest of the system has to enforce them.
Do not let the builder certify itself
Separation of duties still matters.
A builder agent has one primary objective:
Complete the requested change.
That makes it poorly positioned to be the only authority deciding whether the change is safe.
A stronger model uses three independent layers:
- Builder agent
- Optimized to create the outcome.
- Reviewer agent
- Optimized to find what the builder missed, ideally using different context or even a different model.
- Deterministic security tools
- SAST, SCA, secrets detection, configuration policy, tests, DAST, and other repeatable systems producing objective evidence.
Different objectives create different failure modes.
That diversity increases assurance.
The same principle applies to models themselves. Coding agents are uneven specialists. Some are fast and ambitious but skip edge cases. Others are slower and methodical. Some are particularly good at architecture or decomposition.
The right question is therefore not:
“Which model is best?”
It is:
“Which model is best for this task on our codebase, and what independent system should verify its work?”
Security needs to follow the software through the entire loop
Security cannot remain something that happens after development.
The secure agentic toolchain should operate across four layers.
- Before commit
- Secrets detection, SAST, SCA, infrastructure policy, linting, and unit tests.
- During build
- SBOM generation, container scanning, dependency policy, security tests, and artifact signing.
- In an ephemeral runtime
- DAST, API testing, authorization testing, BOLA/IDOR checks, fuzzing, unauthenticated-surface discovery, and testing of LLM-specific functionality.
- In production
- Attack-surface monitoring, configuration drift, runtime telemetry, threat intelligence, and continuous reassessment.
The operating principle should be straightforward:
Fail closed where the risk demands it. Auto-fix where confidence is high. Escalate uncertainty to humans.
The objective is not more gates.
It is stronger evidence with less ceremony.
Test behavior, not just code
This may be the most important shift.
Generated code can be clean, syntactically correct, thoroughly unit-tested—and still create a serious security vulnerability.
Imagine an endpoint:
GET /api/customers/1234It returns exactly the requested customer.
The code works.
The tests pass.
The important security question is not whether the endpoint returns Customer 1234 correctly.
It is:
Who is allowed to request Customer 1234?
That is why agentic development requires behavioral security testing.
Every build should increasingly be tested for:
- unauthenticated endpoint exposure;
- BOLA and IDOR;
- tenant-isolation failures;
- object- and function-level authorization;
- exposed administrative or debug interfaces;
- permissive CORS;
- privilege escalation;
- incorrectly scoped tokens;
- prompt injection and unsafe tool use in LLM-powered functionality.
The dangerous bug may not be code that fails.
It may be code that works too well.
Security findings should become feedback, not future work
The target operating model looks something like this:
Intent → Threat Model → Builder → Security Tools → Independent Reviewer → Attack Testing → Human Decision → Merge → Continuous Production Assessment
And then the loop starts again.
A failed test should not automatically become a Jira ticket for some future sprint.
When remediation is safe and deterministic, the agent should repair the problem immediately and rerun the validation.
Security becomes part of the agent’s definition of done.
This matters because the economics have changed.
When generating a fix was expensive, postponing it might have been rational.
When an agent can modify, test, and revalidate the software immediately, leaving a known defect for a future sprint can become artificial scarcity.
The goal shifts from:
Find more vulnerabilities.
to:
Prevent, validate, repair, and prove.
That is a much more useful security outcome.
AI applications require two security models
There is another mistake organizations should avoid.
Securing AI applications does not mean replacing traditional application security with AI security.
You now need both.
Traditional application-security requirements remain:
authentication, authorization, secrets, cryptography, dependency security, business logic, infrastructure configuration, logging, monitoring, resilience, and API security.
AI and agentic systems add another set of risks:
prompt injection, sensitive-data disclosure, unsafe output consumption, tool misuse, excessive agency, plugin and model supply-chain risks, and uncontrolled resource or cost consumption.
AI security is additive.
An application containing an LLM still has APIs.
It still has identities.
It still has data stores.
It still has permissions.
And now the model itself may also be capable of acting.
What security teams should build now
The security organization therefore has an opportunity to stop being primarily a review queue.
Its output should increasingly become reusable guardrails that every coding agent can consume.
That means building:
- Secure agent instructions
- A maintained security contract for each repository and technology stack.
- Policy as code
- Executable rules for identity, infrastructure, dependencies, sensitive data, and deployment.
- Pre-commit security services
- Fast checks and high-confidence remediation before generated code enters shared branches.
- Independent review agents
- Separate models whose objective is to find missing controls and unsafe behavior.
- Ephemeral attack testing
- Deploy every meaningful build into a temporary environment and attack its APIs, authorization model, unauthenticated surface, and important abuse cases.
- Continuous production assessment
- Continuously identify new exposures, configuration drift, vulnerable components, and changing threat context.
Security becomes an engineering platform rather than a queue developers must wait behind.
What engineering leaders should start leaving behind
We should stop measuring security maturity by how many manual review steps a change must survive.
We should stop automatically turning every fix into future backlog work when high-confidence remediation can happen now.
We should stop placing security exclusively at CI/CD after an agent has already made a large change.
We should not give autonomous coding agents broad production credentials simply because doing so is convenient.
And most importantly:
We should stop equating “the agent completed the task” with “the system is secure.”
Replace ceremony with evidence.
Replace late findings with continuous prevention and repair.
Autonomy should expand only as verification becomes stronger
Organizations do not need to jump directly from autocomplete to autonomous production changes.
There is a natural maturity path.
At the assistive stage, humans write and AI suggests.
At the agentic stage, AI implements bounded tasks under repository instructions and automated security gates.
At the governed stage, agents plan, build, repair, undergo independent review, and face ephemeral attack tests.
At the autonomous-with-guardrails stage, agents can remediate within policy while policy-as-code, risk-based human approval, and continuous production assessment keep them inside established boundaries.
The governing principle should remain:
Autonomy should expand only as verification becomes stronger.
That principle matters well beyond software development.
The more capable agents become, the less useful it is to ask whether we trust the model.
We should instead ask:
What can the system prove?
The new secure coding model
The future of secure software development is probably not humans learning to write secure code faster.
It is something different.
Humans define secure intent.
Agents generate and repair software.
Independent systems prove how the software behaves.
The destination is software that is:
Secure by construction. Verified continuously. Remediated at machine speed.
As code generation becomes cheaper, the value moves toward defining the system, establishing its boundaries, and producing evidence that the system stayed inside them.
Coding agents are not merely making the existing SDLC faster.
They give us an opportunity to rethink the SDLC itself.
And perhaps security’s biggest opportunity in this transition is not to build faster gates.
It is to stop being a gate.
Build the constraints. Build the verification. Build the feedback loops. Let machines do what machines are good at, and reserve human judgment for the decisions where it actually matters.
Outcomes, not outputs. Evidence, not ceremony. Security inside the loop.