When AI Finds a Way In: VulnSign and the Future of Autonomous Pentesting

Five targets. One instruction. Less than ten minutes.

VulnSign identified a vulnerability in an application widely used across Turkish government institutions and began uncovering a potential attack chain extending toward some of Türkiye's most critical government infrastructure.

The entire experiment took approximately 5–10 minutes.

I stopped the test before discovering how far the chain could actually go.

But to understand why this experience surprised me, we need to go back about two years.

Two years ago, I called it Prompt Reverse(Shell) Engineering

With more than 25 years of experience in cybersecurity, and as one of Türkiye's earliest ethical hackers, I've witnessed several generations of security technologies.

Yet the recent OpenAI–Hugging Face incident brought back a particularly interesting memory.

While everyone was talking about AI agents escaping sandboxes and compromising infrastructure, I couldn't help smiling. :D

Because approximately two years earlier, while experimenting with ChatGPT, I had discovered something remarkably similar.

And I wasn't simply making HTTP requests or triggering outbound network connections.

I managed to make the virtual machines running ChatGPT's sandbox environments establish actual, command-capable shell sessions with a remote server on my own network.

These were not ordinary callbacks, DNS lookups, or network connectivity tests.

The sandbox instances established shell connections to my external infrastructure, remained connected, and waited for commands that I could execute remotely.

At first, it involved a single virtual machine.

Then the experiment escalated.

Eventually, hundreds of OpenAI-hosted sandbox instances were simultaneously connected to my infrastructure, maintaining remote shell sessions and waiting for instructions.

What began as prompt manipulation had effectively evolved into a remotely controllable, botnet-like architecture composed of ChatGPT's own sandbox environments.

And all of this was triggered through prompts.

No traditional exploitation framework. No direct access to the underlying infrastructure.

Just prompts that caused the execution environments to behave in ways I could control remotely.

I gave this technique a name:

Prompt Reverse(Shell) Engineering.

I also recorded the experiment. The video demonstration below shows the behavior I observed.

[Video demonstration]

When I reported the behavior to OpenAI, the response I received was essentially:

"This is not a security vulnerability. It works this way by design."

That was approximately two years ago.

Today, autonomous agents escaping execution boundaries, establishing unexpected communication channels, and gaining remote command execution capabilities have become major topics in AI security research.

The irony is difficult to ignore.

What was once dismissed as "by design" is now at the center of the AI security conversation.

But the more interesting part of this story is what happened next.

What happened when I gave VulnSign one instruction?

Recently, I decided to evaluate the real-world capabilities of the local AI model available with VulnSign Enterprise.

Not with a carefully prepared demonstration.

Not with a synthetic benchmark.

With a short experiment against real-world, publicly accessible infrastructure.

The entire test lasted approximately 5–10 minutes.

I gave VulnSign a single instruction:

"Start a security scan against five randomly selected government websites."

What followed was largely automated.

VulnSign retrieved candidate targets from its internal database, and the AI selected and grouped them.

It identified their underlying technology stacks, generated target-specific scanning profiles and policies, and launched five concurrent scans.

Because crawling and active vulnerability testing run simultaneously, the platform does not need to wait until the entire application has been discovered before beginning its security analysis.

During the scan, VulnSign identified an XML External Entity (XXE) vulnerability in an application shared by numerous Turkish public institutions.

The autonomous AI then began investigating its impact.

It analyzed the surrounding server and service architecture, correlated backend APIs, and started identifying relationships between systems.

Within minutes, the emerging evidence suggested that the potential impact might extend beyond the initially vulnerable application, possibly reaching infrastructure associated with government ministries.

This was not a verified end-to-end compromise of those systems. It was an emerging attack path whose full extent had not yet been established.

And that was precisely why I stopped.

I terminated the scan rather than allowing the autonomous process to continue exploring increasingly sensitive infrastructure.

I subsequently contacted the relevant company and disclosed the finding and its technical details by email.

Following my long-standing professional practice, I did not pursue a CVE registration.

