Technical and Operational Questions, Answered.

Invariant Vector Defense (IVD) has two security prongs. It addresses two recurring failure modes: distributed traffic that becomes destructive after it concentrates on a target, and inputs or actions that become dangerous after they are admitted into trusted systems.

IVD-N addresses the first by detecting coordinated attack behavior earlier in the path and suppressing it before service impact. IVD-ACP addresses the second by enforcing an explicit and repeatable policy decision before any input, artifact, command, or AI-facing request receives trusted authority.

Distributed attacks and unsafe execution events both exhibit stable, measurable behavioral properties that persist despite surface-level variation. A botnet with millions of source IPs still exhibits consistent timing entropy, SYN proportions, packet size distribution, and interarrival variance. A poisoned artifact still presents structural characteristics that deviate from authorized execution patterns regardless of how it arrived.

IVD extracts those stable properties, called invariants, and uses them to make limited policy decisions. This allows the system to act on the underlying structure of an event rather than on individual packets, signatures, or source addresses that attackers can easily vary.

A Psi-vector is a compact traffic fingerprint derived from observable packet, header, and timing behavior. In plain English, it is a compact summary of stable behavioral features such as protocol mix, packet-size distribution, timing behavior, and other metadata features available in the tested environment.

It is not a claim of perfect mathematical invariance. It is a practical way to represent features intended to remain useful across common attacker changes so related traffic can be evaluated as one coordinated pattern rather than as millions of isolated flows.

A macro-object is not a new packet type or router object. It is IVD's limited internal representation of one coordinated traffic pattern after related traffic behavior has been grouped into a single decision unit.

For example, many related UDP flows in a controlled DNS-reflection-style scenario may be represented as one grouped attack object for policy decisioning. That lets the Policy Engine produce one limited mitigation action rather than attempting to track every flow individually.

In networking, the control plane is the layer responsible for routing policy, topology, and forwarding decisions, as distinct from the data plane which carries actual traffic. In software and AI systems, the control plane is the layer that governs what is allowed to execute, what receives trusted authority, and what is admitted into protected execution environments.

Most current defenses operate after traffic has already entered or execution has already occurred. IVD is designed to make policy decisions earlier: what should be suppressed, admitted, narrowed, isolated, or denied before harmful behavior concentrates or before unsafe inputs reach trusted execution.

IVD-N addresses availability: it identifies distributed hostile traffic earlier in the path and suppresses it before it can saturate your network edge or collapse your services. It is positioned at the routing and transit layer.

IVD-ACP addresses execution trust: it evaluates whether an artifact, command, AI prompt, API request, or retrieval input should be admitted into a trusted execution path before that trust is granted. It is positioned at application and system admission boundaries.

One protects network availability. The other protects execution authority. They share a decision pattern but operate at different points in the stack and can be deployed independently.

IVD was invented by Skip Middleton, President and Founder of Sinteag Ventures, Inc. Sinteag Ventures is a Florida-registered company with SAM.gov registration and CAGE/UEI vetting for federal engagement.

The architecture emerged from direct experience with the failure modes that large-scale distributed attacks expose: the gap between where current defenses operate and where the actual damage becomes irreversible. IVD is the product of that observation formalized into a patent-pending architecture with controlled-environment validation evidence supporting a TRL-6-style posture within tested scope.

IVD is a prototype-backed architecture with controlled-environment validation evidence and filed USPTO patent applications. It is not currently positioned as production-accredited enterprise software. The current posture is evaluation-ready, evidence-based, and now engaged in TRL-7-oriented independent testing, with federal lab evaluation held as a separate pending pathway.

Commercial discussions, design-partner engagements, and federal evaluation pathways are open. The goal is not to replace your current security stack; it is to add an earlier policy layer that reduces what that stack must handle.

