Agentic pentesting exposes SQL injection gaps scanners miss

At a glance

What this is: Terra describes how an AI agent found an unauthenticated SQL injection that scanners and manual testers missed, then proved it could expose live customer endpoint records.

Why it matters: It matters because application security teams need to prioritise proof of exploitability and business impact, not just tool output, especially where exposed data could affect downstream operations and trust.

Context

SQL injection remains a control failure in application security because the issue is rarely only the query flaw itself. The real governance gap appears when testing fails to prove whether the flaw can reach live data, cross a trust boundary, or create business impact in the specific environment.

This case also has a strong identity and access angle. The vulnerable endpoint was accessible without authentication, which means the exposure path bypassed access control entirely and converted an application flaw into a data-access problem. In practice, that is where scanner-centric testing often falls short: it can flag syntax risk without demonstrating whether a real attacker could reach sensitive records.

Key questions

Q: What breaks when a public API can execute SQL before authentication?

A: The control boundary breaks at the point where unauthenticated input reaches database logic. That turns a normal application flaw into an exposure path for live records, metadata, or infrastructure data. The risk is not just injection syntax, but the ability to cross from anonymous access into data that should have been protected by identity and authorization controls.

Q: Why do some SQL injection flaws become much more serious than others?

A: They become more serious when the vulnerable path reaches production data, customer records, or operational systems that have real business value. A low-level code flaw turns into a high-impact issue once it can expose something attackers can use for mapping, fraud, or downstream compromise. Context, not just severity labels, determines the real risk.

Q: How should security teams prove that a scanner finding is exploitable in a real environment?

A: Teams should validate whether the finding can be turned into an actual attack path, not just a detection result. That means checking prerequisite libraries, runtime protections, classpath exposure, and reachable interfaces, then attempting controlled proof of impact in a safe test window. The goal is to distinguish theoretical vulnerability from practical risk so remediation priorities reflect attacker feasibility.

Q: Should application teams prioritise endpoint exposure or query sanitisation first?

A: They should prioritise the exposed path first when unauthenticated access can reach sensitive records, because exposure determines whether the flaw is reachable at all. Query sanitisation still matters, but removing or protecting the public route immediately reduces attack surface and limits blast radius while deeper code fixes are prepared.

Technical breakdown

Unauthenticated SQL injection in a public API path

SQL injection occurs when untrusted input is interpreted as part of a database query instead of data. In this case, the agent found a public API endpoint that accepted a query parameter and behaved like it was passing attacker input into SQL execution. The important technical detail is not just that injection was possible, but that the endpoint was reachable before authentication. That means the attack surface sat outside identity controls, so the application itself had to absorb the risk. When a public API exposes query-driven behaviour, scanners often stop at pattern matching and miss the exploit path that a researcher can actually chain into data access.

Practical implication: treat unauthenticated query-capable endpoints as high-risk until they are proven unable to reach sensitive database logic.

Proof of concept matters more than signatures

The article shows a useful distinction between detection and validation. Traditional scanners can identify suspicious input handling, but they often cannot generate a working exploit, interpret the server response, and prove what data becomes reachable. Terra’s agent did the full chain: observed the anomaly, crafted a payload, confirmed table enumeration, and then tested whether customer records were exposed. That is what converts a suspected vulnerability into a risk decision. The technical lesson is that exploitability is contextual. A flaw that seems routine in isolation becomes critical when it reaches production records, operational infrastructure, or other sensitive assets.

Practical implication: require exploit validation for high-risk findings, not just scanner confirmation or severity scoring.

Business context turns data exposure into operational risk

The article’s strongest point is that the exposed data was not generic test output. The endpoint could reveal live customer endpoint records, which in this environment represented operational infrastructure across multiple customers. That shifts the issue from a classic application bug to a governance problem about blast radius. SQL injection here was not simply a confidentiality issue. It was a route to mapping environments, targeting customer estates, and enabling downstream attacks. For security teams, that is why risk context must sit alongside technical findings. The same vulnerability can carry very different consequences depending on what the data represents and how it connects to the rest of the business.

Practical implication: map vulnerable application paths to the business assets they can expose before deciding remediation priority.

Threat narrative

Attacker objective: The attacker’s objective would be to extract live customer infrastructure data and use it to target downstream environments or operations.

