Your agent gets attacked before your users find it.
For anything with a model in the loop — an agent with tools, an n8n workflow calling OpenAI or Anthropic, a chatbot on your data. In five working days I try to make it leak, overreach and spend, by hand, against your own prompts and integrations.
new · fixed price once scoped · one system, one environment
One AI system, one environment, with the prompts and the code.
The same shape as the web review: eight areas, findings in writing, a walkthrough call. The bugs are new; the discipline is not.
01
Prompt injection
Direct, and indirect through documents, web pages, emails and tool output the model reads. Whether an instruction in the data becomes an instruction to the system.
02
Tool permissions
What the model can call, with whose credentials, and what happens when it is talked into calling it. Least privilege, confirmation for anything that spends or deletes.
03
Data leakage
The system prompt, other users' conversations, retrieval scope across tenants, what the model will repeat back if asked nicely.
04
Exposed keys
Provider keys and tokens in n8n credentials, client bundles, logs, prompts and the git history.
05
Who can talk to it
Authentication around the agent, rate limits, and cost abuse — a public endpoint that spends your API budget.
06
Output handling
Where the model's output lands: rendered HTML, a SQL query, a shell command, an email. Untrusted output treated as untrusted.
07
Retrieval and memory
Poisoning the corpus, memory that persists across users, embeddings that cross tenant lines.
08
Logging and configuration
Prompts and personal data in logs, debug modes, model and temperature settings, fallbacks when the provider fails.
what you get
Findings you can hand to a developer, or an investor.
A written findings document in the same format as the web review: what it is, why it matters to your business, how to reproduce it — the exact prompt or request — and how to fix it. A 30-minute walkthrough call with whoever builds the workflow.
If the system holds up, the document says so. I don't invent findings, and I'll tell you if what you actually need is the web review of the app around the model.
what you receive
A finding, as it arrives.
Every finding in a report says what the issue is, what an attacker gains, exactly how to reproduce it, and how to fix it — ranked by real-world impact, never a scanner result passed through. This one is from the public sample; the whole 12-page report is linked under it.
IDOR on order endpoint exposes any customer's orders
Order API · CWE-639 · OWASP API1:2023
What the issue is
GET /v2/orders/{orderId} verifies that the caller is authenticated but never checks that the order belongs to them. Order IDs are sequential integers, so the entire order table can be walked by incrementing a number.
What an attacker gains
Any authenticated customer can read every order in the system: line items, totals, delivery addresses, phone numbers and email addresses. For a retailer this is a personal-data breach affecting the whole customer base, reachable from a free signup.
Reproduction
# authenticated as customer A (own order)
GET /v2/orders/10442 → 200 OK // expected
# same session, another customer's order
GET /v2/orders/10441 → 200 OK
{"orderId":10441,"customer":{"name":"[REDACTED]", …
A short script walking IDs 10000–10500 returned 500 of 501 records. Enumeration was stopped at that point and no data was retained; the redactions above are applied at capture.
How to fix it
Enforce ownership server-side on every object access — the query itself should be scoped to the caller, not filtered afterwards. Replace sequential identifiers with UUIDs so that enumeration is not trivially possible even if a check is missed in future.
-- scope the query, do not check after fetching
SELECT * FROM orders WHERE id = $1 AND customer_id = $2;
Add an automated test asserting that customer A receives 404 for customer B's order. This class of bug returns whenever a new endpoint is added, so the guard needs to be a test, not a code review habit.
Sample report · fictional target · every finding, payload and identifier in it is synthetic. Real reports go to the client and nowhere else.
price and timeline — fixed once the system is scoped
9000
USD, about · ₹75,000 · fixed in writing after a short call
50
working days, from access to written findings
80
areas checked, listed above
30 min0 min
walkthrough call with your developers
“About” because AI systems vary more than web apps: one workflow with two tools is a different week from an agent with twenty. The price is fixed in writing before it starts, like everything else here.
before you book
Questions people actually ask.
What counts as an AI system here?+
Anything with a model in the loop that your users or your data can reach: an agent with tools, an n8n or similar workflow that calls OpenAI or Anthropic, a chatbot over your documents, a copilot inside your app.
Is this a review of the model, or of my code?+
Of your system: the prompts, the tools, the data the model can reach, the code around it, and the way its output is used. The model itself is the provider's; how you've wired it is yours.
Do you need the prompts and the source?+
Yes. A white-box review with the prompts, the tool definitions and the code finds far more than poking at a chat window, and it is the only way to check permissions and key handling.
How is this different from the web security review?+
Same shape — five working days, eight areas, written findings, a call — but the areas are the ones that matter when a model is in the loop. If your app has both, the two can be scoped together.
book an ai review
Tell me what the model can reach.
What it does, which tools it has, and where the data comes from. I reply within one working day.