Distributed attacks become most dangerous when traffic from many sources arrives at a target's network edge, DNS infrastructure, cloud identity layer, or routing infrastructure at the same time. At that point, physical bandwidth limits become the constraint and downstream mitigation may be too late.

IVD-N is designed to identify the coordinated structure of an attack earlier in the path and suppress it closer to where it originates. This reduces the volume of hostile traffic that ever reaches downstream infrastructure while preserving continuity for legitimate services.

IVD-N sits before or adjacent to the firewall path. It observes routing-layer telemetry and emits limited mitigation policy to participating routing infrastructure. The firewall remains downstream and continues its normal function. IVD-N is not inline, does not perform payload inspection, and does not require firewall rule changes to operate.

In a production deployment, IVD-N would typically be positioned adjacent to routing infrastructure, ISP edge points, transit or provider interfaces, or enterprise border routing depending on the deployment model.

Not for the core architecture or evaluation model. IVD-N used standard routing and lab infrastructure with FlowSpec-style policy behavior in its TRL-6 validation. It does not require proprietary firewall changes, endpoint agents, or packet payload inspection.

IVD-N affects routing and mitigation policy, not firewall security policy. In production, a customer may choose to integrate IVD with routers, SIEM, SOC workflow, or provider mitigation infrastructure. Those are deployment design decisions, not prerequisites for evaluation.

IVD-N requires packet header metadata and flow-level telemetry: IP headers, TCP/UDP flags, timestamps, and flow-level aggregates (NetFlow/sFlow format). No payload inspection. No application content. No user-identity enrichment required.

This is the same class of data used by standard network monitoring and flow analysis tools. In the evaluation model, telemetry is processed locally. There is no cloud dependency and no requirement to transmit traffic content to external infrastructure.

BGP FlowSpec (Border Gateway Protocol Flow Specification, RFC 5575) is a routing protocol extension that allows network operators to distribute traffic filtering rules to routers using the same BGP infrastructure already deployed for routing. Instead of configuring each router individually, a FlowSpec announcement can move mitigation rules through the routing fabric.

IVD-N uses FlowSpec-style signaling to send grouped-traffic mitigation rules toward source or transit networks where supported. This enables suppression at participating networks rather than only at the victim's edge. FlowSpec-v2 is a forward-looking extension that adds support for invariant-range matching, which is part of IVD's longer-term standardization path.

The Service Identity Layer (SIL) is the primary mechanism. SIL allows registered legitimate services with cryptographic identity to request adjustment of an active mitigation: changing drop behavior to rate limiting, narrowing scope, or preserving priority treatment during an active suppression event.

In TRL-6 testing, IVD-N reported zero observed false positives across defined benign scenarios, including flash crowd events, CDN cache bursts, and UDP-heavy legitimate traffic. Those results apply to the tested scenario set. Production false-positive governance is an evaluation design topic.

The Service Identity Layer (SIL) is the identity-aware exception and relief mechanism in IVD-N. Its purpose is to prevent mitigation from suppressing legitimate high-volume services alongside attack traffic.

A registered service with cryptographic identity can request adjustment of an active mitigation: changing drop behavior to rate limiting, narrowing scope, or receiving priority treatment. Relief-request mechanisms allow suppression to stay active against attack traffic while preserving continuity for authenticated legitimate services.

SIL is not a general identity system and not a replacement for IAM. It is a service identity and mitigation-relief layer tied specifically to traffic-control decisions.

No. IVD-N can operate inside one administrative domain for detection, classification, and limited policy generation. Single-domain deployment provides local value. Multi-provider participation increases the reach of suppression earlier in the path.

If other carriers do not accept FlowSpec rules, enforcement remains local or within participating networks. Detection and grouped attack-object handling still operate. The policy output can support local rate limiting, RTBH-style handling, provider escalation, or SOC workflow. Broader suppression depends on operator participation, routing policy, and FlowSpec acceptance.

