Notifications
Clear all
Topic starter
06/07/2026 9:43 am
TL;DR: Codewall’s analysis of the McKinsey Lilli breach shows an autonomous offensive agent reaching 22 exposed APIs, then using SQL injection and IDOR to reach internal data and system prompts, according to Reva.AI. The real failure is not prompt injection alone but the absence of runtime authorization for AI platforms, where control decisions must happen at the moment of interaction.
NHIMG editorial — based on content published by Reva.AI covering the McKinsey Lilli breach: AI platform compromise through exposed APIs and backend flaws
Questions worth separating out
Q: How should security teams prevent AI platform breaches that use exposed APIs and IDOR?
A: Security teams should treat AI platform APIs like privileged control surfaces, not ordinary application routes.
Q: Why do AI platforms need runtime authorization instead of static application controls?
A: AI platforms combine users, agents, APIs, prompts, and backend data in ways that static code checks cannot govern consistently.
Q: What do security teams get wrong about protecting AI system prompts?
A: Teams often treat prompts as application text instead of privileged configuration.
Practitioner guidance
- Map every AI-facing API and backend dependency Create a complete inventory of endpoints, service accounts, prompt stores, retrieval layers, and database paths used by AI applications.
- Enforce object-level authorization on AI data paths Apply policy checks to each object request, not just to the user session.
- Protect prompts as privileged configuration Store system prompts, retrieval indexes, and model instructions behind tightly scoped write access with immutable change logging.
What's in the full article
Reva.AI's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step attack sequence from discovery through prompt tampering, including how the exposed endpoints were identified.
- The technical explanation of how SQL injection and IDOR combined to expose both data and AI control assets.
- The runtime authorization pattern the vendor proposes for governing agent, API, and data interactions.
- The specific way system prompts and backend assets were stored and modified in the Lilli environment.
👉 Read Reva.AI's analysis of the Lilli breach and runtime authorization gap →
AI platform breaches and the runtime authorization gap teams are missing?
Explore further
06/07/2026 10:00 am
Runtime authorization is the missing control plane for AI platforms. This breach shows that identity alone cannot decide whether a specific agent, API call, or database interaction is safe in context. The failure is structural, because authorization embedded in application logic fragments across services and cannot keep pace with AI platform complexity. Practitioners should treat runtime policy enforcement as the security boundary for agent-facing systems.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- That same research found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI platform exposes data and behavioural controls through backend flaws?
A: Accountability sits with the teams that own application security, IAM, and the AI control plane together. If unauthenticated APIs, weak object controls, or writable prompts exist, the failure is governance as much as engineering. Organisations should assign explicit ownership for endpoint inventory, runtime policy, and privileged configuration protection.
👉 Read our full editorial: AI platform breaches expose the runtime authorization gap in enterprise AI
