Normal capacity
Collect bounded health information and operate normally. There is no reason to apply aggressive filtering simply because a traffic tag exists.
AUTOMATIC REQUEST FOR ASSISTANCE
When capacity is scarce, protect presumed-clean traffic first.
A server, VM or gateway can monitor its own load and automatically request help as resources become constrained. TaraSec's proposed safety boundary is simple: high load does not make anyone an attacker. The strongest autonomous intervention is to ask cooperating infrastructure to suppress traffic that TaraSec has already tagged through its normal evidence process.
SEPARATE TWO DECISIONS
Load determines how much protection is needed. Evidence determines what is tagged.
A traffic spike, backup, software update or popular service can create high load without an attack. For that reason, overload must not itself create a negative TaraSec tag.
Instead, local AI or deterministic monitoring can decide that a machine needs assistance. TaraSec's cooperative evidence determines which traffic already carries a suspicious assessment. The two decisions remain deliberately separate.
GRADUATED RESPONSE
Use the least intervention necessary.
Increasing pressure
Observe CPU, memory, connection pressure, queues, bandwidth and application health. Sustained abnormal conditions can trigger an assistance request without accusing any source of causing the load.
Assistance
Ask cooperating routers, networks or providers to give scarce capacity to presumed-clean traffic and suppress traffic already carrying sufficiently strong TaraSec threat information.
Recovery
Continuously reassess. As capacity returns, automatically reduce or expire the intervention rather than turning a temporary overload response into a permanent block.
AI'S SAFETY BOUNDARY
AI can ask for protection. It cannot manufacture evidence.
AI may decide when a server needs protection, but it must not decide that someone is an attacker merely because the server is overloaded.
Its maximum autonomous intervention is a bounded Request for Assistance to suppress traffic already tagged through TaraSec's normal accountable evidence process. Tag creation, corroboration, contradiction and recovery remain separate from the overload decision.
This keeps the fast packet path deterministic. AI belongs primarily in the slower control plane: assessing resource pressure, correlating observations, choosing the degree of assistance and deciding when assistance can safely be withdrawn.
WHY COOPERATION MATTERS
Move mitigation upstream before unwanted traffic consumes the victim's capacity.
A small VM cannot outspend a large DDoS attack. But it can tell a cooperating network that it is running out of resources and ask that scarce capacity be reserved for traffic with the strongest reason to be considered clean.
The long-term TaraSec model is therefore not an “AI firewall.” TaraSec provides cooperative signalling and accountable traffic context; AI manages the degree of protection; routers, firewalls and participating providers enforce bounded policy.
A DIFFERENT AI MECHANISM
This is separate from AI-guided TaraSec development.
Request for Assistance protects operating services. TaraSec's cooperative development model addresses a different problem: how contributors, AI and accountable governance can improve TaraSec itself.
The two share a philosophy of cooperation, but they have different authority, data and safety boundaries.
EXPERIMENTAL STATUS
The building blocks exist; automatic overload-driven protection is still being integrated.
TaraSec already contains traffic tagging concepts, server protection registration, Request for Assistance structures, partner status reporting and AI/load monitoring. Generic VM reporting and the automatic overload → assistance → tagged-traffic suppression loop are active development work, not a production claim.