Yes, because IVD-N does not rely on payload inspection. The invariant features it computes, such as packet size distribution, interarrival variance, SYN proportion, and bidirectionality, are observable from packet headers and flow records regardless of whether the payload is encrypted. Encryption does not mask the behavioral structure of a large-scale coordinated attack.

Mitigation rules are limited and time-limited by design. When the attack pattern falls below threshold, IVD-N is designed to issue a withdrawal through the same FlowSpec mechanism used to install the rule. This prevents indefinite suppression of traffic based on a transient attack event.

Withdrawal behavior and rule lifecycle management are part of the TRL-6 evidence package and are a key evaluation metric for confirming the system does not produce persistent false-suppression.

No. IVD is designed to make policy decisions earlier in the path. IVD-N complements DDoS mitigation, routing controls, SOC workflows, and downstream filtering. IVD-ACP complements IAM, EDR, WAF, SCA, SBOM, sandboxing, CI/CD security, and human review. It is not a replacement for those layers.

The detailed boundary language is on the Technology page.

AI pipelines, RAG (Retrieval-Augmented Generation) systems, administrative surfaces, and software execution paths share a structural gap: trusted authority is often granted implicitly. When an input arrives through a trusted channel, many systems execute, index, or act on it before asking whether it should be trusted.

IVD-ACP enforces an explicit and repeatable policy decision at the admission boundary: before execution, before indexing, before retrieval eligibility, and before privileged action. It shifts the model from implicit trust to controlled execution.

Any input that can lead to execution, indexing, retrieval, mutation, or privileged action at a protected boundary: software artifacts, administrative commands, AI prompts, API calls, retrieval requests, configuration payloads, orchestration instructions, tool-invocation requests, and memory-persistence inputs.

ACP checks structure, authority implication, and whether the input should be trusted under policy. It is not payload inspection in the DLP sense or application exploit signature matching in the WAF sense.

IVD-ACP assigns one of five explicit outcomes to each evaluated input:

ALLOW: input is permitted to proceed through the trusted path under policy.
READ_ONLY: input is viewed or summarized only; no state change, tool call, memory write, or execution.
SANDBOX: input is routed to isolated evaluation before any production effect is allowed.
QUARANTINE: input is blocked from trusted execution, indexing, or retrieval paths and retained for review.
REJECT: input is denied before admission to the protected workflow.

Outcomes are auditable, limited, and logged. The system does not require a binary allow or block decision; SANDBOX and QUARANTINE provide a graduated response appropriate to uncertainty or elevated risk.

Uncertainty is handled through outcome configuration rather than forcing a binary allow or block decision. An ambiguous input can be routed to SANDBOX for constrained execution or QUARANTINE for review rather than being REJECTED outright. This gives operators a way to tune risk tolerance without accepting unsafe inputs into trusted execution or blocking legitimate activity.

Policy thresholds, escalation paths, and outcome configuration are defined by the operator, not by IVD. ACP provides the enforcement architecture; the operator defines the rules.

Yes. ACP is not dependent on a language model to make security decisions. Its evaluation is policy-bound and structural: explicit scoring, rules, distance thresholds, stable representations, or other non-LLM mechanisms can drive outcome assignment.

ACP is designed to govern AI workflows, but it is not itself an AI system. The goal is evaluation that is explicit, repeatable after policy evaluation, and auditable, which is precisely the property that semantic AI-based filtering does not reliably provide.

IVD-ACP is positioned at admission boundaries inside the application and system layer: API gateways, administrative surfaces, software ingestion paths, AI workflow boundaries, RAG and vector-store indexing paths, orchestration systems, CI/CD-adjacent artifact admission points, and command-execution paths.

It is separate from the network firewall entirely. IVD-ACP and IVD-N do not need to be co-located or deployed together.

That depends on deployment point and policy configuration. In the controlled prototype, the focus was enforcement correctness rather than production-scale latency characterization. A production evaluation would include latency, throughput, and exception-handling measurements.

