IVD-ACP blocks unsafe execution influence before trust is granted.

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.

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-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.

Boundaries and non-claims

• It does not replace IAM, EDR, WAF, SCA, SBOM, SIEM, SOAR, sandboxing, code review, or human security review.
• It does not magically determine attacker intent.
• It does not guarantee every malicious artifact will be identified.
• It does not eliminate runtime controls.
• It does not prevent compromise by a fully authorized insider acting within legitimate authority.
• It does not make policy mistakes impossible.
• It does not claim production deployment across enterprise environments.
• It does not claim to have prevented named public incidents.

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.