1. Entry occurred through an unauthenticated public API endpoint that accepted query input and allowed attacker-controlled SQL behaviour.
2. The agent confirmed the injection by extracting table names, showing that the database interaction went beyond a harmless error condition.
3. Escalation occurred when the same path was used to retrieve live customer endpoint records without authentication.
4. The likely impact was exposure of operational infrastructure data that could support environment mapping and follow-on attacks.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exploitability proof is the missing layer in many application security programmes. Scanner output can show that an input field is suspicious, but it does not always prove whether the flaw reaches live data or a meaningful business asset. This case shows that the decision point is not whether a vulnerability exists in theory, but whether it can be turned into working access in the target environment. Practitioners should treat exploit validation as part of risk governance, not as an optional research exercise.

Unauthenticated application paths create a governance problem before they create a database problem. Once a public endpoint can influence query execution, identity controls no longer contain the blast radius. That makes the issue especially relevant to IAM and API governance because the attack bypasses authentication rather than abusing it. The practical lesson is to review which externally reachable functions can reach sensitive backend records without any identity check.

Business-context testing is now a requirement for high-value applications. The same SQL injection severity can mean very different things depending on whether the reachable data is a test table, customer metadata, or production infrastructure records. This is a useful model for continuous pentesting because it aligns technical testing with operational impact. Security teams should prioritise testing that demonstrates consequence, not just defect existence.

Agentic testing changes the economics of validation, not the underlying control failure. AI agents can accelerate discovery and proof-of-concept generation, but the real issue remains the application design gap that allowed unauthenticated query access. In practice, that means organisations should not let automation replace governance. They should use it to raise the quality of validation around high-risk endpoints and to shorten the time between detection and remediation.

SQL injection here is a data-access and trust-boundary failure, not just an AppSec defect. When live customer endpoint records can be exposed through an unauthenticated path, the issue touches confidentiality, operational resilience, and downstream customer trust at the same time. The broader implication is that application security and identity governance need to share a view of which services can reach which records, and under what conditions.

From our research library:

• Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and insufficient risk controls.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Business-context validation is becoming the differentiator in application testing. A scanner can tell you that an input is malformed, but it cannot reliably tell you whether the flaw reaches live customer data or operational infrastructure. Teams that still rank findings by vulnerability class alone will keep missing the cases where the consequence is what changes the priority.

AI agents change the speed of proof, not the need for control. The real value is not that an agent can find more issues in isolation, but that it can accelerate the path from suspicious behaviour to demonstrable impact. That matters because systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.

For practitioners

• Audit unauthenticated API endpoints for query execution paths Inventory externally reachable endpoints that accept query or filter parameters, then verify whether any of them can influence database logic before authentication is enforced.
• Require exploit proof for high-severity findings For application vulnerabilities that touch customer or operational data, require a working proof of exploitability and a mapped business impact before assigning remediation priority.
• Tie application findings to exposed business assets Document which records, systems, or customer environments a vulnerable path can expose so remediation reflects the actual consequence rather than the scanner label.
• Review public APIs for identity bypass paths Check whether public APIs can disclose or modify sensitive records without an identity boundary, and add authentication or authorization controls where the path is currently open.
• Use continuous testing on high-risk application paths Focus repeated validation on internet-facing endpoints that can reach production data, especially where a single flaw could expose many customers or environments.

Key takeaways

• The core issue was not a routine SQL injection alert, but an unauthenticated path that could reach live customer endpoint records.
• The article shows why exploit validation and business context matter when deciding whether a vulnerability is truly high risk.
• Teams should focus remediation on exposed public APIs that can touch sensitive backend data before attackers can chain them into broader impact.

Key terms

• SQL Injection: SQL injection is a flaw where untrusted input is interpreted as part of a database query. In practice, it lets an attacker read, change, or delete data by manipulating the application’s request handling rather than by logging in with valid credentials.
• Unauthenticated Management Endpoint: A service interface that allows operational actions without verifying identity first. In practice, this is a privileged path exposed as if it were public. When such an endpoint can create files, change state, or reach internal systems, it becomes a direct control-plane risk rather than a simple application bug.
• Exploitability proof: Exploitability proof is evidence that a vulnerability can or cannot be turned into a working attack in a specific environment. It goes beyond severity scores by testing real paths, privileges, configurations, and dependencies that determine whether an attacker can achieve impact.
• Business Context Aware Testing: Business context aware testing adapts security validation to the real function and risk of an application. It considers what the system does, what data it protects, and what harm a compromise could cause. This helps teams prioritize findings and design tests that reflect actual operational impact.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.