The intended deployment model is selective placement at high-risk admission boundaries, not inspection of every enterprise action. The first deployment surfaces should be narrow enough to evaluate cleanly and important enough to justify the control.

High-value administrative APIs, AI workflow tooling, RAG and vector-store ingestion pipelines, CI/CD-adjacent artifact admission, orchestration systems, and privileged command pathways. The first deployment should be narrow enough to evaluate cleanly and important enough to produce demonstrable value.

Pilot designs must define fail-open or fail-closed behavior by protected surface. IVD should not leave failure behavior implicit. Network and ACP deployments require explicit recovery, logging, rollback, and operator review procedures.

For ACP specifically, fail behavior should be defined per protected workflow, because the right default for a document-ingestion path may differ from the right default for a privileged command path.

TRL-6, Technology Readiness Level 6, is defined as prototype demonstration in a relevant environment. It represents a step beyond paper architecture and simulation-only theory, but does not yet claim production-scale operational deployment.

For IVD, this means controlled-environment validation evidence supporting a TRL-6-style posture within tested scope. External evaluators may classify maturity differently until independent replication is complete. The current package is intended for structured federal evaluation or design-partner engagement, while TRL-7 requires operationally representative third-party validation. Review validation scope.

No. IVD has controlled-environment validation evidence supporting a TRL-6-style posture within its tested scope. TRL-7-oriented independent testing is underway with Gear Six Labs, a European third-party software testing lab, with completion targeted for June 25, 2026.

Completion should not be described as achieved until the final report and evidence package are complete. Federal lab evaluation remains a separate pending pathway.

References to Gear Six Labs describe the current independent testing pathway and do not indicate completed TRL-7 validation until the final testing report is complete.

Not yet. IVD is preparing for federal lab evaluation and maintains evidence materials intended for qualified technical reviewers. Federal lab testing remains a separate next-step pathway from the current Gear Six Labs testing effort.

No. Exploit and incident references are architectural mapping examples. They do not claim IVD was deployed in, prevented, detected, or mitigated those incidents.

Testing confirmed the architecture's behavior within controlled scope. For IVD-N, the evidence confirmed that distributed traffic can be represented as grouped attack objects, converted into limited mitigation policy, and enforced through FlowSpec-style suppression in a 60-node FRR and Containerlab multi-AS environment without destabilizing routing. For IVD-ACP, testing confirmed pre-execution and pre-index enforcement: artifacts and commands were assigned explicit outcomes before reaching protected execution or indexing paths.

The threat slides and exploit cards show where the same failure classes appear in public incidents. They are architectural mapping examples, not incident-prevention proof.

Run 16 is the clean TRL-6 network baseline reference selected from a broader development and validation sequence. It demonstrated that the IVD-N prototype could detect distributed attack behavior as one grouped attack object, generate limited mitigation policy, and support FlowSpec-style enforcement in the 60-node testbed environment.

Key results from Run 16 and the broader tested scenario set: detection latency under 3 seconds from attack onset, 99.4 percent attack traffic reduction at the victim edge, and zero observed false positives across defined benign scenarios including flash crowd, CDN burst, and UDP-heavy legitimate traffic.

For IVD-N, the TRL-6 evidence reported zero observed false positives across the defined benign scenarios tested, including benign surge, CDN burst, flash crowd, and UDP-heavy legitimate traffic scenarios. That result applies to the tested scenario set, not to all possible production traffic patterns.

For IVD-ACP, false positives are governed through explicit outcomes. The system does not require a binary allow or block decision on every ambiguous case. It can ALLOW, READ_ONLY, SANDBOX, QUARANTINE, REJECT, or route to review depending on policy configuration. Operational environments require explicit false-positive governance, review, relief, and tuning.

False negatives are also possible. Operational validation must measure both false positives and false negatives rather than claiming full coverage.

