Introducing: Lory AI Autonomous Tester

Lory is the autonomous testing agent inside the Lorikeet Security platform. She authenticates to your application, enumerates the surface that actually exists, sends real authenticated requests across every HTTP verb, tries to chain what she finds into an attack path, and writes CVSS-scored findings with evidence — which a human pentester then approves or rejects before anyone sees them. This is the introduction post: what she does, how the guardrails work, and — just as importantly — what she still refuses to do.

There is a version of this announcement we could have written six months ago, and it would have been mostly true and completely misleading. The agent existed. It ran tools. It wrote findings. What it could not do was log in. It could not send a POST request. It could not follow a link to a page it had not been handed. It was, honestly described, a well-guardrailed vulnerability scanner wearing the vocabulary of a penetration tester.

That gap closed on July 27, 2026. Lory's toolbelt went from nine tools to sixteen, she gained a session engine with an encrypted credential vault, five enumeration primitives, a shared findings bus, and a synthesis pass whose only job is to find chains. Every finding she writes now carries the vector, skill, model, and depth tier that produced it, plus a CVSS v3.1 vector and base score as structured, queryable data rather than prose buried in evidence text. AI engagements can now produce the same branded report, attestation letter, and SARIF export that a human-led engagement produces.

This post explains what that machinery actually does. We have tried to write it the way we would want a vendor to write it for us: concretely, with the limitations stated in the same voice as the capabilities.

What "Autonomous Tester" Means Here

The phrase is doing a lot of work in this industry right now, so let us be precise about our use of it. Lory is autonomous in the sense that she decides what to test next. She is not autonomous in the sense of deciding what is in scope, and she is not autonomous in the sense of deciding what is true.

Scope is declared by you, enforced by a separate component she cannot talk her way past, and re-checked on every single tool call. Truth is decided by a human reviewer who approves or rejects each finding before it exists anywhere a client, a report, or an export can see it. What sits between those two fixed points is genuine agency: given an authorized target and an objective, Lory chooses the reconnaissance, picks the techniques, decides what is worth chasing, and abandons the paths that go nowhere.

The Session Engine: Why Logging In Changed Everything

Almost every interesting web vulnerability lives behind authentication. Insecure direct object references, privilege escalation, broken access control, business logic abuse, mass assignment, insecure file upload, race conditions on stateful endpoints — none of these are reachable by an unauthenticated agent that can only issue GET. An agent restricted that way will reliably find missing security headers, exposed metadata files, outdated server banners, and TLS configuration issues. Those are real findings. They are also the findings a free scanner gives you, and no one should pay for a penetration test that stops there.

Lory now holds a session object for the lifetime of an engagement. Concretely, that means:

• A persistent cookie jar per identity. State carries across tool calls and across vector passes, so a finding discovered in one phase can be validated in another without starting over.
• A declared login flow she can drive. Either a straightforward form post, or a browser-driven login for JavaScript-heavy authentication that a plain HTTP client cannot complete.
• Automatic CSRF token extraction and replay. Tokens are pulled from forms and meta tags and attached to state-changing requests, which is the difference between "the endpoint rejected me" and "the endpoint is actually testable."
• A session-validity probe with automatic re-authentication. Long engagements outlive short session timeouts; when the session drops, she notices and logs back in rather than silently spending the rest of the run testing a login page.
• At least two identities. This is the one that matters most. A low-privilege actor and a high-privilege actor let her test privilege boundaries directly — can user A read user B's object, can a standard role reach an admin route — instead of inferring access control from the outside.

Credentials for all of this live in an encrypted per-asset vault, and they are redacted from logs, from engagement transcripts, and from finding evidence. A finding that reproduces an IDOR does not get to quote your test account's password back at you in the report.

Enumeration: You Cannot Test What You Never Found

The second structural gap was discovery. A single-page fetch tool tells you about the page you already knew about. Real applications hide most of their attack surface behind a JavaScript bundle, an undocumented query parameter, or an API spec nobody linked from the homepage.

Output from all five feeds a single per-engagement attack surface inventory that every subsequent testing pass reads before it starts. This is the difference between an agent that tests the three URLs you gave it and one that tests the application those URLs belong to.

Chaining: The Findings Bus and the Synthesis Pass

Here is a failure mode that is easy to miss when you evaluate AI security tools. An agent can run ten separate testing passes, write a correct finding in each, and still produce a report that no experienced pentester would recognize as engagement output — because each finding was written in isolation and none of them know about each other.

A human tester who finds a server-side request forgery does not write it up and move on. They ask what the SSRF can reach. If it reaches an internal metadata endpoint, they ask what credentials that endpoint returns. If those credentials work, the finding is no longer "SSRF in the URL preview feature, medium severity." It is a full path to compromise, and it is critical.

Lory now has two pieces of machinery for exactly this:

• A shared findings bus. A per-engagement blackboard every testing pass reads at start and writes at end — confirmed findings, credentials and tokens discovered, internal hosts found reachable, endpoints worth revisiting. Pass seven knows what pass two learned.
• A synthesis pass. A final agent pass whose only job is to read the complete blackboard and look for chains. It emits chained findings at combined severity, cross-referencing the component weaknesses that make the chain work.

