IVD-ACP evaluates artifacts, commands, retrieved content, memory writes, and tool actions before they become execution-eligible in AI agents, RAG systems, software supply chains, and privileged automation.
In plain English, admissibility means checking whether an input should be trusted before it can act. ACP sits at specific admission points such as CI/CD gates, artifact intake, RAG pre-index boundaries, agent tool gateways, and administrative workflows. It decides whether an input is allowed, restricted, isolated, quarantined, or rejected before the protected system acts on it.
Deterministic authority states, system-external decision control, durable policy, quarantine, and replayable evidence turn "input filtering" into control-plane infrastructure.
External artifacts are evaluated before trust is granted, then assigned an explicit enforcement outcome after policy evaluation.
IVD-ACP evaluates inputs before they can execute, enter an index, trigger a tool call, or change state. It is intended for systems where origin-based trust is too weak because packages, prompts, scripts, and admin actions can become dangerous before downstream controls react.
The architecture is relevant to software supply chains, administrative portals, CI/CD workflows, orchestration tools, agentic AI systems, retrieval pipelines, and other environments where unsafe content can gain trusted authority.
Trusted systems often accept harmful inputs too early. Once content, commands, or artifacts are admitted into trusted memory or indexing flows, downstream controls are forced to clean up after the trust decision.
Inputs can be challenged before they enter retrieval pipelines, corpus stores, or agent memory, reducing persistence risk and model contamination risk.
Packages, commands, scripts, and control-bearing artifacts can be evaluated before execution is even eligible. The result can be ALLOW, READ_ONLY, SANDBOX, QUARANTINE, or REJECT depending on policy. In practice, a quarantined or sandboxed item may then be routed to review.
ALLOW, READ_ONLY, SANDBOX, QUARANTINE, and REJECT provide clear outcomes rather than vague monitor-only posture. The enforcement result is intended to be explicit and repeatable after policy evaluation.
The decisive layer is external to the system being protected, reducing opportunities for unsafe content to manipulate its own enforcement path.
Administrative portals, CI/CD workflows, agentic AI systems, retrieval-augmented generation, orchestration tools, and privileged APIs.
IVD-ACP is designed for software package or dependency intake, CI/CD workflow gates, artifact checks before indexing or execution, RAG pre-index control, agent or tool-call control, administrative command review, privileged workflow admission, and quarantine or audit of inputs that should not be trusted.
Concrete examples include an npm package entering a build, an AI agent requesting tool execution, a document entering a retrieval index, or an administrative command requesting mutation. In each case, ACP is meant to evaluate before trust or execution is granted.
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.
Different environments require different integration points. ACP does not claim to intercept every execution path in every enterprise environment.
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-ACP does not wait until content is already trusted. It checks whether an input should be trusted before execution, before indexing, and before high-impact actions are allowed into privileged surfaces. That keeps the decision explicit and reviewable.
A concrete example is an npm package or dependency entering a CI/CD workflow, an AI agent tool call, an administrative command, or a RAG document being proposed for indexing. ACP evaluates the item before it becomes trusted by the protected system.
IVD-ACP complements software composition analysis, EDR, WAF, IAM, SBOM work, CI/CD security, patching, sandboxing, and human review. The current posture is evaluation-ready and limited to controlled-environment review. The broader threat-model framing is on the Technology page.
Designed for documents entering RAG, vector stores, agent memory, enterprise knowledge bases, and automated workflows. The gate binds artifact identity, provenance, policy version, authority state, admission or quarantine outcome, and replayable evidence.
Designed for tool execution, administrative APIs, shell or infrastructure commands, database writes, CI/CD actions, external API calls, and other privileged effects. Action and authority context are evaluated before the protected system acts.
IVD-ACP does not promise universal interception. Commercial scope begins at a named admission surface with defined policy ownership, bypass assumptions, success criteria, and rollback behavior.
IVD-ACP is the execution-control side of IVD. It checks whether an input, command, or artifact should be allowed, isolated for safer handling, or quarantined before it reaches trusted systems.
In plain English, ACP is a before-trust checkpoint. It does not replace normal security tools; it gives the protected workflow an explicit decision before a risky input can act.
| Evidence area | Public-safe statistic | Plain-English meaning | Boundary |
|---|---|---|---|
| March formal ACP validation | 6 PASS / 0 FAIL | Six formal controlled scenarios produced expected decisions. | Controlled-environment validation. |
| Authority states | READ_ONLY, SANDBOXED, QUARANTINED observed | Inputs and actions were allowed, isolated, or blocked depending on risk. | Six formal scenarios. |
| March ACP telemetry | 48 telemetry export records | Supporting records were generated during validation. | Supporting telemetry. |
| March ACP expansion | 12 PASS / 0 FAIL | Additional ingestion matrix passed. | Not production proof. |
| March ACP soak | 120 PASS / 0 FAIL at concurrency 12 | Controlled soak behavior was stable in that test. | Not enterprise reliability proof. |
| March ACP performance | 3 x 250 requests / 0 errors | Controlled performance qualification output. | Not production throughput. |
| April ACP | 4 unique artifact hashes quarantined/blocked | Exploit-bearing or unsafe artifacts were recovered as blocked/quarantined evidence. | Controlled ingest evidence. |
These ACP results support controlled-environment admissibility and authority-state enforcement. They do not establish production hardening, enterprise accreditation, multi-tenant validation, or TRL-7 operation.