The evidence package includes: frozen scenario artifacts (PCAP captures and JSON logs), a SHA-256 forensic hash registry for chain-of-custody, detection latency and suppression metrics per run, Principal Component Analysis (PCA) separation plots for macro-object discrimination, and testbed topology documentation (60-node Containerlab, FRR, GoBGP).

Artifacts are available to qualified reviewers. No testbed access is required for initial evidence review. An evaluation license provides access to the live testbed for evaluators who want to run defined attack scenarios directly.

Qualified reviewers may request controlled-environment validation summaries, structured audit logs, rule lifecycle records, ACP decision records, methodology notes, and hash-anchored evidence materials. Public site excerpts are intentionally limited and should not be treated as a substitute for technical diligence.

IVD has controlled-environment test evidence across both prongs. IVD-N testing focused on traffic-pattern observation, compact traffic fingerprinting, grouped attack-object formation, FlowSpec-compatible rule behavior, rule lifecycle handling, and evidence capture. IVD-ACP testing focused on pre-execution and pre-index decisioning, including read-only, sandbox, and quarantine outcomes for representative requests and artifacts.

These results are scoped to controlled test environments and should not be read as production deployment claims. Review what was tested.

No. IVD is designed to produce auditable policy decisions. The public site summarizes the tested surfaces and evidence categories. Qualified reviewers may request controlled-environment validation summaries, structured audit logs, rule lifecycle records, ACP decision records, methodology notes, and hash-anchored evidence materials.

No. Some evidence materials are reserved for qualified technical review because they may include sensitive implementation, testbed, or security details. Public excerpts are intended to describe scope, method, and evidence posture without substituting for full diligence.

For IVD-N: operation in a more operationally representative routing environment, ideally with real or replayed carrier-grade telemetry, more diverse router platforms, and realistic provider policy constraints.

For IVD-ACP: deployment against a live or near-live protected administrative API, AI workflow, retrieval pipeline, or orchestration boundary with sustained evidence capture and false-positive governance.

The objective of TRL-7 is not production certification. It is independent confirmation under more operationally realistic conditions and definition of the path to production readiness.

No. The 52-entry figure is not a coverage limit. It is an intentionally conservative external evidence set derived from the CISA Known Exploited Vulnerabilities (KEV) catalog.

The full 1,559-entry catalog was analyzed. An internal working corpus of 934 entries was identified as potentially relevant. From that, 52 entries were selected for the external-facing evidence set using three filters: direct mapping to before-trust admission-boundary failure, product or surface type in a management plane or control-bearing category, and exclusion of failures primarily unrelated to admission logic such as memory-safety, browser, or client-side rendering failures.

The 52-entry set keeps the external claim reviewable and defensible. It is not a claim that IVD-ACP addresses only those 52 entries.

The KEV-derived external shortlist identified five failure classes directly mappable to before-trust admission-boundary failures: Admission Failure (27 entries), Unsafe Execution Binding (14 entries), Authority Failure (4 entries), Control Plane Exposure (4 entries), and Retrieval-Mediated Influence (3 entries).

These represent confirmed exploitation events where the failure occurred at the same architectural point that IVD-ACP is designed to govern: the boundary between an external instruction and the trusted execution context it targets.

IVD-ACP is directly relevant to the threat class where adversaries exploit AI orchestration infrastructure. Confirmed exploitation of Langflow (CVE-2025-3248) and malicious MCP (Model Context Protocol) server impersonation demonstrate that AI workflow and pipeline surfaces are active exploitation targets. These are admission boundaries where inputs can gain trusted authority without explicit policy enforcement: exactly the gap IVD-ACP addresses.

IVD-N is relevant where AI-accelerated attack generation produces observable correlated distributed network behavior at the traffic-pattern layer.