For security reasons, I will not disclose the affected institutions, application identifiers, or underlying infrastructure details.

The XXE vulnerability wasn't what surprised me

XXE is nothing new.

We've understood this vulnerability class for decades.

Discovering another XXE vulnerability is not, by itself, a technological breakthrough.

What surprised me was what happened after the first vulnerability was found.

Within minutes, a locally running AI model had:

• Analyzed the attack surface and identified target technologies.
• Discovered a vulnerability and validated its immediate impact.
• Investigated relationships between servers and services.
• Correlated backend APIs.
• Identified possible paths beyond the original application.
• Used the initial vulnerability as the starting point for a broader, stateful attack chain.
• Adapted its analytical strategy based on the evidence it discovered.

This is fundamentally different from simply sending thousands of predefined payloads and recording their responses.

Two years ago, the question was:

"Can AI escape its sandbox?"

Today, the question has changed:

"How far could an unrestricted AI-powered hacking tool go if nobody stopped it?"

I didn't discover the complete answer during my VulnSign experiment.

Because I shut it down before the tenth minute. :D

And perhaps that is the most revealing part of the experience.

The real intelligence is in the architecture, not just the model

There is something important I want to clarify.

VulnSign's advantage is not that its local AI model is magically more intelligent than frontier models developed by OpenAI, Anthropic, Google, or other AI companies.

It isn't.

The difference lies in how the model is trained, the quality of its domain-specific knowledge, the tools it can operate, and, most importantly, the feedback loop connecting reasoning to actual security testing.

A powerful general-purpose language model is not automatically a powerful penetration testing system.

For VulnSign, I approach the architecture as three complementary capabilities.

Deterministic scanning provides the muscle

Reliable vulnerability detection rules, specialized scanners, protocol analysis, payload execution, and evidence collection provide the technical foundation.

AI provides the intelligence

It interprets evidence, understands relationships between vulnerabilities, adapts testing strategies, generates context-aware payloads, and determines which investigation paths deserve further attention.

Human expertise provides the judgment

The security professional establishes the objectives, defines the boundaries, evaluates the consequences, and determines when testing must stop.

Having provided some of Türkiye's largest online brands with their first cybersecurity consulting services, I know how important this distinction is.

Automation alone has never been enough.

And neither has intelligence without context.

The real value emerges when deterministic execution, AI reasoning, and human judgment operate together.

From isolated vulnerabilities to stateful attack chains

Consider an older Windows/IIS application.

During conventional crawling, an endpoint may remain completely invisible.

The crawler cannot discover it because the application does not expose a direct link.

A conventional DAST scanner may never test it.

But VulnSign is not limited to the URLs discovered by its crawler.

Its testing workflow can connect multiple discovery and exploitation techniques into one continuous investigation.

Stage 1 — IIS Tilde Enumeration

Identify evidence of hidden resources through IIS-specific behavior.

Stage 2 — Hidden Path Discovery

Use the discovered signals to investigate previously unknown application paths.

Stage 3 — Hidden Variable Discovery

Identify parameters and inputs associated with those newly discovered endpoints.

Stage 4 — SQL Injection Analysis

Pass the discovered inputs to the appropriate active scanning rules and determine whether an SQL injection vulnerability exists.

Stage 5 — Controlled Exploitation

If SQL injection is confirmed, assess the database context, available privileges, and potential impact.

For example, a highly privileged SQL Server context may make functionality such as xp_cmdshell relevant to impact analysis, subject to the authorization and safety boundaries of the test.

The complete workflow can be represented as:

Endpoint Discovery → Parameter Discovery → Injection Analysis → Controlled Exploitation

The important part isn't any individual technique.

Every experienced penetration tester already knows these techniques.

The important part is connecting them intelligently.

Each discovery produces evidence that informs the next decision.

An endpoint becomes a parameter.

A parameter becomes a vulnerability.

A vulnerability becomes a potential route to another system.

Several seemingly unrelated security signals become one stateful attack chain.