The reporting instructions had told the model to chain findings for a long time. Nothing had ever given it the opportunity. Now the opportunity is a discrete, budgeted phase of the engagement.

Every Finding Now Carries Its Origin

This change is invisible in the UI and it is arguably the most important one on the list.

Previously, an AI-generated finding recorded what it found but not what found it. There was no column linking a finding back to the attack vector, the specific skill, the model version, or the depth tier that produced it. CVSS existed as prose inside the evidence field — a human could read it, but nothing could query it, validate it, or chart it.

Every finding written from now on carries structured attribution: vector, skill, model, depth tier, CVSS vector string, and CVSS base score, each as its own indexed column. That is what makes the following questions answerable at all:

• Which of our skills produce findings a human approves, and which produce noise?
• Does false-positive rate change when we change models?
• What does an approved finding actually cost us to produce, by depth tier?
• Did that skill edit make results better or worse?

None of those had a numeric answer before. We wrote a separate post about the measurement loop, because it deserves more than a paragraph.

Deliverables: Report, Attestation Letter, SARIF

A finding in a dashboard is not a deliverable. Auditors, customers, and procurement teams ask for artifacts, and until this release an AI-driven engagement could not produce a single one of them — the report builder understood human pentest engagements and incident response engagements, and simply did not know AI engagements existed.

The Guardrails, Stated Plainly

Scope enforcement that fails closed

Every tool call is checked against the scope rules for the engagement before it executes. The important property is not that the check exists — everyone has a check — it is what happens when the check is uncertain. Our target normaliser handles userinfo, ports, bracketed IPv6, trailing dots, and internationalized domain names, and a target it cannot confidently parse matches no rule at all and is refused. A URL like https://[email protected]/ is not a hypothetical; it is a classic parser-confusion pattern, and fail-closed is the only correct response to it.

Non-destructive by design

The toolbelt is deliberately detection-oriented. Injection testing runs at minimum level and risk with no data extraction and no shell option. Template-based scanning excludes denial-of-service, intrusive, and fuzzing categories outright. There is no post-exploitation tooling: no database dumping, no shell spawning, no persistence, no lateral movement. This is a real constraint on what Lory can prove, and we would rather state it than let "AI red teamer" language imply otherwise.

A stop button that actually stops

A halt issued from the dashboard is honoured at the next tool boundary, not at the end of the current pass. This matters more than it sounds: a single pass can invoke two long-running scanners back to back, so a naive per-iteration cancellation check can leave a "stopped" engagement running for ten more minutes. The check also fails closed — if the engine cannot read engagement state, it halts rather than assuming it should continue.

Model failover

Inference calls fail over across a retryable-only, cheapest-first chain. A single provider hiccup no longer takes an engagement down mid-run.

What Lory Refuses To Do

Four asset types in our platform — mobile applications, cloud control planes, Active Directory, and source code repositories — have written methodology but no executable tooling behind them yet.

The tempting product decision is to let those engagements run anyway, produce whatever the generic tooling finds, and let the report speak for itself. We think that is the single most dangerous thing an autonomous testing product can do, because a thin test that reports nothing is indistinguishable from a thorough test that found nothing — and the client makes risk decisions on the difference.

So the platform refuses. Requesting an engagement against an untooled asset type is blocked at request time and at start time, with an explicit message saying why. The refusal gate stays on per asset type until real tooling ships for it. Secrets scanning and source repository analysis are next in the queue, followed by cloud, then mobile, then Active Directory.

Where the Human Sits

Every finding Lory writes lands in pending_review. It is excluded from reports, exports, dashboards, and the client-facing findings list until a Lorikeet Security pentester triages it. Approval means a human read the evidence and agrees it is real. Rejection requires selecting a reason from a fixed taxonomy — false positive, out of scope, duplicate, not exploitable, insufficient evidence, accepted risk — because free-text rejections cannot be aggregated, and a rejection you cannot aggregate teaches you nothing.

We are explicit about this because "human in the loop" is frequently claimed and rarely specified. In our case the loop is: the agent proposes, a named pentester disposes, the disposition is recorded as structured data, and that data feeds back into which techniques stay in the default rotation.

How to Start

An engagement starts from the AI Pentester page in your dashboard. You declare scope, pick a depth tier, optionally supply credentials for the identities you want tested, and start the run. Progress streams into a live engagement timeline — every tool call, every decision, every finding written, timestamped — so an engagement is auditable while it is running rather than only after it finishes.

If you work in an editor, the Lorikeet MCP server exposes findings, the vulnerability knowledge base, asset inventory, and scope checking to Claude Code, Cursor, or Claude Desktop — so the tool you use to write the fix can read the finding that describes it.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

Lorikeet Security helps modern engineering teams ship safer software. Our work spans web applications, APIs, cloud infrastructure, and AI-generated codebases — and everything we publish here comes from patterns we see in real client engagements.

Practical security, written by practitioners.