IVD-ACP is relevant to the subset of supply chain attacks that occur at software ingestion, artifact admission, and execution boundary points. When a malicious package, poisoned artifact, or compromised update arrives at a protected admission boundary, ACP can check whether the input should be trusted before execution is granted. The failure mode in most supply chain compromises is implicit execution: trusted delivery channels are abused because execution follows delivery without a policy gate in between.

IVD-ACP does not address the compromise of software providers, repositories, or build chains earlier in the delivery path. It addresses the admission decision at the end of that path.

IVD-ACP addresses control points that ransomware operators increasingly abuse: privileged administrative actions, script execution, policy changes, credential access, and management-plane requests. Ransomware staging and detonation chains depend on trusted admin surfaces and payload admission. ACP constrains those admission decisions.

IVD does not claim to stop ransomware as a categorical statement. It addresses the policy-decision failure modes that advanced ransomware campaigns exploit during staging and lateral movement.

IVD-N is relevant where state-sponsored activity produces coordinated distributed network behavior observable at the traffic-pattern layer: for example, coordinated edge-device exploitation producing correlated botnet or relay traffic. IVD-ACP is relevant where state-sponsored intrusions abuse trusted administrative pathways, orchestration systems, or management-plane actions to establish persistence and move laterally. Both failure modes are documented in publicly reported state-sponsored activity consistent with China-nexus and Russia-nexus tradecraft.

No. They share a doctrine but operate at different enforcement points and can be deployed independently.

IVD-N is a network-control deployment: edge telemetry observation, regional synthesis, policy engine, FlowSpec controller, and routing enforcement earlier in the path.

IVD-ACP is an admission-control deployment: API gateways, administrative surfaces, AI workflow boundaries, RAG and vector-store indexing paths, orchestration systems, or command-execution paths.

Yes. IVD is designed as a complementary policy layer. IVD-N operates from telemetry and routing-policy integration without replacing firewalls, EDR, SIEM, WAF, IAM, or scrubbing centers. IVD-ACP operates at selected admission boundaries without replacing IAM, EDR, secure coding, or vulnerability management.

The design goal is to reduce what reaches downstream controls or what is admitted into trusted execution, not to replace the existing security stack. In production, integration would still require normal change control and coordination with network and application owners.

Yes. An evaluation or initial deployment can begin in observe-and-report mode. For IVD-N, that means telemetry ingestion, grouped attack-object detection, and policy recommendation without active enforcement. For IVD-ACP, that means outcome scoring and audit logging before enforcement is activated. Monitor mode is the recommended starting point for any evaluation engagement.

The customer or evaluator. IVD provides the architecture for evaluation and limited enforcement. The operator defines thresholds, enforcement actions, exceptions, approval paths, and escalation rules appropriate to their environment. IVD does not impose autonomous blocking without operator-defined policy.

IVD can be configured for observe-only, recommendation, human approval, or limited automated enforcement. The architecture supports automation, but the operator defines when and how enforcement is permitted. For early evaluation, observe-only or recommendation mode is the appropriate starting point.

Any system that can influence enforcement must be treated as sensitive infrastructure. IVD's design addresses that by separating observation, decision, and enforcement; logging all policy actions; limiting rule generation; and using cryptographic identity for relief and exception paths. A production deployment requires normal hardening, authentication, change control, and monitoring.

Adversarial mimicry and model poisoning are identified as hard remaining risks and are planned TRL-7 evaluation topics. Those risks are one reason the requested next step is structured evaluation rather than immediate production deployment.

IVD is designed to produce structured event logs, policy decisions, outcome assignments, mitigation-rule lifecycle records, relief-request records, rule withdrawal records, and evidence bundle hashes. The goal is not just enforcement, but reviewable enforcement: every policy action should produce an auditable record suitable for compliance, forensic review, or evaluation assessment.

No. IVD-N does not require packet payloads or application content. Evaluation can be structured around header-derived and flow-level telemetry, replay data, synthetic traffic, or lab-generated PCAPs. IVD-ACP evaluation can be structured around representative commands, artifacts, or test inputs rather than live sensitive production data. Data handling, retention, and sovereignty are evaluation design decisions.

