Evidence

What we actually found

Two engagements, published with client permission. Both systems had passed the checks their buyers asked for. Neither buyer was wrong to ask; the checks just do not reach this.

Case 01  /  Enterprise AI sales intelligence

Active GRC tooling. A free trial account. 95 customers' reports.

An AI-enabled sales intelligence platform with enterprise contracts, an active compliance motion, third-party GRC tooling in use, and a smallest customer north of $1B in revenue.

8
critical or high, confirmed
95
customer reports retrieved
3.49 MB
cross-tenant, one request
17
vulnerability classes across 5 categories

The finding that mattered

The platform's core value is AI-generated research reports built over months of analysis and stakeholder profiling. The report download endpoint accepted an account ID and never checked whether the caller owned that account. Account IDs were sequential integers.

A single authenticated user, including a free trial account, could iterate the range and collect working download URLs. We obtained 95 customer reports across 201 probed accounts in one session. The URLs embedded temporary storage credentials valid for seven days, so each exposure kept a week-long tail.

Three more that change the threat model

  • System prompt extraction. The AI returned its verbatim operating instructions to any user who asked. That is a map of every constraint the platform had, and once it is out, every control built on "the AI will not do X" becomes negotiable.
  • Persistent prompt injection. Attacker-controlled instructions could be written to the AI's stored configuration. They survived logout and applied to every future interaction on that account.
  • Fabricated compliance certifications. The AI generated and published SOC 2, ISO 27001 and GDPR certifications with no content review and no human approval. One API call, externally shareable.
finding-01 / broken object-level authorisation CONFIRMED EXPLOITED
[01] authenticate, free-trial tier ...... ok [02] account IDs sequential ............. yes [03] endpoint ownership check ........... NONE [04] accounts probed .................... 201 [05] reports retrieved .................. 95 [06] data exposed ....................... 3.49 MB [07] storage cred expiry ................ 7 days
BOLA System prompt disclosure Persistent injection Unreviewed AI publication

Compliance tooling was active and working as designed. It answers whether controls exist and are evidenced. It does not answer whether an endpoint checks ownership.

Case 02  /  AI-native LMS platform

Losing enterprise deals at security review, then not

An AI-native LMS SaaS selling into large Indian enterprises. They had just lost a significant deal, not on product, but because they could not clear the buyer's security review. More deals were in the pipeline carrying the same questionnaires.

28
findings across the MCP surface
3 / 8
critical / high
100%
of critical and high closed
2 mo
to enterprise-grade

Why nobody else was assessing it

Their MCP server was the novel attack surface, and generic VAPT vendors do not assess it. Not because they are careless, but because it is new territory and there is no established methodology to apply. Meanwhile the enterprise questionnaires kept arriving: DPDP, CERT-In logging, cloud posture, LLM supply chain, MCP security.

We ran the full MCP red-team framework against production authentication and the MCP server, both unauthenticated and privileged. The focus was chained attacks: individually defensible components that combine into critical enterprise risk.

What the chain gave up

  • Malformed input leaked the tenant ID, the database schema and storage tokens
  • OAuth client registration was wide open
  • Findings mapped to OWASP Top 10 and OWASP LLM Top 10, so the output was a CISO-ready narrative rather than a raw technical list

We do not accept "fixed" on trust. After the engineering team shipped remediations we re-ran both assessments live against the running system, same attacker model, same two-tenant probes, and recorded exactly what closed.

Retest record / MCP surface HiltLock

Error and secret channels

Before. 28 findings, 3 critical and 8 high. Malformed input leaked the tenant ID, the database schema and storage tokens. OAuth client registration was wide open.


After. Every critical and high finding closed and verified by live retest against the running system, not by reviewing a remediation ticket.


Outcome: enterprise security reviews cleared. Two months from weak posture to enterprise-grade.

MCP chained attack Secret disclosure Open OAuth registration Closed and retested
The pattern

What both engagements have in common

Two very different systems, two different attack surfaces, one shared shape.

01

The traffic looked legitimate

No malformed request, no injected payload a signature would match. A valid session and an incrementing integer. Nothing to detect, because nothing looked wrong.

02

Compliance was genuinely in place

GRC tooling active in one, enterprise questionnaires being answered in the other. Both were doing the work their buyers asked for. Neither exercise asks whether a control survives an attacker.

03

The surface was too new to have a playbook

MCP servers, agent tool wiring, AI-generated artifacts published without review. There is no signature list for these yet, which is precisely why a human has to go and look.

Find out what is reachable in yours

Start with the automated pass if you want a fast baseline, or go straight to the human assessment if the system is multi-tenant or can take actions. Twenty minutes is enough for us to tell you which.