Security tools detect issues. Security systems prevent them. That distinction — between bolting on scanners and building controls into the infrastructure developers already use — is where most product security programs plateau. The tools are present, the findings pile up, but the fundamental gaps remain because the controls were never embedded into the systems themselves.
Neelu Tripathy, a product security leader with deep experience across offensive and defensive security in both enterprise and startup environments, joins this episode to share how security teams can shift from piecemeal tool adoption to building systems that scale. The conversation covers embedding security into developer platforms, calibrating product security for engineering velocity, and the emerging controls required for agentic development.
You can read the complete transcript of the episode here >
Why Tools Alone Do Not Prevent Breaches
Organizations invest in SAST, SCA, DAST, secret scanning, and cloud security posture management — yet breaches continue. The reason is not that the tools fail to detect issues. The problem is what happens after detection:
- Thousands of findings overwhelm developers. A dependency scan on a large retail application can return thousands of vulnerabilities. Developers lack the context to determine which are reachable, exploitable, or already mitigated by network controls.
- False positives erode trust. When security teams push hundreds of uncontextualized findings into sprints, developers learn to deprioritize them. The signal-to-noise ratio breaks down.
- Controls are not embedded in systems. A scanner that runs in the pipeline is a checkpoint. A control built into the platform — a secure golden image, an internal artifactory with vetted dependencies, an MCP server registry with pre-approved tools — is a system that prevents issues from being introduced in the first place.
Neelu’s framing: a control is worth a thousand attacks. Focus on building controls into the infrastructure rather than relying solely on detection tools that surface issues after the fact. The tools have their place, but they are not a substitute for systemic security.
Build Systems, Not Just Pipelines
The gap in most product security programs is not budget or headcount — it is strategic thinking. Security teams spend their time tactically (this sprint, this release, this finding) without allocating dedicated time to build systems that prevent entire categories of issues at scale.
What “building systems” means in practice:
- Embed security in concentrated places of engineering power. Identify the platforms, registries, artifactories, and shared infrastructure that all developers touch. Put controls there — one investment impacts thousands of developers.
- Package security for consumption. Instead of handing developers a list of issues, provide a secure baseline they can adopt. A golden image with security controls baked in. A Dependabot/Renovate-style PR that upgrades vulnerable dependencies automatically. A pre-configured IDE plugin that catches issues during coding.
- Automate correlation, not just detection. Traditional pipeline scanning runs tools in isolation — SAST, SCA, secret scanning each produce separate result sets. The value multiplier is a correlation module (powered by AI) that connects findings across tools: this dependency was pulled from a public source instead of the internal artifactory; this secret was committed alongside a change to a production configuration; this vulnerability is reachable through this specific code path.
This is not about eliminating security engineers. It is about ensuring their time is spent on complex problems rather than triaging noise that a well-designed system would have prevented.
Using AI Across the Product Security Lifecycle
AI is not a single-purpose tool for security teams. Neelu identifies multiple application points across the product security lifecycle:
- Scripting and automation: Attack chain scripts for recon, OSINT, fingerprinting, and the entire offensive lifecycle can be generated and maintained faster using AI. Security engineering teams (not just pen testers) benefit from AI-assisted development of internal tools.
- Front-end and SRE work: Security organizations that need dashboards, deployment automation, or infrastructure provisioning can use AI to handle work that previously required specialist developers.
- Correlation and triage: AI-powered correlation modules can connect findings from multiple pipeline tools on the fly — identifying that a flagged dependency came from an external source when an internal alternative exists, or generating a PR with the fix automatically.
- Playbook automation: Incident response playbooks, especially the initial investigation and triage phases, can be automated using AI — handling the data collection and initial analysis before a human makes the response decision.
- Policy translation: Organizational compliance requirements can be translated into OPA policies, IDE guardrails, or pipeline rules using AI — turning abstract controls into enforceable code.
The line Neelu draws: AI can handle primary tasks (not just mundane ones) up to the point where human judgment is required for high-impact decisions. The human in the loop is still necessary for response actions with blast radius.
Calibrating Product Security for Engineering Velocity
Time is currency in development. Engineering teams operating at seventy to eighty story points per week cannot absorb security overhead that introduces friction without proportional risk reduction. In agentic development, where AI agents are the primary code producers and humans are the bottleneck, this constraint becomes even tighter.
Neelu’s calibration framework:
- Shift security to the IDE. Basic guardrails and baseline checks at the code-writing stage — before anything hits the pipeline. With coding agents and AI-powered IDEs, these checks run as the code is generated, reducing the volume of findings that surface later in the build.
- Invest in the pipeline correlation layer. Rather than blocking builds on raw findings (which overwhelms developers), implement intelligent correlation that surfaces only actionable items — reachable vulnerabilities, exploitable paths, secrets with production access.
- Provide packaged security rather than findings. Secure golden images, pre-vetted dependency sources, generated PRs with fixes, and pre-configured security baselines. The developer’s interaction with security should be “review and accept” rather than “investigate and fix from scratch.”
The mindset shift: security teams should measure success not by findings generated but by issues prevented without developer intervention.
Securing Agentic Development: The New Controls
Beyond traditional shift-left security, agentic development introduces entirely new components that require specific security controls:
- Agent registry and identification. Just as dependencies are tracked and vetted, agents must be registered, identified, and traceable. If something goes wrong in production, you need to trace it back to which agent made which change and who authorized it.
- MCP server scanning. MCP servers should be treated like dependencies — vetted on every import, scanned for vulnerabilities, and sourced from approved registries rather than arbitrary open-source marketplaces. The AI supply chain requires the same rigor as the traditional software supply chain.
- Agentic gateways and LLM gateways. Traffic controls for agent-to-agent communication (A2A protocol), agent-to-LLM communication, and agent-to-infrastructure communication. What data flows where, what actions are permitted, what requires human approval.
- Agent runtime isolation. Agents executing instructions should run in sandboxed, ephemeral environments — containerized, isolated, and destroyed after execution. No persistent state that could be compromised across sessions.
- Context management security. Context (memory, conversation state, retrieved data) needs its own security model — identification, tracing, access control, and lifecycle management separate from traditional data security.
These controls are not future considerations. Teams doing agentic development today need them now, because the threat surface exists the moment an agent has access to production infrastructure.
How Product Security Has Evolved — Layer by Layer
Neelu traces the evolution of product security through a pattern: each technology wave gets productized layer by layer.
- Network layer: Firewalls, IDS/IPS — the perimeter era. Productized and mature.
- Application layer: Web application firewalls, SAST, DAST — the AppSec era. Productized and well-understood.
- Cloud and infrastructure layer: CSPM, CWPP, CIEM — the cloud security era. Increasingly automated.
- AI and agentic layer: Agent registries, MCP scanning, LLM gateways, context security — the current frontier. Early-stage, with controls still being defined.
The cautionary note: you cannot have an ASPM or CSPM and assume your domain is secure. Products cover specific layers; real security requires foundational controls that span across layers and evolve as technology changes.
Related Resources
- Securing the SDLC in the AI Era
- AI in AppSec: A Paradigm Shift
- Application Security: Beyond Tools — People, Process, Governance
- Scaling AppSec with Secure-by-Default Frameworks
- What is Shift-Left Security?
- What is Agentic AI Security?
- What is Model Context Protocol (MCP)?
- What is Software Composition Analysis (SCA)?
