Meet Lory: Lorikeet's AI Pentester, and How to Fix Her Findings in Claude Code via MCP

Lory is the AI pentester living inside the Lorikeet Security dashboard — plans an engagement, tests your authorized scope, and writes evidence-backed findings for a human to countersign, 24/7 instead of once a year. This post introduces her properly: how she thinks, what she's tested against, and how her results compare to a traditional pentest. Then it covers the Lorikeet Security MCP server, which is how Claude Code, Cursor, or Claude Desktop read those findings and help you fix them without leaving your editor.

Most "AI pentesting" you'll see marketed right now is a vulnerability scanner with a chatbot bolted on the front — same CVE list, now with a paragraph of generated prose above it. That's not what we built. Lory plans an engagement the way a person does: recon first, then targeted probing based on what's actually exposed, then an attempt to chain anything she finds into real impact before she ever writes a finding down. And because Lory produces findings the same way our human pentesters do, the MCP server that lets Claude Code read and act on those findings works whether the finding came from Lory, from a human tester, or from your own team.

Who Is Lory?

Lorikeet Security is named after the lorikeet — a small, sharp, brightly-colored parrot. Lory is our mascot's namesake given a job: an offensive security agent that operates inside your portal, not a support chatbot that answers questions about your findings after the fact. The distinction matters. Lory doesn't wait for you to ask "is this endpoint vulnerable" — she goes and finds out, the same way a contracted pentester would, and brings back evidence.

What she is not: a wrapper around a scanner that summarizes CVE output with an LLM. Her toolbelt runs actual reconnaissance and exploitation attempts against your infrastructure, her technique selection is driven by what's actually exposed rather than a fixed checklist, and every finding she produces is checked by a person before it's real. She is scope-gated by design — she only touches assets you've explicitly authorized — and non-destructive by default, meaning her exploitation techniques are chosen to prove impact without breaking anything.

How Lory works, step by step

What Lory brings to an engagement

What Lory Knows: The Numbers Behind the Guidance

The remediation guidance Lory writes isn't an unmoored model guess — it's grounded against Lorikeet Security's internal vulnerability knowledge base, which we import from MITRE and OWASP source material and keep query-indexed for both Lory and the kb.search MCP tool. Here's the actual breakdown, pulled straight from that database:

MITRE's two attack-pattern catalogs (CWE for weakness classes, CAPEC for attack patterns) make up the bulk of the volume, with OWASP's ASVS and WSTG providing structured, testable requirements on top. This is the same reference material a human Lorikeet Security pentester works from — Lory doesn't get a separate, thinner playbook.

Engagement Depths: Choosing How Far Lory Goes

Every engagement runs one of three depths. These aren't marketing tiers layered over identical behavior — each one changes what Lory actually attempts:

Bar length reflects relative depth of engagement, not a linear time scale (Deep runs 10–20× longer than Surface, not 5×).

• Surface — passive recon and safe checks only. What's exposed, what's fingerprintable, no active probing.
• Standard — active enumeration plus non-destructive exploitation. This is where most OWASP Top 10 classes get tested.
• Deep — a full AI-led engagement with a human pentester reviewing throughout, not just at the end. Chaining, pivoting, and multi-stage attack paths are in scope.

Lory vs. the annual pentest

The honest comparison isn't "AI vs. human" — Lory's findings are human-reviewed either way. It's cadence: a scheduled, point-in-time engagement vs. something that can run continuously against drift.

Starting an engagement

1. Make sure the target is registered as an asset and marked in-scope. Anything outside your authorized scope is held for a human scope review before Lory will touch it, so add and confirm scope first under Manage scope.
2. Pick the asset from the dropdown on the AI Pentester page — Lory reads its engagement type from your scope rules automatically.
3. Choose a depth: Surface, Standard, or Deep.
4. Optionally leave notes for Lory — credentials for authenticated testing, areas to focus on, or things to avoid.
5. Click Request engagement. In-scope targets kick off immediately; you'll get a Teams and email notification when the report is ready for review.

Findings show up in your normal findings workflow once a human has signed off, alongside anything from a traditional Lorikeet Security engagement. That's the point — Lory is another way findings get into your portal, not a separate, siloed product.