Scrubbing generally acts after traffic has already concentrated toward the victim or scrubbing center, where physical bandwidth constraints are often already engaged. IVD-N is designed to identify attack structure earlier and support suppression closer to ingress or transit points. It does not replace scrubbing. It reduces the volume pressure that scrubbing centers must absorb.

IVD-N is not just anomaly detection. The architectural claim is detect, group, decide, enforce, and audit. The grouped attack object, or macro-object, can drive mitigation policy. A monitoring tool tells you something is happening. IVD-N is designed to produce a limited policy decision that enables enforcement before traffic concentrates at the protected edge.

IAM (Identity and Access Management) determines who is authenticated and what permissions are assigned to an identity. A valid, authenticated user with appropriate permissions can still submit a dangerous command, a poisoned artifact, or a prompt that generates an unauthorized action. IAM does not evaluate the content, structure, or authority implication of what that authenticated user submits.

IVD-ACP evaluates whether a specific input should be admitted into a trusted action path after identity is established: a separate and later decision point. The two are complementary, not competitive.

Endpoint Detection and Response (EDR) generally observes or responds on endpoints during or after execution activity: it detects malicious behavior that has already reached and begun executing on a host. ACP sits before selected execution or indexing paths and assigns an outcome before the input becomes trusted. It is not a replacement for EDR; it reduces the chance that unsafe inputs reach the point where EDR has to respond.

A WAF (Web Application Firewall) or API security tool generally filters web and API traffic against signatures, behavioral rules, schema validation, or application-layer patterns. ACP is focused on whether artifacts, commands, retrieval inputs, orchestration requests, and authority-bearing actions should be trusted before they receive execution status.

ACP can be deployed adjacent to an API gateway, but its decision model is about execution authority, not request filtering. The scope extends beyond web and API traffic to include AI workflow inputs, software artifacts, administrative commands, and retrieval-path content.

Prompt filtering operates inside or near the AI interaction layer and typically relies on semantic judgment about prompt content: whether a prompt appears harmful, is trying to bypass safety rules, or is classified as a specific attack type. This judgment is probabilistic, can be bypassed by rephrasing, and operates only on prompts.

ACP is broader and earlier. It can govern artifacts before indexing, retrieval eligibility, tool invocation, memory persistence, administrative action, or execution. The goal is not to filter prompts; it is to decide what receives trusted authority at the admission boundary, regardless of the input type.

SIEM (Security Information and Event Management) aggregates, correlates, and alerts on security events after they occur. It is fundamentally a detection and response tool: it tells you what happened. ACP is a pre-execution enforcement tool: it determines what is allowed to happen before it occurs. The two are complementary; ACP's audit logs and authority-state records would naturally feed into a SIEM workflow.

IVD-N is most relevant for environments where availability and routing stability are mission-critical: telecommunications, cloud infrastructure providers, internet exchange operators, financial services (payment networks, trading infrastructure), energy and grid operators, defense networks, and federal government systems.

IVD-ACP is most relevant for environments where execution trust is a growing risk: AI platform operators, enterprise AI and RAG pipeline operators, federal and defense administrative systems, critical infrastructure control systems, software supply chain participants, and any organization deploying autonomous or agentic AI workflows.

Yes. IVD-N addresses the network availability dimension of critical infrastructure protection: suppressing distributed attacks before they saturate communications links connecting operational technology (OT) networks, SCADA systems, and grid control infrastructure. For environments where a saturated communications link directly translates to loss of supervisory control, upstream suppression is a relevant capability.

IVD-ACP addresses the execution trust dimension: protecting administrative interfaces, update pathways, and configuration surfaces from unauthorized or unsafe commands before they reach control-bearing systems.

