security: unbounded ACP frames and per-request goroutines (Z-017)

[PierrunoYT]

Description

The Agent Communication Protocol (ACP) implementation currently lacks resource boundaries for frame processing and concurrency. Specifically, there are no hard caps on the number of frames that can be processed per request, nor is there a limit on the number of goroutines spawned to handle concurrent lapped requests or streaming responses.

A malicious or malformed ACP stream could be designed to send an excessive number of frames or initiate a large number of concurrent requests, forcing the system to allocate unbounded memory or exhaust the available thread pool.

Impact

This is a classic Denial of Service (DoS) vector. An attacker (or a malformed provider response) could crash the Zero process by triggering an Out-Of-Memory (OOM) event or by exceeding the operating system's process thread limit, rendering the agent unavailable.

Recommended Fix

Implement strict resource quotas for ACP sessions:

1. Frame Budgeting: Introduce a maxFramesPerRequest limit. Once a request exceeds this budget, the connection should be terminated with a protocol error.
2. Concurrency Throttling: Implement a semaphore or worker pool to cap the number of concurrent goroutines active for a single ACP session or request.
3. Memory Capping: Use limited readers or pre-allocated buffers to prevent a single large frame from consuming all available system memory.

[vedantlavale]

working on this :)

[gnanam1990]

Approved after checking current main. ACP still reads newline frames with ReadBytes and starts request handlers in goroutines without explicit frame-size or per-connection concurrency limits. The fix must bound both memory and handler concurrency and fail closed without deadlocking shutdown. PR #944 is already active.