How IVD works in practice.

Where IVD-N sits

IVD-N does not replace a firewall, scrubbing service, WAF, SIEM, or SOC. It sits where traffic behavior can be observed, grouped, converted into limited policy decisions, and translated into router-enforceable rules where supported.

Telemetry may come from controlled test traffic, PCAP or test harnesses, or operational telemetry sources such as NetFlow, IPFIX, sFlow, or packet and header metadata, depending on deployment.

Broader suppression across providers depends on operator participation, routing policy, and FlowSpec acceptance. IVD does not assume third-party carriers will automatically accept externally originated filtering rules.

Example: from traffic pattern to router rule

1. A distributed traffic pattern appears in a controlled test or monitored edge environment.
2. The edge sensor creates a compact traffic fingerprint from observable packet, header, and timing behavior.
3. Related abnormal behavior is grouped into one limited attack object.
4. The Policy Engine chooses monitor, rate-limit, drop, or withdraw.
5. The FlowSpec Controller emits a FlowSpec-compatible router filtering rule where supported.
6. The rule is logged, time-limited, and withdrawn when conditions normalize.
7. Evidence records are retained for review.

This is a representative controlled-environment trace, not a claim of carrier-scale production validation.

Where IVD-ACP sits

IVD-ACP is not one universal hook into every execution path. It is deployed at specific admission surfaces where an input or action can be evaluated before trust or execution.

ACP is not a magic external monitor. It must be placed at an admission surface: CI/CD gate, package proxy, API gateway, RAG pre-index gate, agent/tool-call gateway, or administrative workflow gate. If a workflow bypasses that admission surface, ACP does not govern that path.

• CI/CD gate
• Package or artifact intake proxy
• API gateway or pre-processor
• RAG pre-index gate
• AI agent or tool-call gateway
• Administrative workflow gate

Different environments require different integration points. ACP does not claim to intercept every execution path in every enterprise environment.

Example: package entering a CI/CD workflow

1. A package, dependency update, script, or artifact enters a build workflow.
2. ACP evaluates it before execution, indexing, retrieval eligibility, or privileged action.
3. ACP considers policy context, package metadata, script behavior, provenance signals, or other configured checks.
4. ACP assigns one outcome: ALLOW, READ_ONLY, SANDBOX, QUARANTINE, or REJECT.
5. The protected workflow receives only the permitted form of the package or action.
6. Non-admissible material is routed to quarantine or review.
7. The decision is logged.

This is a representative admission-flow example, not a claim that ACP detects every malicious package or replaces SCA, SBOM, EDR, IAM, WAF, sandboxing, CI/CD security, or human review.

IVD-N deployment model

• Edge telemetry sensor or test observer
• Regional or coordination service
• Policy Engine
• FlowSpec Controller
• Router enforcement point
• Audit logs

These are deployment patterns for evaluation and pilot design. They should not be read as claims of production deployment or accreditation.

IVD-ACP deployment model

• API gateway or pre-processor
• CI/CD gate
• Package proxy or artifact intake gate
• RAG pre-index gate
• Agent or tool boundary
• Audit logs

These are deployment patterns for evaluation and pilot design. They should not be read as claims of production deployment or accreditation.

Network convergence failure

IVD-N is designed for cases where distributed traffic becomes harmful because many sources converge on protected infrastructure faster than downstream systems can absorb, classify, or filter it.

In plain terms, the risk is not just that bad packets exist. The risk is that coordinated traffic becomes expensive and destabilizing once it collapses onto the victim edge.

Trusted execution failure

IVD-ACP is designed for cases where packages, prompts, commands, documents, tool calls, or other artifacts become harmful because they are trusted or executed before a policy decision is made.

In plain terms, the risk is not just that unsafe content exists. The risk is that it is admitted into trusted execution, indexing, retrieval, or privileged workflow authority too early.

False positives and false negatives must both be expected in operational environments. Tested-scope results should be described only as tested-scope results. Any serious pilot needs explicit review, override, relief, quarantine, and tuning workflows so that mistakes can be seen and corrected.

• False positives must be reviewed and governed.
• False negatives remain possible and must be measured during operational validation.
• Rule counts must be limited and governed.
• Rule churn must be governed.

Network enforcement depends on router support, TCAM capacity, operator policy, and clean rule withdrawal. ACP deployment depends on explicit fail-open or fail-closed behavior for each protected workflow. Pilot designs should never leave failure behavior implicit.

• Rules must expire and be withdrawn cleanly.
• FlowSpec and router enforcement depend on platform support and operator policy.
• Router TCAM and rule limits are real operational constraints and should be governed.
• Unreachable coordination behavior must be explicit for pilots.

Service Identity Layer relief is intended to soften, narrow, or adjust mitigation for authenticated legitimate services. It does not mean all legitimate traffic will always be unaffected.

• Service Identity Layer relief requests are intended to narrow mitigation for authenticated legitimate services.
• ACP should define fail-open or fail-closed behavior per protected surface.
• Protected workflows should define rollback and recovery procedures before pilot use.
• Operational validation must confirm how relief, override, and quarantine behave under stress.

Example: false-positive relief through SIL

SIL does not put identity into BGP. SIL informs the Policy Engine, which may then adjust router-enforceable rules within operator policy.

SIL relief governance was exercised in staged IVD-N validation. A valid signed relief request was accepted within policy, an invalid signature was rejected, and cleanup confirmed no router state was changed.

During active mitigation, a legitimate registered service may be affected by a broad rule. SIL is intended to let that service submit an authenticated relief request. If the request is valid and policy allows it, the Policy Engine can narrow the rule, soften a drop action to rate-limit, or create a scoped exception while leaving the broader mitigation active. The relief action is logged, time-limited, and subject to operator policy.

These results support controlled-scope SIL governance claims. They do not claim universal preservation of all legitimate production traffic or live production router mutation.

SIL is not a guarantee that every legitimate flow will be preserved. It is a governance mechanism for authenticated, registered services. It does not remove the need for operator review, rule limits, expiry, rollback, and false-positive monitoring.

1. A mitigation rule is active.
2. A registered legitimate service detects impact.
3. The service submits a signed relief request.
4. The Policy Engine validates identity, prefix or scope, and safety limits.
5. The rule is narrowed, softened from drop to rate-limit, or left unchanged.
6. The decision is logged and time-limited.