AI can genuinely improve security work. But it can also create a new layer of confident summaries, duplicated processes and security-flavoured noise.
AI was sold as the technology that would simplify work and cut through the clutter. So naturally, some businesses responded with AI councils, AI frameworks, AI workflows, AI maturity models, AI governance layers—and enough new acronyms to train another model. Yes, responsible governance matters. But for God’s sake, AI was supposed to reduce bureaucracy—not become its newest department.
The difference is not the model. The difference is the workflow around it. “The model is not the control.”
Here is how I currently see AI across the major security domains.
SAST: A contextual reviewer, not the source of truth
AI is useful for reviewing static-analysis findings.
It can help explain a finding in business language, identify likely false positives, connect the issue to application context and suggest remediation.
That is valuable because the difficult part is often not identifying a suspicious code pattern. It is understanding whether that pattern matters in the real application.
The slop begins when an entire repository is handed to a model and the model is expected to replace repeatable analysis.
A model may produce a convincing review while missing an earlier finding, overlooking a changed assumption or reaching a different conclusion because the prompt, context or model version changed.
“A review that discovers something new but forgets what was already known is not autonomous security.”
Deterministic analysis, baselines, regression checks and historical findings still matter. AI should add reasoning around that process—not replace the process itself.
DAST: Not dead, but being demoted
The claim that DAST is dead is too strong.
Dynamic testing still has a role because some security properties only become visible when an application is running: authentication flows, session behaviour, deployment configuration, runtime input handling and server-side interactions.
However, traditional broad DAST is losing strategic importance.
Modern environments provide better visibility into APIs, cloud configuration, identity, exposed services and runtime posture. API security has also expanded beyond endpoint scanning into authorization, sensitive business flows, inventory and abuse cases. The OWASP API Security Top 10 reflects that shift.
The problem is not that every CSP, CORS or browser-level observation is invalid. Some can represent real risk.
The problem is reporting technically correct observations without enough context about exploitability, affected data, trust boundaries or business impact.
“A technically correct observation is not automatically a meaningful security finding.”
DAST is probably moving toward a narrower role: targeted runtime validation, authenticated workflow testing, API abuse testing and regression testing for previously confirmed issues.
Not dead.
Just no longer the centre of gravity.
VAPT: AI as a force multiplier, not an autonomous pentester
AI can be extremely useful in vulnerability assessment and penetration testing.
It can help pentesters understand source code, architecture, configuration, workflows, historical findings and business rules before testing begins.
It can generate attack hypotheses, expand test cases, prepare evidence, draft reports and create proof-of-concept material.
But the final determination of exploitability, impact and business risk still requires human validation.
“AI as a developer tool for pentesters: absolutely. AI as the pentester: not yet.”
An autonomous pentester would need to maintain attack hypotheses, understand application state, distinguish a blocked test from a secure control, validate exploitability safely and produce defensible evidence.
Generating a plausible attack narrative is not the same as proving a vulnerability.
SCA: Structure first, AI second
Software composition analysis is one of the areas where AI is often unnecessary.
If a repository is well structured, dependency manifests are reliable and package boundaries are clear, deterministic dependency analysis is usually the right answer.
Why ask AI to rediscover what the package manager and dependency graph can establish more reliably?
The situation changes when the repository contains multiple languages, nested modules, internal packages, embedded dependencies or inconsistent manifests.
AI can help perform repository reconnaissance, identify application boundaries and classify languages and frameworks.
But dependency identity, version mapping and vulnerability matching should remain machine-verifiable.
An important distinction:
“An SBOM is an inventory. SCA is the analysis of that inventory against vulnerability, licensing and policy data.”
AI may help create structure around a messy repository. It should not become the source of truth for dependency identity. CISA’s SBOM guidance is useful context here.
GRC: Useful for communication, insufficient for assurance
AI-generated dashboards and board-level summaries are a clear “yay.”
They can translate technical evidence into business language, highlight trends, identify ownership gaps and surface overdue actions.
But dashboards are outputs of governance. They are not governance themselves.
AI cannot establish control effectiveness simply by summarising policies or collecting attestations.
Assurance still requires evidence, scope, ownership, sampling, exceptions and judgment.
“A dashboard can compress evidence. It cannot manufacture assurance.”
Threat modelling: Better first drafts, not final decisions
AI can help identify assets, trust boundaries, abuse cases, attacker goals and overlooked scenarios.
It can also make threat modelling more iterative instead of a document created once and forgotten.
But the quality of the output depends on the quality of the business, architectural and operational context.
AI can help create the model.
It should not be the authority deciding whether the model is complete.
Cloud security: Helpful for prioritisation, not magic
Cloud environments are built on relatively standardised provider primitives, and modern cloud-security platforms already consolidate posture, identity, workload and runtime signals.
AI can help with prioritisation, runtime drift, anomaly detection, control mapping and communicating technical exposure to non-technical stakeholders.
But cloud security is still fundamentally about identity, access, network paths, data exposure, secrets, workloads and control-plane configuration.
“CNAPP is convergence, not correctness.”
AI cannot compensate for poor asset inventory, unclear ownership or a weak identity model.
Business logic and design flaws: The strongest “yay”
This is where AI may provide some of the greatest value.
Traditional scanners are good at identifying known technical patterns. They are much less effective at understanding whether application behaviour violates business intent.
AI can reason across user roles, entitlements, approval chains, state transitions, multi-tenant boundaries, pricing rules and operational workflows.
That makes it useful for identifying inconsistencies between what an application is supposed to do and what it actually allows users to do.
This is especially relevant to authorization flaws, abuse of sensitive business flows and design-level weaknesses. OWASP’s Business Logic Security guidance captures why these issues require more than pattern matching.
Human validation is still required.
But this is a genuinely strong use case.
SOC: Promising workflow, incomplete evidence
AI-assisted SOC workflows look promising.
The summaries are useful. Correlation is useful. Reducing repetitive analyst work is useful.
But a convincing explanation is not the same as a successful security outcome.
The metrics that matter are:
- Time to triage
- False-positive reduction
- Escalation precision
- Containment quality
- Analyst workload
- Detection coverage
- Missed-pattern recurrence
- Decision drift over time
A successful SOC copilot should be measured by what it changes operationally—not by how impressive its incident summary sounds.
Fine-tuning is not automatically the answer
Fine-tuning a model on every historical security report may sound like a competitive advantage.
Often, it is not.
Historical reports may contain inconsistent severity ratings, outdated assumptions, duplicated findings and analyst-specific preferences. Fine-tuning can preserve those weaknesses while making them harder to identify.
Fine-tuning may be useful for stable behaviour, organisational terminology, output formats and clearly defined task boundaries.
It is less suitable as a replacement for current application context.
For a specific application or workflow, it is often better to provide relevant evidence through structured context and retrieval, with provenance and clear boundaries.
“Use fine-tuning to shape behaviour. Use context to represent reality.”
The real differentiator is the harness
The model is not the architecture.
The real differentiator is the organisation’s ability to build standardised, repeatable workflows around it.
That means:
- Defining the workflow for each security domain
- Establishing what is in scope and out of scope
- Selecting the right analysis method for each application type
- Creating templates for APIs, microservices, source code, cloud environments and operational activities
- Preserving historical findings and validated decisions
- Defining expected outputs and evidence requirements
- Measuring accuracy, consistency, cost and result drift
The same model can perform very differently depending on the workflow surrounding it.
“The unit of AI automation is not the model. It is the workflow.”
The most interesting opportunity: building the engineering–security bridge
The most interesting use of AI in security may not be autonomous vulnerability discovery. It may be the bridge it creates between engineering and security.
For years, the two teams have often worked with different languages, priorities and definitions of risk.
Engineering sees tickets, deadlines, architecture and user impact.
Security sees attack paths, control gaps, exploitability and exposure.
Both may be looking at the same application—but not always at the same problem.
AI can help translate security findings into engineering context, connect them to business workflows and explain why an issue matters in the application’s real design.
It can also help security understand the constraints behind an engineering decision instead of treating every deviation from a control checklist as an equally urgent risk.
“The real promise of AI in security may be getting engineering and security to finally work from the same context.”
That does not mean AI replaces either team.
It means both teams can begin with the same evidence, the same application context and a shared understanding of the expected outcome.
The objective is not to create another AI council, framework or governance layer.
It is to reduce the distance between identifying a problem and solving the right problem.
That is where AI can move beyond automation and become organisational leverage.
The mature approach is not to ask AI to do everything. It is to template the security arsenal, then customise the use case on top of it.
That is where the real benefits appear:
- Faster analysis
- Better context
- More consistent outcomes
- Lower repetitive effort
- Predictable reporting
- Measurable ROI
The final question should not be:
“Can AI do security?”
It should be:
“Where can AI improve a defined security workflow without making the result less reliable?”
That is the difference between AI-enabled security and security slop.