AI platform breaches expose the runtime authorization gap in enterprise AI

At a glance

What this is: This is an analysis of how an AI platform breach moved from exposed APIs to database access and prompt tampering, revealing a runtime authorization gap.

Why it matters: It matters because AI platforms combine identity, data, and execution in ways that can outpace traditional IAM, NHI, and application security controls.

👉 Read Reva.AI's analysis of the Lilli breach and runtime authorization gap

Context

AI platform security fails when teams assume authentication and authorization can be bolted on after the fact. In this case, the primary issue was not credential theft but unauthenticated exposure, weak object-level controls, and the ability to alter AI system prompts once the backend was reached.

For IAM and NHI teams, the lesson is that agent-facing systems create a broader trust boundary than conventional applications. When models, APIs, and backend services are tightly coupled, a single gap can expose both data and behaviour, which is why runtime governance matters as much as perimeter control.

Key questions

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. That means authenticating every endpoint, enforcing object-level authorization on each request, and testing for IDOR, SQL injection, and cross-object access in the same review cycle. If the backend can expose prompts or configuration, it should be treated as a high-value identity boundary.

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. Runtime authorization evaluates each action at the moment it occurs, so policy can reflect context, object ownership, and intended behaviour. Without that layer, one exposed interface can cascade into data access and system manipulation.

Q: What do security teams get wrong about protecting AI system prompts?

A: Teams often treat prompts as application text instead of privileged configuration. In practice, prompts shape model behaviour, so tampering with them can change how the system responds for everyone. They should be handled like sensitive control assets, with restricted write access, change logs, and strong separation from ordinary data stores.

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.

Technical breakdown

Exposed APIs create a direct path into AI backends

When internet-facing APIs are undocumented or unauthenticated, they become the first exploitable layer in an AI platform. In this breach, discovery of 22 exposed endpoints gave the attacker a direct route into backend services without needing stolen credentials or phishing. That pattern matters because AI platforms tend to accumulate service interfaces faster than teams can classify them. Once an API sits outside centralized policy enforcement, it becomes an identity blind spot, not just an application bug.

Practical implication: inventory and protect every AI-related API behind centralized authentication and authorization, not local code checks.

SQL injection and IDOR still drive AI compromise

AI systems do not remove legacy application flaws. Blind SQL injection allowed backend query manipulation, while insecure direct object reference let the attacker cross user boundaries and view other consultants' data. These are classic flaws, but their impact grows when the same backend also carries system prompts, configuration, and retrieval data. The technical mistake is treating AI as a separate security class when it still depends on ordinary application trust decisions.

Practical implication: test AI platforms for SQL injection, IDOR, and object-level authorization failures before exposing them to users.

System prompts are operational assets, not just text

System prompts shape model behaviour, so they function like governance controls embedded in content. When the attacker reached the database, the stored prompts became a high-value target because modifying them could alter how the platform behaved for all users. That is a different risk from data theft: the attacker is no longer only reading information but influencing execution logic. For AI platforms, prompt integrity belongs in the same protection class as privileged configuration.

Practical implication: place prompts, model rules, and retrieval sources behind immutable or tightly controlled access paths with full audit logging.

Threat narrative

Attacker objective: The attacker aimed to gain control over backend data and the AI platform's operating logic, not just to exfiltrate information.

1. Entry occurred through 22 undocumented internet-facing API endpoints that lacked authentication, giving the attacker a direct route into the AI platform backend.
2. Escalation followed a blind SQL injection flaw and an insecure direct object reference, which exposed database structure and let the attacker move across user boundaries.
3. Impact came when the attacker reached the database containing system prompts and internal data, allowing both exposure and behavioural manipulation of the AI platform.

Breaches seen in the wild

• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Legacy application flaws become identity failures once AI systems are connected to shared backends. SQL injection and IDOR are old vulnerabilities, but in an AI platform they expose more than records. They can expose prompts, retrieval content, and behavioural controls that shape the system for every user. That means application security, IAM, and NHI governance have to be evaluated together rather than as separate workstreams.

System prompt integrity is now a governance problem, not a developer detail. The article is right to frame prompts as a high-value target because they govern how the platform acts after access is obtained. When those instructions sit beside ordinary data without strict protection, the attacker can change the system’s behaviour at scale. The implication is that AI control assets need privileged handling, auditability, and ownership.

Identity programmes need a new concept: AI control-plane blast radius. Traditional blast-radius thinking focuses on accounts and data sets. AI platforms expand that boundary to include prompts, tool invocation paths, retrieval sources, and backend configuration. That makes one compromised interface capable of affecting both confidentiality and system behaviour. Practitioners should assess AI platforms by the operational reach of a single control failure.

Runtime decisions matter more than static trust assumptions. This breach worked because the platform trusted request paths that had not been governed at execution time. Static assumptions about upstream authentication, object ownership, and prompt protection broke once the attacker reached the backend. Security leaders should use this as a signal that AI governance must be enforced at the moment of action, not during design only.

From our research:

• 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.
• For readers building control strategy, OWASP NHI Top 10 is the next useful step because it frames the control failures that emerge when AI systems can act inside live environments.

What this signals

AI control-plane blast radius: once AI applications share prompts, APIs, and backend data stores, one weak interface can affect both confidentiality and system behaviour. The practical response is to treat AI application paths as governed execution surfaces, not just software features.

The market is moving toward runtime enforcement because static code controls are too slow for AI environments that change rapidly. Teams that still rely on upstream authentication alone will miss the point where object ownership, prompt integrity, and tool access actually need to be decided.

A useful benchmark for programme maturity is whether security can explain who may change prompts, who may call tools, and who can touch retrieval sources at runtime. If those answers are unclear, the AI platform is already operating outside a defensible trust model.

For practitioners

• 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. Prioritize internet-facing interfaces and any undocumented routes that sit outside policy enforcement. The exposed 22 endpoints in this case are exactly the kind of blind spot that inventory work should surface early.
• Enforce object-level authorization on AI data paths Apply policy checks to each object request, not just to the user session. That includes search histories, records, prompts, and configuration objects that may be shared across tenants or user roles. This blocks IDOR-style lateral movement even when the attacker reaches a valid backend.
• Protect prompts as privileged configuration Store system prompts, retrieval indexes, and model instructions behind tightly scoped write access with immutable change logging. Limit write privileges to specific service accounts and review every modification path as part of privileged access governance.

Key takeaways

• The breach shows that AI platform security fails when undocumented APIs and weak object controls open a path into backend systems.
• The real impact is broader than data exposure because prompt access can change how the AI system behaves for every user.
• Runtime authorization and privileged handling of prompts are the controls that would have reduced the attack's reach.

Key terms

• Runtime Authorization: Runtime authorization is the practice of evaluating access at the moment an action occurs, not just at login or deployment. In AI platforms, it decides whether a specific agent, user, or service account can access a particular object or tool in the current context.
• Object-Level Authorization: Object-level authorization controls access to individual records, prompts, files, or configuration items rather than broad application areas. It prevents cross-object access when an attacker reaches a valid backend path, which is especially important in AI systems with shared data layers.
• System Prompt Integrity: System prompt integrity means preserving the confidentiality and correctness of the instructions that govern an AI system's behaviour. Because prompts influence tool use, response style, and operational boundaries, unauthorised changes can alter the system itself, not just the data it returns.
• AI Control-Plane Blast Radius: AI control-plane blast radius is the range of data, actions, and behaviours that can be affected when one AI control fails. It extends beyond records and credentials to include prompts, tool invocation paths, retrieval sources, and backend configuration.

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.

👉 Reva.AI's full article covers the attack chain, prompt exposure, and runtime control model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.