Who is accountable when a pre-authentication RCE affects an AI service?

Accountability usually spans application owners, platform teams, and cloud operators because the failure sits across request handling, deployment design, and network exposure. Governance frameworks should assign ownership for runtime execution paths, not just patching, because the key question is who approved an architecture that can execute untrusted input before authentication.

Why This Matters for Security Teams

A pre-authentication RCE in an AI service is not just a vulnerability management issue. It is a control failure at the boundary where unauthenticated traffic can reach code that can execute, call tools, or access internal services. That means accountability must extend beyond the application owner to the platform team that exposed the runtime and the cloud operator who shaped the network and identity guardrails. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames governance, protection, and recovery as shared duties rather than isolated tickets.

This is especially important in AI services because the blast radius can include model endpoints, retrieval layers, secret stores, and downstream tool execution. NHIMG research on the ASP.NET machine keys RCE attack shows how pre-auth flaws can become full execution paths, while the DeepSeek breach is a reminder that exposed systems can quickly translate into data exposure and secret leakage. In practice, many security teams encounter ownership disputes only after the service has already been exploited, rather than through intentional architecture review.

How It Works in Practice

Accountability for a pre-auth RCE usually lands in three places at once: the team that owns the AI application, the platform team that runs the service, and the cloud or infrastructure team that approves exposure, segmentation, and runtime permissions. The core question is not who applies the patch first. It is who accepted a design that allowed untrusted input to reach executable code before any identity check.

Practically, that means ownership should map to the full execution chain:

• request ingress and edge filtering
• authentication placement and bypass paths
• container, VM, or serverless runtime permissions
• access to secrets, vector stores, and internal APIs
• logging, alerting, and isolation after compromise

For AI services, this becomes harder because the service may invoke model tooling, retrieval plugins, or orchestration agents after initial request handling. Current guidance suggests treating these as separate trust boundaries, with explicit approval for each runtime path. The governance lesson from NHIMG’s DeepSeek breach coverage is that exposed AI systems often fail across more than one layer, so incident ownership cannot stop at the application ticket queue. Security teams should align this with the NIST Cybersecurity Framework 2.0 by assigning clear accountable owners for identify, protect, detect, and respond activities. These controls tend to break down when the AI service is deployed by one team, secured by another, and monitored by a third because no single owner reviews the end-to-end execution path.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance faster delivery against clearer control ownership. That tradeoff becomes most visible in cloud-native AI stacks, where platform teams may manage ingress and runtime, while product teams manage prompts, tools, and data access.

There is no universal standard for this yet, but current guidance suggests using an explicit RACI model for pre-auth execution risk. The application owner should own the code path, the platform team should own the runtime guardrails, and the cloud team should own exposure, segmentation, and baseline policy. If a managed AI service is involved, accountability may also extend to the provider for shared responsibility gaps, especially where the service exposes webhooks, connectors, or custom tool execution.

Edge cases include serverless AI endpoints, reverse proxies that transform requests before auth, and retrieval systems that can trigger internal calls even when the main API is not authenticated. In those cases, the decisive control is not just patch status but whether the architecture allows code execution before a trust decision. The safest approach is to document the execution path, name the decision-maker for each control point, and require sign-off before new attack surfaces go live.

Related resources from NHI Mgmt Group

• Who is accountable when AI tool use happens through unmanaged browser sessions?
• Who is accountable when shadow AI uses corporate credentials to process sensitive data?
• Who is accountable when an AI vendor changes an agent's capabilities without notice?
• Who is accountable when shadow AI is used from managed endpoints?