Who is accountable when an LLM denial-of-service event is triggered by a legitimate user or service account?

Why This Matters for Security Teams

A denial-of-service event triggered by a legitimate user or service account is rarely a simple “bad user” problem. It usually exposes weak controls around rate limits, tenant isolation, retry handling, and the ownership of the model endpoint itself. That makes accountability a shared operational issue across security, platform, and application teams, not just a support ticket for the account holder.

The practical risk is that authorised identities often have enough trust to create expensive inference bursts, chain repeated calls, or trigger downstream tool activity that amplifies impact. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework treats this as an availability and governance problem, not only an access-control problem. NHIMG research on AI agents as a new attack surface shows how quickly authorised behaviour can cross intended scope when visibility and policy are weak.

In practice, many security teams encounter the incident only after the model endpoint starts timing out, rather than through intentional capacity testing or policy validation.

How It Works in Practice

Accountability is easiest to assign when the control plane is explicit. The owner of the model endpoint is usually accountable for service resilience, the platform team for enforcement controls, and the application team for the calling pattern that created load. Security owns the policy requirements, logging standards, and incident criteria. The user or service account may be the trigger, but it is usually not the accountable party unless misuse was intentional and outside approved behaviour.

Operationally, teams should define thresholds for request rate, token volume, concurrency, retry storms, and tool-calling loops. They should also distinguish between normal bursts and abuse by combining identity context, tenant context, and request context. The NIST AI 600-1 Generative AI Profile and CSA MAESTRO agentic AI threat modeling framework both support this broader view of runtime risk, while NHIMG’s Ultimate Guide to NHIs reinforces that machine identities need explicit lifecycle ownership.

• Assign endpoint ownership to a named service team, not a vague platform bucket.
• Log identity, prompt size, request frequency, model response time, and downstream action paths.
• Use quotas and backoff controls so a valid identity cannot monopolise capacity.
• Separate policy violations from capacity failures in incident playbooks.
• Review whether retries, batching, or agent loops are causing self-inflicted load.

These controls tend to break down when service accounts are shared across applications, because attribution becomes ambiguous and one workload can mask the source of the overload.

Common Variations and Edge Cases

Tighter throttling often increases false positives and may interrupt legitimate automation, requiring organisations to balance service continuity against abuse resistance. That tradeoff is especially sharp in customer-facing copilots, batch inference jobs, and agentic workflows that can generate high-volume but legitimate bursts.

There is no universal standard for this yet, but current guidance suggests treating a legitimate identity that causes denial-of-service as a governance signal, not a user misconduct finding by default. If the account was authorised, the question becomes whether ownership, quotas, and monitoring were designed well enough to absorb predictable load. If the account is a service principal, the accountability usually shifts even more clearly toward the system owner and the policy owner, because machine accounts rarely behave like humans and often fail in repeatable patterns.

For incident review, teams should ask whether the event was caused by poor capacity planning, insufficient guardrails, an agent loop, or an identity that was granted too much authority for its task. NHIMG’s reporting on LLMjacking shows how quickly legitimate access can become an attack path once secrets or identities are abused. In practice, accountability hardens only when every high-usage identity has an owner, a limit, and a response path before the outage becomes visible to customers.

Related resources from NHI Mgmt Group

• When do service accounts become a higher risk than ordinary user accounts?
• When does a service account become a compliance problem?
• What problem does ownership attribution solve for service accounts and API keys?
• How should security teams govern Active Directory service accounts?