Part 2: The MCP Server — Getting Your Data (and Lory's Findings) Into Claude Code

Everything above happens in the dashboard. The Lorikeet Security MCP server is what lets an AI agent you already work in — Claude Code, Claude Desktop, Cursor, or anything else that speaks Model Context Protocol — reach into that same data without you switching tabs. Once it's connected, you can ask Claude things like "what are my open critical findings" or "is api.acme.io in scope" and get answers pulled live from your workspace, scoped strictly to your company — a token can't see another tenant's data.

Setting it up in Claude Code

First, generate a token from the MCP Server page in your dashboard — it's shown once, so save it somewhere safe (a password manager, not a repo). Then add the server to ~/.claude/mcp.json (user-level) or your project's .mcp.json:

Run /mcp in any Claude Code session to confirm the connection — you should see lorikeet come up with a green status. Claude Desktop and Cursor follow the same shape: point a streamable-HTTP MCP client at the same URL with the same bearer token in the Authorization header. Full JSON-RPC and curl examples for every method live in our MCP docs.

What you can actually do with it

Every tool is invoked through tools/call, but in practice you just talk to Claude in plain English and it picks the right tool. Here's the current toolset:

Read scopes (findings:read, kb:read, compliance:read) are self-serve on any token you issue. Write scopes — findings:write, retest:request, tickets:write — require an explicit grant from your account manager, since they let an agent take actions on your behalf rather than just read.

The workflow that matters: fixing a finding without leaving Claude Code

This is the part worth actually adopting. Instead of reading a finding in the portal, translating it into a code change in your head, and jumping between three tabs to fix it:

1. Pull the finding. Ask Claude Code something like "pull my open critical findings from Lorikeet." It calls findings.list, then findings.get on the one you care about to get the full description, evidence, and affected asset.
2. Find the code. With the affected asset and evidence in context, Claude greps your actual repository for the vulnerable endpoint, query, or component — the same way it would for any bug you described to it directly.
3. Pull remediation context. If the finding's guidance needs backup, Claude can call kb.search against the OWASP/MITRE-backed KB charted above for the specific vulnerability class (SSRF, IDOR, broken auth, whatever it is) to ground the fix in the right pattern rather than guessing.
4. Fix it and review the diff. Claude proposes the change; you review it like any other diff before merging. Nothing here auto-merges — the write surface into your codebase is the same one you already trust.
5. Close the loop. Once the fix ships, ask Claude to file the retest: it calls retest.request with a note on what changed. A Lorikeet Security pentester re-tests and marks the finding resolved — no portal round-trip required.

If you're running your own agent against an authorized engagement — the "bring your own AI" path — findings.create and engagement.update exist for the same reason Lory writes to pending_review: your agent can propose a finding or leave progress notes on an active engagement, but the affected asset has to pass a live scope.check first, and everything still lands in front of a human before it's real.

Pulling more than just findings

The MCP server isn't only a bug-fixing pipeline. A few other things it's genuinely useful for from inside Claude Code or Cursor:

• Attack surface triage: "What assets do I actually have findings against, and which ones are in scope?" via asm.assets — useful before you point any tool, human or AI, at something.
• Compliance-aware fixes: Pull compliance.controls for the framework you're tracking while you're triaging findings, so you can see whether a given finding maps to a control that's currently blocking a SOC 2 or ISO 27001 milestone.
• KB lookups mid-review: Ask "what does WSTG say about testing for business logic flaws" and get it answered from kb.search instead of leaving your editor to go find the OWASP page.
• Engagement status without a tab switch: If you or your own agent kicked off an AI-driven engagement, engagement.update lets you leave a note the human reviewer will see, right from the terminal.

Why We Built These Together

The failure mode we were trying to avoid is the one most security tooling still has: findings live in a portal, fixes live in a codebase, and a human has to be the router between them, manually, every time. Lory produces validated findings around the clock instead of once or twice a year. The MCP server means the tool you're already using to write the fix — Claude Code, in your actual repo — can read those findings, ground its fix in the same knowledge base charted above, and close the loop with a retest request, all without a copy-paste in sight.

Neither piece removes the human. Lory's findings are countersigned before they're real; Claude's fixes still go through your normal review before they merge. What both pieces remove is the friction between "we found it" and "we fixed 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.