Capacity is a security and availability boundary
A connected service can be disrupted by demand that exceeds its ability to process work, whether malicious or accidental. Applications, identity systems, management interfaces, and AI runtimes can have different limits. Identify the resources needed to complete the intended task and which are shared. A fast radio link does not establish end-to-end capacity. Treat overload behavior as part of the service design rather than assuming that more infrastructure can always be provisioned immediately.
Bound automated work and retries
Agents can make repeated tool calls, extend a workflow, or consume costly model capacity without producing useful results. OWASP identifies denial-of-wallet risk and recommends limits on execution, retries, tokens, and tool chaining. Apply controls appropriate to the workload and service objectives. A retry should not duplicate a consequential action or expand authority. The responsible teams need to decide what is queued, rejected, paused, or escalated when approved capacity or execution boundaries are reached.
Preserve management and evidence access
During disruption, teams still need trustworthy status and a controlled way to act. Review shared dependencies so a single overloaded component does not remove both the service and its recovery path. CISA’s secure-by-design principles support layered defenses and avoiding compromise of the entire system through one failed control. Validate the proposed protections under authorized, representative tests. Do not infer resilience from a diagram showing redundant components without checking whether they depend on the same constrained service.
Exercise recovery and review fairness
Measure useful completed work, rejected requests, recovery time, and effects on other tenants or services. Review whether one workload can consume resources needed by another. Include support procedures and clear communication when the service is degraded. Future IMT-2030 research treats resilience as important, but it is not a guarantee for a particular application. Dependable protection against resource exhaustion combines realistic limits, observable state, contained failures, and a tested response when demand exceeds the system’s supported operating range.