Welcome to this week’s edition.

I've been following all these stories about AI agents hacking systems, discovering vulnerabilities and supposedly replacing security testers.

But I wanted to see what they can actually accomplish myself.

So I gave several AI agents access to security tools and pointed them at my own deliberately vulnerable web application.

The results were pretty interesting.

A normal search returned zero results. A manipulated sql injection search returned 50 database records.

Another test exposed 52 orders associated with 21 different customer email addresses.

The final result: five confirmed security findings out of six investigated findings.

Let's get into it ~

For the target, I used TrustShop, my own deliberately vulnerable web application hosted on AWS.

It contained synthetic customer data, simulated orders and intentionally introduced security weaknesses. Everything was within my authorized testing environment.

I approached it as a black-box assessment. The agents received the target and the permitted scope, not the application source code or a list of vulnerabilities to discover.

(Small tip. Use a virtual credit card to put a hard limit on your API key spending. Don't rely on platform features that can be hacked.)

For the actual testing workflow, I combined three components:

The underlying models were accessed through OpenRouter, which acts as a model-access layer.

The language model reasons about what to do. The agent framework connects that reasoning to tools that can actually perform actions.

Hermes used different models throughout the project. And importantly, this was not a completely unattended experiment.

One of the clearest findings involved the application's report search functionality.

Normally, a search term should be treated as data. If I search for a particular word, the database should return only matching records.

In my test, the normal search returned zero results.

But when the agent tested a manipulated input, the same functionality returned 50 synthetic records, including 30 additional records outside the intended search filter.

This is a classic SQL injection problem.

The application allowed input that should have been treated as a simple search value to influence the underlying database query.

The important observation was not that the agent produced an unusual request. It was that the application's behavior changed in a measurable way and exposed records the ordinary search did not return.

That demonstrated a database-query manipulation vulnerability.

It did not prove that the agent could modify records, execute operating-system commands or take over the server. Those would require separate evidence.

The second finding is probably the easiest to understand from a business perspective.

Imagine logging into an online store and checking the delivery status of your order.

Now imagine being able to change the order identifier and retrieve somebody else's tracking information.

That is essentially what happened.

The application required users to log in before accessing order tracking. Requests without authentication were rejected with HTTP 401.

So authentication was working.

But another security check was missing.

Being logged in does not mean you should be able to access everybody else's orders.

This vulnerability is known as Broken Object Level Authorization (BOLA), also commonly called Insecure Direct Object Reference (IDOR).

During testing, one authenticated account successfully retrieved another account's order details, including the customer's email address and shipping information.

The investigation then checked sequential order identifiers.

The result was:

All of this involved synthetic customer information in my controlled lab.

The vulnerability was straightforward: the application verified that a user was authenticated but failed to enforce ownership of the requested order.

For real applications, this type of mistake can expose customer addresses, order histories and personal information without requiring any particularly sophisticated exploit.

The third main finding involved file uploads.

The application was supposed to accept PDFs.

However, the agent submitted a file named test.pdf.html and the application accepted it even though it was not a PDF.

The test used harmless content.

This demonstrated an upload validation bypass: the application relied on insufficient checks to decide whether a file was allowed.

It did not demonstrate remote code execution or malicious file execution.

Two additional vulnerabilities were confirmed:

Unauthorized report access: Report functionality exposed data without the required authorization. This was a separate access-control weakness from the SQL injection, even though both affected reporting features.

Checkout race condition: A normal sequential checkout created one order. When five checkout requests were submitted concurrently from the same starting state, the application created five orders.

A race condition happens when the outcome depends on the timing of overlapping operations.

Here, the application failed to handle simultaneous checkout attempts consistently.

That could cause duplicate order processing in a real system, but I did not demonstrate multiple payment charges.

The observed result was five created orders, not five completed payments.

One session-related security issue was investigated but ultimately not confirmed.

And that is an important part of the experiment.

An AI agent reporting a vulnerability is not the same as proving that vulnerability exists.

A useful security finding needs evidence showing what was tested, how the application responded and what security boundary was actually crossed.

I also saw the practical limits of automated discovery. An earlier scan returned no findings despite the application containing known weaknesses.

A clean report does not necessarily mean a clean application. It may simply mean the relevant routes, user roles or business workflows were not sufficiently examined.

This is why I care much more about reproducible observations than impressive-looking vulnerability counts.

For reference, my final demo presentation reported approximately 79 minutes and $10 for the demonstrated workflow.

They exclude preparation, environment setup, earlier work and my own time.

When you give an AI agent access to security tools, you are also giving it capabilities that could be dangerous outside the intended scope.

That makes the agent's execution environment a security concern of its own.

The operating principles are straightforward: run execution in an isolated sandbox, restrict access to host files and credentials, tightly control network destinations and grant tools only the permissions needed for the authorized task.

A system prompt saying "only attack this application bro" is not a security boundary.

My biggest takeaway is not that AI agents have suddenly become elite hackers.

The confirmed weaknesses were familiar application-security problems: SQL injection, broken authorization, inadequate upload validation and unsafe concurrency handling.

No zero-day vulnerability was demonstrated.

And because TrustShop was deliberately vulnerable, this experiment tells us little about success rates against hardened production environments.

What interested me was how the agents connected the different stages of a security assessment.

They could investigate an application, form hypotheses, interact with tools, test suspicious behavior and collect evidence of actual impact.

The progression from a possible vulnerability to a demonstrated security failure is where agentic tooling becomes genuinely useful.

But that usefulness depends on the same things good security testing has always required: appropriate scope, adequate coverage, repeatable results and careful verification.

For defenders, I think that is the development worth watching.

Attackers do not necessarily need completely new vulnerabilities if automation makes familiar weaknesses easier to find and test.

And security teams have an opportunity to use similar capabilities to investigate their own systems before somebody else does.

The real change is not that AI invented a new way to hack applications. It is that reasoning models can now use tools to carry out meaningful parts of the process.

That's it for this week.

See you in the next one.

–Rami