Directly. As AI agents, orchestration frameworks, and RAG pipelines are embedded into enterprise operations, the admission boundary between external instructions and trusted execution becomes a structural attack surface. IVD-ACP is designed for precisely that boundary: evaluating whether an AI-facing input, tool call, retrieval request, or agent action should be admitted into trusted execution before the AI system processes or acts on it.

For AI platform operators, this is a control-sovereignty question: ACP enforces your policies, not Sinteag's.

Yes for both prongs. IVD-N is relevant to the availability and routing stability of cloud network infrastructure, where distributed convergence events directly impact multi-region service availability, BGP routing stability, and cloud identity infrastructure. IVD-ACP is relevant to API gateway surfaces, AI workflow infrastructure, and orchestration pipelines that cloud platforms operate on behalf of enterprise customers.

Use the contact form on this site or email [email protected]. The standard first step is an architecture package and TRL-6 evidence summary, available without NDA. Full internal specifications, ACP policy model detail, and SIL design documentation are available under NDA. Live testbed access is available under an evaluation license.

Step 1 - Evidence Package Review. Qualified reviewer access to controlled-environment evidence artifacts. No NDA required for the external evidence package.

Step 2 - Internal Architecture Review. Signed NDA for full internal specification, ACP policy model, and SIL design documentation.

Step 3 - Live Testbed Demonstration. Evaluation license for access to the 60-node Containerlab environment. Evaluator can run defined attack scenarios directly.

Step 4 - Federal Lab or Independent Validation. Structured evaluation under an appropriate federal lab or equivalent independent framework. Funding model and scope to be determined by evaluation pathway.

A defined-scope technical evaluation with two tracks: IVD-N replay and routing validation in a lab topology, and IVD-ACP admission-control validation against representative inputs. The objective is not production certification. It is independent confirmation of grouped attack-object detection, limited policy behavior, outcome enforcement, auditability, and operational limits.

Failure would be informative if specific.

For IVD-N: inability to form stable macro-objects, excessive false positives in benign traffic, uncontrolled rule generation, route instability, or poor withdrawal behavior under cleared or controlled conditions.

For IVD-ACP: bypass of admission logic, inconsistent outcome assignment, inability to prevent pre-index admission, excessive false positives, or mutation of the decision path from within the protected execution environment.

Identifying failure modes clearly is part of the evaluation design and informs TRL-7 criteria.

For IVD-N: production-scale telemetry diversity, cross-AS governance, router-vendor platform differences, and adversarial traffic mimicry designed to evade invariant-based detection.

For IVD-ACP: connector coverage across diverse execution environments, production-scale latency characterization, policy tuning under operational conditions, false-positive governance at scale, and hardening against bypass in complex enterprise workflows.

Two non-provisional USPTO utility applications are pending: Application 19/458,205 (IVD-N) and Application 19/456,364 (IVD-ACP). Both are anchored to a November 2025 provisional application (63/919,908). Patent applications are pending; claims have not yet been issued.

No. IVD is proprietary architecture with pending patent claims. Architecture white papers, abstract documents, and the TRL-6 external evidence package are publicly available for review. Internal specifications, policy models, and testbed access require NDA or evaluation license engagement.

A USPTO application means non-provisional utility patent applications have been filed and are pending examination. The priority date is established. Claims have not yet been issued, examined, or granted. Federal reviewers and technical evaluators should treat the IP position as pending, not as granted claims. The applications cover the dual-prong architecture described in the white papers and technical documentation.

Sinteag Ventures is registered and active on SAM.gov with CAGE/UEI vetting. The current posture is document-first: architecture materials, controlled-environment evidence packages, and evaluation packages are being prepared or submitted for technical review through appropriate channels.

TRL-7-oriented independent testing is underway with Gear Six Labs, a European third-party software testing lab, with completion targeted for June 25, 2026. Federal lab evaluation remains a separate pending pathway. The goal is structured independent evaluation, not immediate procurement, accreditation, or implied endorsement.