This is where AI-assisted security testing begins to resemble the reasoning process of an experienced penetration tester.

What makes VulnSign AI-native?

Adding a chatbot to an existing vulnerability scanner does not make it AI-native.

Neither does summarizing scan results with an LLM.

In VulnSign, AI can go significantly further.

It can generate context-specific JavaScript to program and extend the DAST engine during an investigation.

It can create custom payloads based on the application's behavior, adapt testing logic to the current scenario, and use the results to guide subsequent analysis.

This changes the relationship between the AI model and the scanning engine.

Instead of treating the model as a passive assistant that explains findings, VulnSign can use it as an active reasoning component within the testing workflow.

The deterministic engine continues to perform the actual security checks, while AI determines how to adapt and combine them.

That is what I mean by AI-native DAST.

Not AI as a marketing feature.

AI as an integral part of the testing architecture.

Frontier models vs. specialized local AI

The OpenAI–Hugging Face incident demonstrates the sophisticated capabilities that frontier AI models can exhibit when connected to powerful tools and agent infrastructures.

Research and investigation at that scale can also require enormous computational resources.

But our claim is not:

"Frontier models cannot perform advanced offensive security reasoning."

They clearly can.

Our argument is different.

A specialized security architecture can achieve sophisticated vulnerability analysis and attack-chain reasoning without requiring a massive general-purpose AI agent infrastructure.

VulnSign combines domain-specific knowledge, deterministic scanning rules, structured findings, specialized tools, and a single local AI model to perform tasks that would otherwise require extensive agent orchestration.

The objective is not to reproduce a frontier model's general intelligence.

It is to use the available intelligence efficiently within a well-designed cybersecurity system.

And there are practical advantages to this approach.

Organizations can operate the AI locally, maintain tighter control over sensitive testing data, reduce dependency on external inference services, and design predictable security boundaries around autonomous operations.

For enterprise environments, those considerations can be just as important as detection accuracy.

The future of DAST is not about sending more payloads

Traditional DAST scanners are excellent at executing predefined security checks.

But modern applications rarely behave exactly as their scanning rules expect.

A parameter may reject certain characters.

An endpoint may require a specific application state.

A vulnerability may only become accessible after discovering a hidden path, identifying an undocumented parameter, or reproducing a sequence of application interactions.

Simply increasing the number of payloads does not solve these problems.

A more intelligent approach requires understanding the target's behavior and adjusting the testing strategy accordingly.

This is one of the architectural principles behind VulnSign.

Deterministic scanning provides repeatability and reliable evidence.

AI analyzes that evidence and adapts the testing process.

The resulting feedback loop allows the platform to move beyond isolated vulnerability detection toward contextual, stateful security analysis.

The future of DAST is not about sending more payloads. It is about understanding what each response means and deciding what to do next.

The question has changed

Two years ago, I was experimenting with ways to make ChatGPT communicate beyond its intended execution environment.

At the time, the behavior was described to me as something that worked by design.

Today, agent containment, unintended communication channels, and autonomous exploitation are major areas of AI security research.

Meanwhile, my own work has moved in another direction.

Instead of merely observing what AI systems might be capable of, I am building a platform that combines AI reasoning with practical application security testing.

The recent VulnSign experiment reinforced something I have believed for a long time:

A vulnerability scanner identifies weaknesses.

A penetration tester understands how those weaknesses relate to one another.

An AI-native security platform should bring those capabilities together while keeping the human operator in control.

In the past, we asked:

"Can AI discover vulnerabilities?"

Now we need to ask:

"Once AI discovers a vulnerability, how far can it go on its own?"

During my experiment, VulnSign began answering that question in less than ten minutes.

I chose not to find out how much further it could go.

And perhaps that is the most important lesson of all.

The next generation of offensive security is not defined solely by what AI can discover. It is defined by how intelligently it can connect discoveries, how responsibly it can act on them, and how effectively humans can control the process.

That is the future I am building with VulnSign.

From Vuln to Sign — detect, validate, fix, and verify vulnerabilities with AI.