Securing the Fusion of Quantum Computing and Agentic AI

October 22, 2026

The convergence of quantum computing and agentic artificial intelligence creates a security problem that cannot be solved by treating quantum readiness, AI security, and Zero Trust as separate initiatives. Quantum computing places pressure on public-key cryptography used to authenticate identities, establish keys, sign software, and protect long-lived information. Agentic AI expands the number and speed of security-relevant actions: agents select tools, access data, call APIs, generate artifacts, delegate subtasks, and initiate workflows with limited human intervention. Quantum-computing services add a specialized execution domain in which job submission, compilation, orchestration, hardware control, facility systems, and research results must be separated and governed.

This post synthesizes three related treatments: an integrated quantum-agentic enterprise architecture; the effect of quantum risk on Zero Trust; and a Zero Trust reference design for quantum-computing infrastructure. It proposes a unified, resource-centric architecture in which every user, agent, workload, job, tool call, dataset, privileged operation, and quantum-service transition is explicitly authenticated, authorized, constrained, logged, and reassessed. Post-quantum cryptography (PQC), cryptographic discovery, crypto-agility, protected key management, software provenance, workload isolation, attestation, and continuous assurance underpin—but do not replace—policy enforcement.

The central conclusion is that Zero Trust remains applicable, but its implementation must expand beyond human-and-device access to include autonomous delegation, model-influenced actions, quantum-job lifecycles, hardware-management boundaries, and the durability of cryptographic evidence. The architecture and migration plan are proposed guidance, not a published standard. They should be tailored to platform capabilities, risk tolerance, and applicable standards. Read below to find out more from Active Cyber™ and check out the Active Cyber Zone podcast series on this topic at Buzzsprout or your favorite podcast providers.

---

Introduction: one security problem across two technology transitions

Classical enterprise security generally assumes that applications execute within defined software boundaries, that workflows are substantially designed in advance, and that identity and access controls are applied to users, devices, services, and transactions. Agentic systems weaken the predictability of that model: a model may interpret an objective, choose a sequence of actions, call external tools, consume untrusted content, and delegate work. Quantum computing introduces a different pressure. A sufficiently capable, fault-tolerant quantum computer could use Shor’s algorithm to threaten widely deployed RSA and elliptic-curve public-key mechanisms. The concern extends beyond confidentiality to authentication, certificate chains, digital signatures, software integrity, and the trust anchors that Zero Trust systems rely on.

Quantum readiness is not merely an algorithm replacement exercise. It requires a cryptographically agile enterprise that can discover dependencies, prioritize risks, modernize trust infrastructure, and change algorithms without redesigning every application.

Agentic AI makes this problem more complex because autonomous workloads generate additional identities, certificates, APIs, credentials, and cryptographic transactions. If the agent’s certificate chain or signature mechanisms are vulnerable, authentication evidence could become less trustworthy. If its credentials are stolen or its permissions are too broad, PQC alone will not stop unauthorized access. And if a prompt injection attack manipulates the agent, cryptographic protection does not prevent it from making a harmful but properly authenticated request.

This is why a converged architecture must combine quantum-resistant cryptography with least privilege, scoped credentials, explicit delegation, runtime guardrails, and independent authorization at the resource boundary.

The implication is clear: cryptographic trust must become a managed, observable, policy-driven infrastructure service rather than a collection of hard-coded application dependencies.

The convergence is architectural rather than a claim that quantum processors are already routinely used by AI agents. A near-term enterprise may run agents on conventional cloud infrastructure while accessing a remote quantum-computing service for selected workloads. The same enterprise still must protect agent identities, job brokers, orchestration services, API gateways, cryptographic services, datasets, and vendor interfaces. Over time, AI may help design, optimize, schedule, or analyze quantum workloads, increasing the coupling between autonomous decisions and specialized compute resources.

The design objective is therefore a cryptographically resilient autonomous enterprise: one that can identify every relevant principal and workload, constrain authority, protect data in transit and at rest, isolate execution, verify artifacts and environment evidence, observe behavior, and recover safely when assumptions fail.

Scope and essential distinctions

Quantum computing, PQC, and quantum communications are different

Quantum computing is a computational technology and a potential threat to some current cryptographic assumptions. Post-quantum cryptography uses conventional computing to implement algorithms designed to resist relevant quantum attacks. NIST’s first three finalized standards are ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. Quantum key distribution (QKD), by contrast, uses specialized quantum communications infrastructure and is not a general substitute for PQC. Most organizations should begin with cryptographic inventory, risk-based PQC migration, and crypto-agility rather than assuming that they need quantum hardware or QKD.

Zero Trust is a decision and enforcement model

Zero Trust is not a single product or a synonym for network segmentation. Its core idea is to avoid implicit trust based on network location or prior authentication. A policy decision should consider the requesting subject, target resource, requested action, context, and current evidence. Policy enforcement points must make the decision effective at the actual access boundary. Authentication establishes identity evidence; authorization determines whether a specific action is allowed. Neither a valid certificate nor successful attestation grants unrestricted permission.

Quantum hardware is not just another server

A customer may not be able to install endpoint agents or arbitrary enforcement software on a quantum processing unit (QPU), cryogenic controller, laser system, or vendor-managed hardware plane. Controls must therefore be concentrated at supported interfaces: identity-aware gateways, job brokers, orchestration APIs, dedicated administrative paths, vendor controls, physical security, and platform-provided telemetry. The architecture must state which controls are enforced by the customer, which by the provider, and which are shared.

Related work. Zero Trust for quantum computing is an emerging topic. A collaboration between IonQ and the Applied Research Laboratory for Intelligence and Security (ARLIS) has been announced to apply NIST SP 800-207 to future quantum computers, and academic surveys of quantum cloud security describe job submission, queuing, and execution flows and multi-tenant risks such as crosstalk and side channels. The public material reviewed for this post does not specify separating the job-submission plane from hardware and facility management, or assigning controls explicitly to customer, provider, and shared responsibility. This paper makes both explicit.

Quantum and Zero Trust Convergence

Quantum computing changes the strength and longevity of the cryptographic foundations on which Zero Trust depends; it does not change the need to verify every access request or enforce least privilege.

For security architects, the goal is a Zero Trust environment in which identities remain verifiable, communications remain protected, software integrity can still be established, and cryptographic mechanisms can evolve as threats and standards change. In an agentic enterprise, that resilience must extend to autonomous agents, their credentials, their tool calls, and the authority they delegate.

The strategic principle is simple: Zero Trust determines whether access should be allowed; quantum-resistant security helps ensure that the evidence used to make that decision remains trustworthy.

Related work. The relationship between post-quantum cryptography and Zero Trust is already discussed in industry analyses. Several vendor papers describe cryptography as a foundation of Zero Trust, and one proposes adding cryptography as a separate pillar in the CISA Zero Trust Maturity Model. This paper makes a narrower claim. It separates the policy decision from the evidence the decision consumes (identity assertions, device and workload attestations, signatures, and logs), and it treats quantum risk as a threat to the durability of that evidence rather than to the decision logic itself.

Threat model for the converged environment

The architecture should account for adversaries and failures across both classical and quantum-service domains:

• Cryptographic compromise: future quantum capability, harvest-now/decrypt-later collection, weak implementation, key theft, signature forgery, or downgrade to a disallowed algorithm.
• Agent manipulation: prompt injection through documents, websites, tool output, or messages from another agent; unsafe planning; confused-deputy behavior; or unauthorized delegation.
• Identity and authorization abuse: stolen tokens, over-privileged service identities, confused ownership, long-lived credentials, or inability to revoke an active agent and its descendants.
• Supply-chain compromise: malicious agent packages, plugins, model files, libraries, compiler components, container images, signed artifacts, or compromised build/signing systems.
• Quantum service abuse: unauthorized job submission, resource exhaustion, circuit or configuration tampering, result exfiltration, cross-tenant leakage, or attempts to reach privileged hardware-control functions.
• Control-plane compromise: compromise of policy engines, job brokers, identity providers, cryptographic services, logging, or management interfaces that can affect many workloads.
• Operational and vendor risk: incompatible PQC implementations, unavailable attestation evidence, opaque provider boundaries, unsafe maintenance access, or migration-induced outages.

Security claims should be bounded. PQC does not stop prompt injection; guardrails do not repair vulnerable key exchange; signatures do not prove that signed software is benign; attestation proves only defined properties of a measured environment under a particular trust model; and Zero Trust policy cannot be stronger than the integrity and availability of the policy decision and enforcement infrastructure.

Extensions to the attack surface: model distillation and version control

Model Distillation, Extraction, and Intellectual-Property Risk

Model distillation is a legitimate technique for transferring capabilities from a larger “teacher” model to a smaller “student” model. The security threat arises when an unauthorized party uses model queries, outputs, or other privileged access to reproduce a proprietary model’s capabilities.

In a converged AI-agent and quantum-computing environment, the assets at risk extend beyond model weights.

• Proprietary AI capabilities: reasoning patterns, specialized fine-tuning, model behavior, and commercially valuable functionality.
• Agent workflows: privileged tool sequences, multi-agent orchestration logic, and domain-specific decision processes.
• Quantum algorithms and workflows: proprietary circuit-generation strategies, optimization methods, hybrid algorithms, and specialized problem-solving techniques.
• Sensitive data and outputs: training examples, retrieved information, quantum-job results, and intermediate artifacts that may reveal intellectual property.

Quantum computing should not be treated as automatically making distillation easier. The more immediate risks arise from scalable API access, autonomous agents that can automate query campaigns, compromised credentials, and access to proprietary workflow outputs. Future quantum capabilities may change parts of the cryptographic threat landscape, but they do not eliminate the need for model-extraction defenses.

Version Control in an Agentic and Quantum World: A New Security Problem

The acceleration of agent-generated code creates a significant security and governance problem for version control. The problem is not simply whether Git or another source-control system can handle more commits. It is whether an organization can preserve provenance, verify correctness, enforce security policy, and maintain human accountability when AI agents generate, modify, test, and deploy software faster than traditional development processes can review it.

Quantum computing adds a second dimension: software may increasingly combine classical code, AI-generated orchestration, quantum circuits, specialized algorithms, and remote quantum services. These components may evolve at different speeds, depend on different toolchains, and require different validation methods.

The result is a mismatch between the speed of software creation and the speed at which an enterprise can establish trust in that software.

Traditional development assumes a relatively understandable sequence:

1. A developer writes code.
2. The developer commits a change.
3. Automated tests run.
4. A reviewer approves the change.
5. The change is merged and deployed.

Agentic development changes that sequence. Multiple agents may independently modify the same codebase, generate thousands of changes, open pull requests, update dependencies, repair failing tests, and respond to security findings. Some agents may work continuously without a human explicitly reviewing every intermediate step.

In a quantum/AI environment, agents might also generate quantum circuits, tune parameters, modify hybrid workflows, or change the classical code that submits and interprets quantum jobs.

The fundamental challenge is that a commit is a record of a change, not proof that the change is safe.

Version control can preserve history, but it cannot by itself establish that an agent understood the business requirement, that its tests are adequate, that it did not introduce a subtle vulnerability, or that the deployed artifact corresponds to the reviewed source.

This introduces a new threat model: code velocity can exceed assurance velocity.

Generation velocity – High

Many agents create changes in parallel, repeatedly and autonomously.

Assurance capacity – Constrained

Testing, review, security analysis, and validation consume time and resources.

The dangerous gap: when change generation outpaces verification, organizations may accumulate unreviewed changes, skip controls to keep delivery moving, or mistake successful tests for proof of security.

This creates several specific attack paths:

Threat	How it arises	Potential consequence
Malicious or compromised agent	An agent inserts an insecure dependency, backdoor, or unauthorized change	Supply-chain compromise
Review overload	Reviewers approve changes they cannot thoroughly understand	Vulnerabilities reach production
Agent identity confusion	Multiple agents share credentials or make unattributed commits	Weak accountability and difficult incident response
Test manipulation	An agent changes tests to pass its own implementation	False confidence in correctness
Dependency drift	Agents independently update packages, libraries, models, or toolchains	Reproducibility failures and new vulnerabilities
Race conditions	Concurrent agents overwrite, conflict with, or invalidate each other’s changes	Broken controls or unreviewed code entering a release
Quantum-workflow integrity failure	Generated circuits or hybrid orchestration logic change without suitable validation	Incorrect results, data exposure, or expensive unauthorized jobs

These risks align with established software supply-chain concerns. NIST’s Secure Software Development Framework recommends integrating security practices throughout development, while Supply-chain Levels for Software Artifacts (SLSA) provenance records how an artifact was produced and supports verification of its origin. Neither framework alone fully solves agent autonomy, so they need to be extended with agent-specific identity and policy controls.

Quantum workloads require a richer versioning model

Ordinary source control records the code. For hybrid AI/quantum workloads, that is only one part of the reproducibility and security record.

A useful model is to version the complete workload configuration and execution provenance.

Component	What must be recorded
Classical source	Commit, content digest, dependencies, build configuration
Agent	Agent identity, orchestration code, policy version, tool permissions
AI model	Model identifier and version, relevant configuration, prompt templates and retrieval configuration
Quantum program	Circuit or algorithm version, parameters, transpiler/compiler version, optimization settings
Quantum backend	Provider, backend identifier, relevant calibration snapshot or execution metadata where available
Execution	Job ID, timestamp, authorization decision, random seeds where applicable, relevant measurement and error-mitigation settings
Results	Output integrity, provenance links, validation results, and permitted data-retention policy

There is an important distinction here: versioning an experiment is not the same as guaranteeing an identical result. Quantum measurements can be probabilistic, and hardware calibration, noise, provider-managed execution, and backend changes can affect results. The goal is to preserve enough evidence to understand, validate, and—where feasible—reproduce an execution, not to promise bit-for-bit identical output in every run.

This is also a security issue. If an agent silently changes a circuit optimizer, transpiler version, or backend selection, it could alter results, expose data to an unapproved service, or increase resource consumption without changing the application’s apparent high-level purpose.

Security reference architecture and controls

Deploying Zero Trust Architecture (ZTA) directly on quantum-computing infrastructure requires a design that protects more than conventional enterprise applications. It must secure the classical computing environment, the quantum processor and its control systems, the orchestration and workload-management layers, the research data, and the interfaces connecting users and applications to quantum resources.

The defining architectural principle is:

No user, workload, administrator, service, device, or external provider receives implicit trust merely because it is inside the facility, belongs to the organization, or has already authenticated. Every access request must be authorized for a specific resource and operation.

Quantum-computing infrastructure introduces an important distinction: most present-day quantum computers are controlled through classical computing systems. Users submit jobs through software interfaces; classical processors compile and optimize circuits; orchestration services schedule jobs; control systems translate instructions into hardware operations; and measurement results return through classical data pipelines. The exact architecture differs among superconducting, trapped-ion, neutral-atom, photonic, and other platforms.

Consequently, the reference design should apply Zero Trust to the complete quantum-computing service—not assume that conventional network security alone can protect the quantum processor.

This design is a proposed architecture informed by established Zero Trust principles, post-quantum cryptographic standards, and quantum-platform engineering considerations. It is not a claim that every quantum-computing vendor exposes the same control interfaces or permits customer-level control over the processor’s lowest-level systems.

The architecture integrates a cryptographic-resilience model with the security controls needed for autonomous agents. The architecture combines seven foundational control layers with a quantum-service execution path. The quantum-service path adds boundaries for research access, agent access, job submission, compilation and scheduling, execution, hardware/facility management, and result handling. There are also four cross-cutting trust layers: PQC and cryptographic agility; continuous validation, testing, and recovery; agent-aware change control and versioned execution provenance; and model distillation and extraction defense.

The foundational layers represent logical control domains, not a requirement to deploy seven separate products.

Foundational Layers

Layer 1 — governance, risk, and accountability

Define risk ownership, approved algorithms, data classifications, confidentiality lifetimes, agent autonomy limits, supplier requirements, and the transactions that require human approval. Separate authority to propose an action from authority to execute it. For example, an agent may prepare a quantum experiment or submit a job for review, while approval to use a scarce production QPU, export sensitive results, or modify platform configuration may require an independent policy decision or human authorization. Quantum risk should also be included in data-governance decisions. Information that must remain confidential for decades may require migration prioritization even when the underlying system has no known present-day cryptographic compromise.

Layer 2 — identity, authorization, and delegation

At least four related identities must be managed: the agent software identity; the running workload identity; the principal that authorized the task; and the specific delegated authority. A quantum job should also carry an attributable job identity, owner, purpose, dataset scope, resource budget, expiry, and parent-task linkage. Use short-lived credentials, narrow scopes, workload identity, explicit delegation tokens, and rapid revocation. Child agents should receive only the capabilities needed for their assigned subtask, not the parent’s general credentials. These identities and relationships must be cryptographically verifiable, but a valid signature alone does not grant permission to perform an action.

A valid identity answers “who or what is making this request?” It does not answer “should this request be allowed?” Authorization should be evaluated separately at sensitive resource boundaries, including each tool call, data export, job submission, result retrieval, and privileged management action.

Quantum-resistant digital signatures become relevant to the long-term integrity of identity systems, certificates, software artifacts, and policy distribution. ML-DSA and SLH-DSA provide standardized post-quantum signature options, subject to implementation and interoperability requirements.

A critical design principle is that agent identity must remain stable as cryptographic mechanisms evolve. Rotating an agent’s signing key or replacing a certificate should not require rebuilding the entire agent ecosystem.

Layer 3 — software supply chain

Establish a verifiable chain of custody from agent-generated source code through build, approval, packaging, and deployment. Record the source commit, initiating task, agent identity, parent version, and change history for every agent-generated change. Generate signed build provenance identifying the source, builder, build process, dependencies, and output artifact digest. Generate and maintain software bills of materials (SBOMs) for software and relevant dependencies; track AI models, model adapters, datasets, and quantum SDKs where applicable. Verify artifact signatures, digests, provenance, and approved origin before deployment or execution. Use isolated, controlled build environments with restricted network access, scoped credentials, and protected pipeline configurations. Separate the authority to propose changes, approve releases, administer build infrastructure, and sign production artifacts. Prevent agents from bypassing required checks, modifying protected release branches, or approving their own high-risk changes. Pin dependencies and record versions of compilers, libraries, models, prompts, policies, and relevant build tools. Maintain immutable or tamper-evident records linking source changes to approved builds and deployed artifacts. Support artifact revocation, quarantine, and rollback when provenance is missing, invalid, or associated with a compromised component. Record quantum-circuit source, transpiler/compiler versions, optimization settings, and available backend execution metadata. Prevent unapproved model weights, agent plugins, tools, Model Context Protocol (MCP) servers, and quantum workflow components from entering production.

Layer 4 — registry and deployment

Treat agent marketplaces, model registries, plugin repositories, quantum circuit libraries, compiler components, and deployment pipelines as trust boundaries. Before deployment, validate publisher provenance, source and dependency risk, model/configuration versions, tool permissions, network destinations, data retention behavior, prompt-injection exposure, signatures, and cryptographic dependencies. Build pipelines should generate an SBOM and, where technically feasible, a cryptographic bill of materials (CBOM) identifying cryptographic dependencies. The CBOM should be linked to application ownership, certificates, keys, libraries, protocols, and the systems relying on them. Verify signatures and provenance at deployment and, where supported, before execution.

The quantum-resilient services are not a replacement for the Zero Trust policy engine. They underpin the mechanisms that establish identities, protect sessions, verify integrity, and provide evidence on which the policy engine relies. Quantum migration then becomes part of DevSecOps rather than a one-time infrastructure exercise.

A deployment gate might reject an agent that introduces a disallowed cryptographic dependency, uses an unsigned artifact, requests unjustified privileges, or lacks required security tests.

The gate should also recognize the difference between a cryptographic algorithm being quantum-vulnerable and a system having an exploitable vulnerability today. Policies must prioritize actual exposure and business risk rather than simply counting algorithm references.

Layer 5 — secure agent runtime and tool enforcement

The model must not be the final security authority for its own actions. Place a policy-enforcing tool gateway between agents and APIs, data stores, code execution, cloud control planes, and quantum job brokers. Validate tool name, arguments, target, data scope, quota, risk, and delegation chain. Use sandboxing or workload isolation; egress allowlists; input and output validation; secret isolation; data-loss prevention; resource and rate limits; delegation-depth limits; and independent approval for high-impact or irreversible operations. Treat retrieved content and tool output as untrusted data, even when it is correctly signed.

The Zero Trust control plane makes and enforces decisions for every sensitive operation. It should evaluate more than whether a login succeeded:

• Access request – Who is requesting access? Which quantum resource? Which operation? Which dataset or job?
• Policy decision point – Evaluate identity, authentication strength, workload provenance, resource sensitivity, current risk, job attributes, and approval requirements.
• Permit – Issue narrowly scoped authorization and enforce it at the target service.
• Deny or contain – Reject the request, quarantine the workload, or require additional approval.
• Continuous monitoring and reassessment – Record the decision, detect anomalies, expire credentials, revoke access and respond to incidents.

The Zero Trust policy engine should consider the following signals.

• Identity: user, agent, service, administrator, or vendor identity.
• Authentication: multifactor authentication (MFA) status, credential freshness, certificate validity, and supported cryptographic mechanisms.
• Workload integrity: approved software image, signed artifacts, provenance, and attestation evidence when available.
• Requested operation: submit a job, view results, modify a schedule, change calibration, update firmware, or access facility controls.
• Resource sensitivity: public test environment, proprietary research, restricted data, production QPU, or critical control interface.
• Operational context: job cost, resource consumption, unusual access patterns, export restrictions, and approval status.
• Delegation: whether an agent is acting within authority explicitly granted by a human or another authorized service.

A valid identity must not automatically imply permission to modify the hardware, access another researcher’s results, or change control-system configuration.

Layer 6 — protected infrastructure, networks, and data

Segment research workstations, agent services, job submission, compilation, scheduling, execution workers, data repositories, security management, hardware control, and facility systems into distinct trust domains. Use encrypted service-to-service communication, private connectivity where appropriate, least-privilege network policy, hardened administration, protected backups, and data access controls.

The supporting Zero Trust services may rely on public key infrastructure (PKI), digital signatures, encrypted APIs, workload certificates, code signing, and secure management channels. These should be assessed for quantum-vulnerable cryptography.

NIST’s first three finalized PQC standards are:

• FIPS 203 — ML-KEM: key establishment.
• FIPS 204 — ML-DSA: digital signatures.
• FIPS 205 — SLH-DSA: digital signatures using a hash-based design.

The architecture should use appropriate standardized algorithms as they are supported by the relevant protocols, implementations, and validation requirements. Crypto-agility is essential because the migration must accommodate interoperability and future standards evolution.

Unlike a conventional server, a quantum processor is part of a specialized physical system. Depending on the technology, it may involve cryogenic equipment, lasers, vacuum systems, precision electronics, or other platform-specific components.

The security architecture should protect the classical management interfaces to those systems, limit who can alter their configuration, and monitor privileged maintenance. Physical access controls and safety interlocks remain essential.

Important limitation: A software-based Zero Trust agent cannot necessarily be installed on a QPU or every hardware controller. Where the platform is vendor-operated or does not support customer-level enforcement, implement Zero Trust at the nearest supported interface and contractually establish the vendor’s responsibilities, evidence, and incident-notification obligations.

Confidential computing and remote attestation may strengthen protection for supported workloads. Sensitive credentials or datasets should be released only when the evidence meets a defined policy. Attestation does not establish model correctness or absence of application vulnerabilities. Attestation can verify that systems, workloads, agents, and artifacts satisfy required security conditions before they receive access or execute sensitive operations.

Some key steps and requirements for confidential computing include:

·        Define attestation requirements for supported hardware, firmware, boot state, operating system, runtime, and workload components. ·        Verify attestation evidence using trusted verification services and approved reference measurements. ·        Bind attestation results to the workload identity, session, requested resource, and applicable authorization decision. ·        Establish freshness requirements for attestation evidence; reject expired, replayed, or invalid evidence. ·        Deny or restrict sensitive operations when mandatory attestation fails or the platform is outside approved configuration. ·        Protect boot measurements, runtime integrity evidence, signing keys, and attestation-verification policies. ·        Verify signed agent packages, model artifacts, plugins, runtime images, and quantum workflow components before execution. ·        Continuously monitor integrity where technically supported and trigger re-evaluation when relevant state changes. ·        Document the limits of attestation, including components managed by cloud or quantum providers that the customer cannot directly inspect. ·        Require explicit integrity and provenance checks at quantum-job submission and orchestration boundaries; do not assume that host attestation proves QPU correctness. Important distinction: Attestation provides evidence about a defined platform or software state. It does not prove that an AI agent’s reasoning is safe, that a model is free of backdoors, or that a quantum computation produced a correct scientific result.

Layer 7 — continuous assurance and security operations

Correlate identity events, policy decisions, agent plans and tool calls, parent-child delegation, quantum job metadata, compiler and artifact provenance, data access, algorithm use, certificate lifecycle, hardware security module (HSM) activity, attestation results, provider maintenance, and security alerts. Preserve tamper-evident records sufficient to reconstruct who authorized a job, which agent acted, what evidence was evaluated, what data was accessed, and which policy allowed or denied the action. Automate low-risk remediation, but stage high-impact policy or cryptographic changes and provide tested rollback.

The architecture should be able to answer:

• Who submitted this quantum job?
• Which source code, circuit definition, compiler, and optimization process produced it?
• Was the software or configuration altered?
• Which hardware platform and configuration executed it?
• Who was authorized to access the results?
• Can the execution record be independently verified?

An AI agent may generate quantum circuits, optimize experiments, submit jobs, analyze measurements, or invoke a quantum cloud API. These capabilities should be enabled through explicit authorization—not by giving the agent broad access to the quantum platform.

Consider an agent asked to run a materials simulation.

1. Task authorization: A user or approved workflow grants the agent permission to run a specific class of experiments with defined cost, data, and resource limits.
2. Agent identity: The agent authenticates using a distinct workload identity. Its identity is not interchangeable with the human user’s credentials.
3. Circuit generation: The agent produces a circuit or job specification, which is validated against allowed operations, resource limits, and data-handling rules.
4. Controlled execution: A job broker evaluates policy and submits the approved workload through the orchestration service. The agent cannot bypass the broker to access the hardware control plane.
5. Result authorization: Measurement results are released only to identities authorized for the relevant research project or dataset.
6. Audit and revocation: The system records the agent, task authority, job identifier, policy decision, and outcome. Suspicious behavior can trigger credential revocation and suspension of pending jobs.

The agent should not have direct access to privileged calibration, firmware, facility, or hardware-management interfaces unless a separately authorized operational use case requires it.

Use signed software artifacts, protected logs, controlled configuration changes, and attestation where supported. Attestation should be treated as evidence with a defined scope and freshness—not as proof that an entire quantum system is secure.

Other specific assurance and operations controls include:

• Establish a common event schema and consistent timestamps across trust services and workload environments.
• Record agent identity, initiating principal, delegated authority, task identifier, tool calls, policy decisions, and execution outcomes.
• Log PKI, HSM, and key management service (KMS) events, including key use, certificate changes, denied operations, and administrative activity.
• Collect source-control, build, signing, dependency-scanning, deployment, and artifact-verification events.
• Collect attestation outcomes, integrity failures, configuration drift, and trust-policy changes.
• Capture quantum-job submission, authorization, provider/job identifiers, execution metadata, cost or quota anomalies, and result retrieval where available.
• Correlate events across identities and sessions to detect distributed abuse, compromised agents, suspicious model extraction, and unauthorized data movement.
• Protect logs against tampering and unauthorized deletion; restrict access to sensitive prompts, outputs, model data, and cryptographic metadata.
• Establish retention, privacy, access, and evidence-preservation policies appropriate to the data classification and regulatory obligations.
• Define actionable detections, severity levels, alert ownership, escalation thresholds, and service-level objectives for incident handling.

Cross-Cutting Trust Services

For the quantum/AI reference architecture, these cross-cutting services should provide consistent trust enforcement across AI agents, software development pipelines, classical infrastructure, quantum workloads, and cloud services.

The controls below are intended as a practical baseline for architecture design, security requirements, and implementation planning.

Cross-cutting layer — quantum-resilient cryptographic trust services

Know where cryptography is used, what depends on it, and how to prioritize migration and remediation. A CBOM inventories cryptographic assets and dependencies. It complements an SBOM, which primarily inventories software components. Maintain a continuously updated cryptographic inventory covering algorithms, protocols, certificates, keys, libraries, signing systems, identity providers, APIs, HSMs, vendor dependencies, and the data protected by each relationship. Capture algorithm and protocol versions, key parameters, certificate lifetimes, ownership, location, and business criticality where applicable. Identify cryptographic dependencies embedded in third-party software, hardware, firmware, SDKs, and managed services.

Classify data according to sensitivity and required confidentiality lifetime to identify harvest-now/decrypt-later exposure. Map cryptographic assets to systems, data flows, identities, suppliers, and applications to identify migration dependencies.

Record cryptographic usage across applications, APIs, agent frameworks, service meshes, CI/CD, cloud services, and quantum-provider interfaces. Identify deprecated algorithms, unsupported libraries, hard-coded cryptographic assumptions, and non-agile protocol dependencies. Track PQC migration status, remediation owners, target dates, validation evidence, and exceptions. Reconcile inventory against observed network traffic, runtime telemetry, source code, package analysis, and vendor attestations. Update cryptographic inventory whenever software, models, infrastructure, protocols, certificates, or providers change.

The CBOM should be treated as a living operational asset, not a one-time spreadsheet. Unknown cryptographic dependencies should be tracked explicitly rather than assumed to be compliant.

Centralize policy for permitted algorithms and protocol profiles. Use NIST-standardized PQC where supported and appropriate: ML-KEM for key establishment, and ML-DSA or SLH-DSA for signatures. Evaluate hybrid migration approaches against protocol and interoperability requirements, prioritizing systems with long-lived sensitive data and long replacement cycles. Cryptographic migration is part of Zero Trust because identity, session protection, software integrity, and attestation depend on trustworthy cryptographic evidence.

Crypto-agility must be governed, not arbitrary. Support cryptographic agility through configurable algorithm selection and replaceable cryptographic libraries, protocols, and providers. Agents and applications must not be allowed to select weaker algorithms or disable validation at runtime, and downgrade attempts must be logged and trigger alerts. Algorithm changes should be authenticated, versioned, staged, observable, and reversible. Define crypto-related emergency procedures for algorithm compromise, deprecation, and accelerated key or certificate replacement such as key backup, recovery, escrow where justified, compromise response, and cryptographic key-destruction procedures. Validate interoperability, performance, certificate size, protocol compatibility, and failure behavior before deploying new algorithms. Verify PQC support across agent communications, APIs, service identities, software signing, data protection, and quantum-provider interfaces.

Securely establish, issue, protect, rotate, and revoke the cryptographic identities and keys used by humans, agents, services, software artifacts, and workloads. Maintain a governed PKI hierarchy with protected root and intermediate certificate authorities. Assign unique cryptographic identities to agents, workloads, build services, quantum-job brokers, and infrastructure services. Protect high-value keys in suitable HSM/KMS services; test issuance, renewal, rotation, revocation, recovery, and algorithm transition. Enforce least-privilege KMS policies, separation of duties, and explicit authorization for key administration and cryptographic operations. Use short-lived credentials where feasible, with automated certificate issuance, rotation, renewal, and revocation. Prohibit embedding long-lived secrets, private keys, and production credentials in prompts, source code, model artifacts, or agent configuration. Log key creation, access, use, export attempts, policy changes, rotation, and destruction. Validate PQC compatibility of PKI, HSM, KMS, certificate authorities, signing services, and dependent applications before migration. Require explicit policy authorization for agents requesting signing, decryption, key-generation, or key-management operations.

Cross-cutting layer — continuous validation, testing, and recovery

The main purpose of this cross-cutting service is to demonstrate that controls remain effective as agents, models, code, policies, cryptographic implementations, and quantum execution environments evolve. Additionally, this service provides containment for compromised identities, agents, artifacts, cryptographic components, and quantum workloads while restoring a known-good state.

Specific requirements and controls include:

1. Define testable security requirements and acceptance criteria for every trust service.
2. Run automated security checks on every material code, configuration, model, policy, and dependency change.
3. Test authorization boundaries, privilege escalation, delegation, credential misuse, and agent-to-agent access.
4. Validate PQC implementations, protocol negotiation, downgrade resistance, interoperability, and crypto-agility procedures.
5. Verify signatures, provenance, artifact digests, and release-policy enforcement in CI/CD and deployment pipelines.
6. Test attestation failure, stale evidence, integrity drift, and attempts to bypass trust enforcement.
7. Conduct adversarial testing for prompt injection, tool misuse, model extraction/distillation, sensitive-data leakage, and compromised agents.
8. Test quantum workflows for unauthorized job submission, altered circuits, unapproved backend selection, parameter tampering, and result-integrity failures.
9. Run chaos and recovery exercises covering revoked identities, compromised keys, unavailable trust services, and failed verification.
10. Continuously measure control coverage, false positives, detection latency, policy exceptions, and remediation performance.
11. Revalidate controls after material provider, firmware, model, compiler, SDK, policy, or architecture changes.
12. Prevent failed mandatory validations from being silently overridden; require documented, time-limited exceptions with accountable approval.
13. Maintain incident playbooks for compromised agents, stolen credentials, model extraction, malicious dependencies, signing-key compromise, and unauthorized quantum jobs.
14. Support rapid suspension of agent identities, revocation of credentials, termination of sessions, and restriction of tool access.
15. Quarantine suspect artifacts, disable affected releases, revoke signing trust where appropriate, and prevent redeployment.
16. Define emergency certificate and key rotation procedures, including recovery from CA, HSM, or KMS compromise.
17. Preserve immutable or tamper-evident evidence linking the incident to identities, source changes, build provenance, artifacts, and execution records.
18. Maintain tested recovery points for source repositories, policies, registries, build configurations, and critical metadata.
19. Support rollback to a previously verified release and confirm that the rollback artifact remains compatible with current cryptographic policy.
20. Establish provider-specific procedures for stopping or cancelling quantum jobs, disabling access, and handling results already returned.
21. Test recovery plans through tabletop exercises, technical simulations, and controlled compromise scenarios.
22. Feed incident findings into policy updates, threat models, agent permissions, security tests, and cryptographic migration plans.

Cross-cutting layer — agent-aware change control and versioned execution provenance

This cross-cutting layer is specifically to make the verification and release process as automated, parallel, and policy-driven as code generation. It consists of six controls:

1. Agent-aware commits and provenance

Every agent has a unique identity. Each change records the agent, initiating request or task, parent commit, model and agent version, tools used, dependencies, and relevant policy decisions. Agent identity must not be confused with human approval.

2. Isolated branches and bounded autonomy

Agents work in isolated branches, worktrees, or ephemeral environments. They may propose changes and run approved tests, but cannot independently modify protected release branches, disable mandatory checks, or grant themselves additional permissions.

3. Risk-based automated verification

Every change passes required tests, static analysis, dependency and secret scanning, and policy checks. High-impact changes—such as authentication, cryptography, authorization, infrastructure-as-code, or quantum-job controls—receive deeper analysis and independent review.

4. Immutable build and release evidence

Build artifacts are generated by controlled pipelines and accompanied by signed provenance and SBOMs. Release systems verify that the artifact corresponds to the approved source and trusted build process. SLSA provides a useful foundation for this.

5. Independent approval for consequential changes

Human approval is reserved for decisions whose impact warrants it, not for every generated line. Changes affecting production privileges, key management, trust roots, sensitive data, or safety-critical quantum workloads require designated approval or an independently enforced authorization policy.

6. Continuous reconciliation and rollback

Monitor deployed versions against approved artifacts, detect unauthorized drift, and support rapid rollback or revocation. An agent that introduces a change must not be able to suppress the telemetry used to assess that change.

Bottom line: version control itself can keep pace with agentic development. The harder problem is preventing the volume and autonomy of changes from overwhelming the organization’s ability to verify them. The strategic shift is from reviewing every line of code to verifying every change’s provenance, permissions, risk, and evidence before it is allowed to execute. In the agentic/quantum world, that is a core Zero Trust control—not merely a software engineering best practice.

Cross-cutting layer – Model Distillation and Extraction Defense

This cross-cutting control capability spans model and prompt security, agent identity, runtime enforcement, supply-chain security, and security operations. It consists of ten controls designed to protect AI and quantum intellectual property, such as model weights, proprietary outputs, agent logic, quantum algorithms, and job results:

1. Identity and authorization: Bind queries to users, agents, service identities, organizations, and delegated authority.
2. Risk-based query budgets: enforce limits by identity, organization, model, session, and workload. Use behavioral detection as well as simple request counts, since sophisticated campaigns may distribute queries across many accounts.
3. Output minimization: do not expose internal model parameters, raw logits, or detailed reasoning traces unless a documented use case requires them. Carefully control high-information outputs and bulk exports. Restrict unnecessary logits, confidence scores, sensitive outputs, and model artifacts.
4. Agent-aware anomaly detection: detect agents that repeatedly generate synthetic training examples, probe narrow capability areas, or transfer large volumes of outputs to external models or storage.
5. Model provenance and watermarking: Use model fingerprints, watermarking where appropriate, signed artifacts, and provenance records. Preserve signed model artifacts and provenance records; evaluate watermarks and fingerprints against removal, copying, fine-tuning, and distillation. Treat these as supporting evidence, not conclusive proof of theft.
6. Runtime containment: restrict model access from unapproved tools, external endpoints, and agent-to-agent channels. Apply egress controls and data-loss prevention to output streams.
7. Extraction detection: Detect systematic probing, coordinated accounts, repeated query patterns, and suspicious output harvesting.
8. Extraction-specific incident response: trigger graduated throttling, challenges, temporary suspension, credential revocation, and investigation when coordinated extraction is suspected. Preserve the identity and delegation chain in audit evidence.
9. Adversarial testing: periodically simulate authorized extraction tests to measure how well the system detects distributed, low-rate, and adaptive campaigns.
10. Adaptive response and assurance: Throttle • Challenge • Revoke • Isolate • Investigate • Retest

The control pattern is consistent with OWASP’s model-extraction guidance, which identifies query monitoring, rate limiting, and watermarking as relevant defenses. Importantly, no single one is sufficient.

Zero Trust protections for model distillation attacks

Classical Zero Trust often evaluates access to a resource. For AI model and quantum IP protection, authorization must also account for the cumulative information an identity or coordinated group can extract through repeated permitted requests.

Zero Trust control	Distillation-aware implementation
Verify explicitly	Authenticate every request and establish the calling agent’s owner, purpose, and delegated authority.
Least privilege	Expose only the models, outputs, tools, and data required for the task.
Continuous evaluation	Reassess risk using query history and behavior across sessions, endpoints, accounts, and agents.
Assume breach	Treat stolen credentials, compromised agent identities, and malicious insiders as possible extraction paths.
Limit blast radius	Use tenant isolation, per-model access boundaries, restricted exports, and bounded query budgets.
Continuous monitoring	Correlate inference logs with agent execution traces, registry access, data egress, and quantum-job activity.

A crucial distinction is that a validly authenticated request can still be part of an unauthorized distillation campaign. Traditional identity verification and encryption cannot detect this threat on their own.

Related work. Public descriptions of provider defenses show that distillation detection already relies on aggregate signals rather than single requests: prompts that look benign individually become a campaign only in pattern, across many coordinated accounts. Those descriptions focus on classifiers, behavioral fingerprinting, intelligence sharing, and tighter account verification. This paper adds an authorization framing. Cumulative information disclosed to an identity, or to a cluster of related identities, becomes an input to the access decision, so a request that is valid in isolation can still be throttled, degraded, or denied when accumulated exposure crosses a defined threshold.

A key emerging concern is distillation through reasoning traces, not just conventional API query harvesting. Recently, OpenAI described a coordinated campaign designed to extract protected reasoning from its models. That reinforces the need to evaluate whether a defense protects sensitive intermediate outputs, not just model weights or API availability.

Cross-cutting layers’ integration requirements

These controls become most effective when the trust services operate as an integrated system rather than independent functions.

Integration requirement	Expected outcome
Shared identity and policy	The same agent identity and authorization context are recognized across repositories, registries, key services, deployment pipelines, and quantum-job gateways.
Policy-enforced trust decisions	Access depends on identity, permissions, artifact provenance, relevant attestation evidence, and workload risk.
End-to-end evidence	A single investigation can trace a deployed workload from initiating agent and source commit through signed artifact to quantum execution and result retrieval.
Automated containment	A critical trust failure can trigger credential revocation, artifact quarantine, job cancellation where supported, and incident escalation.
Crypto-agile trust services	PKI, signing, attestation, and provenance mechanisms can evolve as approved cryptographic standards and implementations change.
Quantum-service execution controls Quantum service What it protects Controls Research access Researchers, notebooks, development tools Federated identity, MFA, role/attribute-based access, privileged-access controls Agent and application access Agents, APIs, automation services Unique workload identity, short-lived credentials, scoped permissions, delegation lineage Job submission Circuit/job metadata, experiment configuration Schema validation, ownership, quotas, approval rules, policy checks Compilation and orchestration Compiler, optimizer, scheduler, job broker Isolated workers, signed artifacts, provenance, restricted service identities Quantum control plane Hardware commands and platform configuration Separate administration, allowlisted commands, dedicated access paths, separation of duties Facility management Environmental and physical systems Physical controls, monitored maintenance, provider assurance, safety interlocks Results and research data Measurements, intermediate results, IP Data-level authorization, encryption, retention controls, export review Security management Logs, policy engines, credentials, response Restricted admin plane, protected audit records, resilient recovery A critical separation is the boundary between the job-submission control plane and privileged hardware management. A valid research job must not confer the ability to issue arbitrary hardware commands or alter facility configuration. Where provider architecture prevents direct customer enforcement, require contractual commitments, documented responsibility boundaries, authenticated administrative access, audit evidence, and incident-notification procedures. Zero Trust flow for agent-initiated quantum jobs Figure 2 depicts a Zero Trust–centric architecture. Enforcement is placed at supported interfaces; the design does not assume that customer-controlled security agents can run directly on QPU hardware. 1.        A user authorizes a bounded objective. The agent receives a unique workload identity and a short-lived task grant tied to the user/principal, purpose, allowed datasets, resource budget, and expiry. 2.        The agent proposes a job specification. Bind the request to context: task purpose, parent authorization, data classification, model/configuration version, runtime identity, destination, requested action, and resource cost. The agent cannot directly call privileged hardware APIs; it submits through the authenticated API gateway and job broker. 3.        The gateway validates the caller identity, cryptographic profile, request schema, destination, rate limit, and token scope. The policy engine evaluates the action against the current task grant and data/resource classification. Policy evaluation covers least privilege, task scope, separation of duties, quotas, data handling rules, geographic or contractual restrictions, and whether human approval is required. 4.        The job broker validates circuit/configuration metadata, checks quotas and approval requirements, and records a stable job identifier linked to the parent agent task. The task and parent commit are recorded. Before release, checks include tests, static analysis, dependency scans, secret scans, and policy checks. 5.        Compilation and optimization run in an isolated service with a distinct workload identity. Artifacts and configurations are verified for provenance and integrity before scheduling. Risk assessment considers impact, provenance, test coverage, privileges, and quantum-workflow changes. 6.        The scheduler submits only the approved job through a provider-supported interface. Hardware administration remains a separate privileged trust domain. Higher-risk jobs require independent approval and enhanced validation; lower-risk jobs may be approved automatically when policy criteria pass. 7.        Results are tagged with job and principal lineage, stored under explicit access policy, and released only to authorized identities. The system records the decision and causal chain: requester, owner, delegation parent, target resource, evidence, policy version, outcome, and subsequent actions. Export controls and retention rules are enforced independently of the agent. 8.        Telemetry correlates the agent’s requests, policy decisions, delegation, job state, artifact hashes, resource usage, result access, and any provider-side events. If behavior deviates, the system can suspend the agent, revoke credentials, cancel pending work where supported, and preserve evidence. This flow illustrates a key principle: a model can propose an operation, but a policy-enforcing control plane determines whether the operation is permitted, and the resource boundary independently enforces that decision. A critical Zero Trust property is that the agent does not decide whether its own output is trusted. The agent proposes; independent controls verify; the release authority enforces. Quantum-resistant cryptography protects specified cryptographic properties; it does not make an autonomous action safe. An agent with a valid PQC-backed identity can still be manipulated by prompt injection, hold excessive privileges, leak data through an allowed channel, or submit an abusive job. The design must pair cryptographic resilience with explicit authorization, runtime containment, resource-side checks, and human accountability.

The mandatory list

These controls must be in place before allowing autonomous agents to modify production-bound software or quantum workflows:

1. Unique agent identities: every agent has its own attributable identity and bounded credentials.
2. Immutable audit evidence: record who or what proposed, validated, approved, and deployed each change.
3. Protected control configurations: agents cannot change their own permissions, disable mandatory checks, or approve their own high-risk changes.
4. Every tool call, data access, and system change an agent can make is treated as a governable and auditable object, and verified pre-execution.
5. Reproducible builds: pin dependencies and toolchains, record build provenance, and verify artifact signatures.
6. Versioned execution context: link the code commit to the model, dataset, prompt/policy configuration, quantum circuit, compiler settings, and job metadata.
7. Risk-based approvals: automatically process low-risk changes that pass independent checks; require stronger validation and approval for changes to identity, cryptography, access policy, and quantum infrastructure.
8. Rollback and revocation: preserve the ability to restore a known-good version and revoke compromised agent or artifact credentials.

Every trust service should produce verifiable evidence, enforce explicit policy, and support rapid response when trust is lost. In the quantum/AI environment, trust cannot depend solely on a valid identity or a successful authentication event; it must also account for the integrity, provenance, authorization, and current risk of the workload performing the action.

Applying Zero Trust: what changes from classical computing?

The Zero Trust principle itself does not change. What changes is the number and nature of subjects, resources, transitions, and trust evidence that must be evaluated. Classical Zero Trust programs often focus on human users, endpoints, applications, service identities, and resource access. Quantum-agent environments add autonomous actors, model-influenced decisions, delegation graphs, dynamic jobs, specialized compute interfaces, hardware-management boundaries, and a longer-term cryptographic migration problem.

Dimension	Typical classical environment	Quantum / AI-agent environment	Architectural implication
Subject identity	Users, devices, services	Users, agents, agent instances, parent/child agents, jobs, orchestration services, operators	Bind identity to owner, workload, task, delegation chain, and expiry
Authorization unit	Session, API, application, dataset	Every tool call, delegation, job submission, result export, privileged hardware action	Authorize the specific action and resource at each boundary
Execution path	Often predefined application workflow	Model-selected paths, tools, and delegated subtasks; quantum jobs pass through brokers and schedulers	Enforce policy outside the model and at the job broker/tool gateway
Trust evidence	Credentials, device posture, application state	Cryptographic identity plus artifact provenance, runtime posture, attestation, model/configuration version, job metadata	Use contextual evidence but define its limits and freshness
Cryptographic risk	Current algorithm strength and key lifecycle	Same risks plus harvest-now/decrypt-later and future disruption to public-key trust	Make PQC migration and crypto-agility part of ZTA operations
Hardware boundary	Managed endpoint/server control agents often feasible	QPU and facility controls may be vendor-managed or unsuitable for customer agents	Enforce at supported interfaces; separately govern control plane and facility
Action reversibility	Transactions can often be rolled back through application controls	Quantum resources may be scarce; experiment data, IP export, or hardware changes may be difficult to reverse	Quotas, pre-execution checks, human gates, and emergency stop/cancel paths
Scale and velocity	Service identities and API calls already numerous	Rapid agent creation, fan-out, and high-volume short-lived actions	Automate issuance, authorization, telemetry, revocation, and lineage
Auditability	User/service-to-resource logs	Need causal trace across prompt/context, agent plan, tool call, delegation, job lifecycle, result and policy	Use correlated, tamper-evident event records with common identifiers

Defining the major Zero Trust challenges

These challenges are not merely theoretical design concerns. NIST’s PQC migration program specifically emphasizes cryptographic discovery, risk-based migration, and interoperability testing across protocols, certificates, and hardware security modules.

1. Cryptographic visibility and dependency mapping

Cryptographic algorithms are embedded in libraries, certificates, protocols, hardware, third-party services, and build pipelines. Organizations may not know where vulnerable algorithms are embedded. Agent frameworks and quantum-service interfaces add more dynamic relationships. Without a continuously maintained inventory and CBOM, migration gaps remain invisible.

Architectural response: Build automated discovery linked to application, agent, workload, data, and supplier inventories. Track owner, algorithm, use, confidentiality lifetime, upgrade path, and dependencies.

2. Identity ambiguity and delegation

A request may originate from a human, an agent acting for that human, a child agent, a tool service, or a scheduled job. Traditional logs may identify only the service account, obscuring who authorized the task and how authority propagated. An authenticated agent may still misuse excessive permissions or delegate work unsafely.

Architectural response: Use distinct identities for agent software and running workloads; preserve principal and task context; issue scoped delegation credentials; impose depth, duration, and fan-out limits; support resource-side authorization and rapid revocation.

3. Policy enforcement across probabilistic behavior

Agent behavior is not fully predetermined. Prompt injection can cause an agent to request technically valid but unintended actions. Model guardrails alone cannot reliably enforce resource permissions.

Architectural response: Make the policy engine and enforcement point independent of the model. Validate each consequential tool call and job transition; use allowlists, schemas, quotas, data boundaries, and approval gates.

4. Quantum job and hardware boundary complexity

The customer may control the job broker but not the QPU or facility. Hardware control APIs can have greater impact than research-level job submission, and provider evidence may be incomplete.

Architectural response: Separate job submission from privileged hardware management. Define customer/provider/shared controls, require supported audit evidence, and enforce the strongest available controls at gateways and administrative interfaces.

5. Long-lived confidentiality and harvest-now/decrypt-later

Data captured today may be exposed later if protected by vulnerable public-key mechanisms. Agent workflows can move sensitive research, prompts, results, and source code across multiple boundaries.

Architectural response: Rank data by sensitivity, exposure, and required confidentiality lifetime. Prioritize exposed long-lived data and vulnerable key establishment; test end-to-end protection rather than one endpoint.

6. Crypto-agility without downgrade risk

Algorithm flexibility is necessary, but uncontrolled selection or inconsistent rollout can create downgrade paths, interoperability failures, or enterprise-wide outages. Hard-coded algorithms make future changes slow and error-prone. Some legacy systems and embedded systems cannot readily support new cryptographic algorithms.

Architectural response: Use centrally governed algorithm policy, authenticated configuration, versioning, staged rollout, downgrade detection, compatibility testing, and tested rollback. Prioritize by risk; isolate, replace, or apply compensating controls where migration is not yet possible.

7. Attestation and runtime evidence

Attestation can establish measured properties of supported hardware/software, but not that a model is correct, a prompt is safe, or the application has no flaws. Evidence can be stale or its trust chain can be weak.

Architectural response: Define exactly what each attestation claim proves, its freshness and revocation semantics, and which decisions depend on it. Continue runtime monitoring after admission.

8. Performance and compatibility

PQC can increase message, key, or signature sizes and affect latency and throughput. Agents can generate many short-lived connections and identities, amplifying bottlenecks in gateways, PKI, HSMs, and schedulers. Identity trust can fail when issuers, clients, devices, or services support different algorithms.

Architectural response: Benchmark complete workflows under realistic concurrency, certificate chains, middleboxes, provider APIs, and failure conditions. Validate product/version support before enforcement. Plan certificate and trust-chain migration; test compatibility and renewal.

9. Supply-chain integrity and model provenance

A signed package can still be malicious if the build or signing process is compromised. Agent tools, model weights, compiler components, and policies can influence sensitive execution.

Architectural response: Require provenance, SBOM/CBOM, signed artifacts, protected signing keys, independent build controls, deployment verification, and emergency revocation/rebuild procedures.

10. Control-plane availability and recovery

Identity providers, policy engines, job brokers, key services, and logs become critical dependencies. If they fail open, access may escape control; if they fail closed without planning, research and business operations may halt.

Architectural response: Define fail-open/fail-closed behavior by resource and action risk; protect management planes separately; test break-glass access, revocation, backups, recovery, and policy-plane compromise scenarios.

11. AI-assisted offensive and defensive discovery

AI may help defenders discover dependencies and analyze code, but it can also accelerate vulnerability discovery or produce false confidence in an assessment.

Architectural response: Use AI as an assistive analyst, not an authority. Require reproducible evidence, independent testing, human review for consequential changes, and adversarial validation.

Zero Trust Integration Challenges

These are the main integration challenges for a Zero Trust architecture that combines autonomous agents and quantum infrastructure.

1. Agent delegation chains. The system must establish which human or service authorized an agent, what authority was delegated, and whether a downstream agent or tool can act within that authority.
2. Enforcement at the point of action. A model’s guardrail is not a security boundary. Authorization must be checked at tool gateways, APIs, data services, job brokers, and other actual resource boundaries.
3. Quantum-provider boundaries. Customers may not control the QPU’s internal hardware, its control stack, or the provider’s virtualization layer. Controls therefore need to combine customer-side authorization, provider APIs, job isolation, provider assurance, audit logs, and contractual responsibilities.
4. Cryptographic transition risk. PQC must be implemented across certificates, signatures, key management, APIs, agent identities, and software supply chains. A product that supports PQC in one interface does not establish that an entire workload is quantum-resistant.
5. Attestation scope. Confidential-computing attestation can establish evidence about supported hardware and software configurations. It should not be represented as proof that an AI agent’s reasoning is safe or that a quantum computation is correct.
6. Cross-platform telemetry. Agent actions, identity decisions, cryptographic events, and quantum-job activity must be correlated into a common audit trail with consistent identifiers and timestamps.
7. End-to-end provenance. The most important capability to integrate is end-to-end provenance across all these systems. A source-control platform may know which agent opened a pull request, an ML registry may know which model was trained, and a quantum provider may know which job ran—but the architecture must connect those records into one verifiable chain. That chain is what turns ordinary version control into agent-aware change control for a quantum/AI enterprise.

Migration plan

A Zero Trust decision is only as reliable as the identity and integrity evidence behind it. If a certificate, signing mechanism, or key-establishment protocol becomes vulnerable, a policy engine may be making a formally correct decision using unreliable evidence. PQC therefore belongs in the trust foundation of Zero Trust, not as an unrelated modernization program. Migration must include identity providers, PKI, certificates, service meshes, API gateways, secure boot, code and model signing, attestation chains, HSMs, and supplier interfaces.

NIST’s first three finalized PQC standards—ML-KEM, ML-DSA, and SLH-DSA—provide a concrete starting point for planning. Actual adoption should follow applicable standards, vendor support, protocol requirements, and risk assessments rather than assuming every component can be migrated identically.

Phase	Activities	Exit criteria / deliverables
0. Establish governance	Name executive risk owner; map business use cases; define agent autonomy tiers, human approval thresholds, data lifetimes, supplier obligations, and quantum-service responsibilities.	Approved charter, risk taxonomy, RACI, initial control baseline.
1. Discover and map	Inventory cryptographic assets, certificates, keys, algorithms, agents, models, tools, quantum APIs, jobs, datasets, suppliers, and management paths. Map data flows and trust boundaries. Identify where RSA, elliptic-curve cryptography, certificates, digital signatures, and public-key key exchange are used, including third-party and embedded dependencies.	Combined asset register and CBOM; owners assigned; unknowns and unsupported components documented.
2. Risk-rank and design	Prioritize by data sensitivity/lifetime, exposure, public-key dependency, business criticality, privilege, autonomy, and reversibility. Start with sensitive data that must remain confidential for many years, high-value identities, critical infrastructure, exposed services, and systems that are difficult to upgrade. Define ZTA policy, trust domains, algorithm profiles, and fail behavior.	Risk-ranked roadmap, target architecture, approved algorithm and identity policies, compensating controls.
3. Build shared trust services	Modernize PKI/KMS/HSM, implement workload identity and short-lived credentials, policy decision/enforcement points, agent registry, artifact signing, telemetry, and crypto-agility abstractions. Assess PKI, certificate authorities, identity providers, API gateways, HSMs, workload identity, code signing, and device attestation for PQC readiness.	Reusable trust services; tested certificate lifecycle; policy and logging integration.
4. Secure the quantum job path	Put an identity-aware gateway and job broker in front of quantum APIs; validate job schema, owner, purpose, quotas, data scope, and approvals. Isolate compilation and scheduling; separate workload and hardware-admin planes.	No direct bypass path for job submission; distinct administrative identities; end-to-end job lineage and audit.
5. Pilot PQC and agent controls	Ensure the enterprise can change algorithms, certificates, and cryptographic policies without rebuilding every application or agent workflow. Select a representative low-to-moderate-risk workflow. Test supported ML-KEM and signature options, hybrid modes where appropriate. Extend Zero Trust to agents. Treat every agent as a non-human security principal, limit its permissions, validate each consequential action, and make delegation traceable and revocable. Institute prompt-injection containment, result access, and attestation-based admission.	Measured performance and compatibility; documented threat tests; incident and rollback playbooks.
6. Validate and red-team	Validate authentication, secure connections, certificate issuance and renewal, service-to-service communication, logging, and recovery across mixed environments. Test unauthorized tool use, child-agent privilege escalation, token theft/revocation, algorithm downgrade, invalid signatures, stale attestation, job tampering, data exfiltration, provider maintenance access, and control-plane outage.	Remediation evidence; recovery exercises; residual-risk acceptance by accountable owners.
7. Roll out by risk tier	Deploy to high-value exposed systems first; use canary groups, compatibility gates, monitoring, vendor coordination, rollback, and temporary compensating controls for legacy dependencies.	Measured coverage and risk reduction; no uncontrolled downgrade; documented exceptions and expiry dates.
8. Operate and adapt	Continuously update inventory, test crypto-agility, renew and revoke identities, assess policy drift, exercise response, and reassess vendor and standards changes.	Operational metrics, recurring assurance reviews, tested migration path for future algorithm changes.

Recommended implementation order

Implement the architecture as a phased program with parallel tracks: (1) Zero Trust and agent governance, (2) PQC and crypto-agility, and (3) quantum-service security. Do not wait for a perfect inventory before addressing urgent exposures; discovery and high-risk remediation should proceed together.

1. Establish attribution: Secure the management plane. Create unique agent and workload identities; protected keys; mandatory artifact verification; protected release pipelines; centralized audit logs; emergency revocation. Establish identity provider, policy engine, job broker, signing services, HSM/KMS, logging, and privileged-access paths. Log generated changes, and prohibit shared agent credentials. Add signed build provenance, SBOMs, CBOM discovery, and attestation verification.
2. Automate the baseline: enforce isolated branches, mandatory tests, security scanning, dependency policies, quantum-job authorization, and protected release paths. Make every production agent and quantum job attributable before expanding autonomous permissions. Enforce tool and job policy at gateways and resource boundaries; do not rely on network location or model guardrails alone.
3. PQC migration validation: Prioritize PQC migration according to risk and confidentiality lifetime, while validating interoperability across complete end-to-end paths. Secure the software supply chain, introduce signed build provenance, artifact verification, dependency attestations, and immutable release evidence. Deploy agent-aware anomaly detection, distillation-defense tests, provider-boundary assurance, recovery exercises, and continuous policy evaluation.
4. Implement continuous assurance: Separate research workloads from hardware administration and facility control, including in provider-hosted deployments. Automate routine inventory, credential expiry, policy evaluation, and low-risk remediation; retain approval and rollback for changes with broad or irreversible impact. Extend to hybrid quantum/AI workflows: version quantum programs and relevant execution metadata, gate provider access, add risk-based approval rules, and test rollback and incident response.

Use NIST’s Secure Software Development Framework as the baseline for development security and SLSA for build provenance and integrity, then add the agent-identity, delegation, and quantum-execution controls specific to this architecture.

Consider use of AAuth for agent authentication. AAuth is an emerging, agent-centric authentication protocol, currently an IETF Internet-Draft rather than a ratified standard. It aims to replace shared secrets with cryptographic identity, support cross-domain trust, and enable fine-grained, per-call authorization, addressing gaps in OAuth for autonomous systems.

Metrics and assurance

Metric	What it measures	Interpretation caution
Cryptographic inventory coverage	Known algorithms, keys, certificates, libraries, and dependencies	High coverage is not enough if critical signing or long-lived data paths remain unknown.
High-risk PQC migration coverage	Migration of prioritized exposed and long-lived data paths	Measure end-to-end paths, not only endpoint feature flags.
Crypto-agility test success	Ability to change algorithm profiles without unacceptable disruption	Include downgrade prevention and rollback tests.
Agent identity coverage	Production agents with unique, attributable identities	Identity must link to owner, workload instance, task, and delegation.
Least-privilege conformance	Agent actions within approved task scope, context-based control over agent delegation (for example, AAuth-style)	Test attempted prohibited actions, not just normal successful calls.
Delegation audit coverage	Parent-child relationships and delegated permissions recorded	Ensure logs preserve causal lineage across asynchronous tasks.
Policy enforcement coverage	Sensitive tools, job submissions, result exports, and admin actions protected by enforcement points	Identify bypass paths and provider-owned interfaces.
Revocation and containment time	Time to suspend agents, revoke credentials, and halt pending work without stopping all work	Include child agents, cached tokens, and third-party services. Measure time to undo
Attestation policy coverage	Sensitive workloads admitted only when required evidence meets policy	Measure evidence freshness, revocation handling, and failure behavior.
Quantum job traceability	Jobs linked to requester, authorizer, configuration, artifacts, results, and policy decisions	Use a stable correlation identifier across all relevant systems.
Control-plane recovery	Successful recovery from identity, policy, broker, key service, or logging failure	Test both security containment and availability impacts.
Supplier readiness	Visibility into PQC support, admin boundaries, audit, and incident response commitments	Track exceptions, compensating controls, and remediation dates.
Change provenance coverage*	Percentage of agent-generated changes attributable to a specific agent, task, and parent version.	Track agent delegation chains
Unreviewed risk exposure*	Number and severity of changes bypassing or awaiting required controls.	Ensure all changes are captured and recorded.
Detection latency*	Time between introduction of a vulnerable change and its detection.	Define the measurement window and how start and end times are captured.
Artifact traceability*	Percentage of deployed artifacts that can be traced to approved source and verified build provenance.	Requires an up-to-date inventory of deployed artifacts; helps surface shadow agents.
Rollback readiness*	Time required to disable or reverse a problematic release.	Define the measurement window and how start and end times are captured.
Quantum-workload reproducibility evidence*	Percentage of runs with the source, parameters, toolchain, backend, and execution metadata needed for investigation.	Metadata must be registered and retained.
* Denotes version control measure
To determine whether security can keep pace with code generation, track both delivery speed and assurance quality. Avoid optimizing simply for the number of commits or the number of lines generated. Those metrics can reward volume without measuring secure outcomes.

Capability map: leading quantum / AI security vendors

The emerging security market for the convergence of quantum computing and agentic AI is best understood as a capability ecosystem, rather than a single category of products. Organizations will need to combine post-quantum cryptography (PQC), AI-agent security, Zero Trust enforcement, confidential computing, quantum-platform security, and continuous assurance.

The key architectural point is that no single vendor should be assumed to cover the entire reference architecture. The goal is to map each provider to the control points it can protect and identify the integration gaps that remain.

This map builds on the reference architecture and covers cryptographic resilience, agent security, identity/Zero Trust, quantum services, confidential computing, model-extraction defense, and agent-aware change control/provenance. The vendor list is intentionally inclusive: rows may represent a company, a named product, an open-source project, or a platform ecosystem. Marks indicate potential architectural fit, not that every feature is native, enabled by default, available in every tier, or independently validated. Confirm current product documentation, licensing, deployment model, region, API coverage, and interoperability before procurement.

Capability landscape

Post-quantum cryptography and crypto-agility	Protects identity, key establishment, digital signatures, certificates, and long-lived data against future quantum-enabled cryptanalysis.	Representative providers: SandboxAQ, Thales, Entrust, Cloudflare, PQShield.
AI-agent discovery, identity, and runtime enforcement	Discovers agents, evaluates risk, governs tool and MCP access, detects prompt attacks, and restricts actions using a deterministic approach.	Representative providers: Palo Alto Networks, Check Point, LaunchDarkly, LangGuard, plus specialized guardrail and runtime tools.
Quantum computing platform and infrastructure security	Secures quantum-job submission, orchestration APIs, access to research data, classical control systems, provider operations, and the hybrid cloud/on-premises environment.	Representative ecosystem: IBM, Microsoft, Amazon Web Services, and quantum-computing providers such as Quantinuum and IonQ. Their quantum services are not interchangeable with dedicated security products.
Confidential computing and attestation	Helps protect sensitive workloads and verify supported execution environments. It does not automatically attest to the integrity of a quantum processor or every cloud-service component.	Representative providers: Intel, AMD, and major cloud platforms with confidential-computing offerings.
Model Extraction / Distillation Defense	Detects systematic query behavior rather than merely rate-limit traffic. Correlates activity across agents, accounts, model endpoints, and sessions. Protects outputs and detects suspicious bulk egress. Supports model provenance or fingerprinting. Detection triggers enforcement at the inference gateway. Produces evidence suitable for incident response and investigation. The OWASP AI Security Verification Standard has a dedicated model-extraction defense section that provides a useful starting point.	Specialist and platform capabilities may include inference-abuse analytics, model/API protection, rate limiting, output controls, adversarial testing, and incident investigation. Dedicated detection of coordinated extraction is uncommon and must be demonstrated. OWASP AI security guidance is a useful control baseline. Representative providers/tools: HiddenLayer, Cisco AI Defense, CalypsoAI, Palo Alto Networks Prisma AIRS, Cloudflare, Kong, Promptfoo, and model providers such as OpenAI and Anthropic for provider-side defenses.
Agent-Aware Change Control and Versioned Execution Provenance	Preserves attribution, review and release gates, build provenance, artifact integrity, and versioned context across agent-generated source changes, models, datasets, quantum circuits, compiler settings, and job execution.	Representative ecosystem: GitLab, GitHub, Harness, Jenkins, MLflow, DVC, Weights & Biases, lakeFS, Databricks/Unity Catalog, IBM Quantum/Qiskit, and Microsoft Azure Quantum. These products cover different parts of the lifecycle; end-to-end provenance usually requires integration.

Vendor-by-capability matrix

Legend: ● = directly relevant/core product capability; ◐ = adjacent, supporting, or dependent on configuration/service scope; — = not a primary capability or not assessed here. These are qualitative architecture-fit indicators, not independent test results, certifications, or guarantees. A company-level mark does not mean every product, tier, region, or deployment supports the capability.

Vendor / platform	PQC & crypto-agility	AI-agent security	Zero Trust / identity	Quantum hardware / services	Confidential computing / attestation	Model extraction defense	Agent-aware change control / provenance
SandboxAQ / AQtive Guard	●	—	◐	—	—	◐	◐
Thales	●	◐	●	◐	◐	—	◐
Entrust	●	—	●	—	—	—	◐
PQShield	●	—	—	—	—	—	◐
AWS	●	◐	●	●	●	◐	●
Microsoft / Azure	●	●	●	●	●	◐	●
IBM	◐	◐	●	●	◐	◐	●
Palo Alto Networks / Prisma AIRS	◐	●	●	—	◐	◐	◐
Check Point	◐	●	●	—	◐	◐	◐
Intel	◐	—	◐	—	●	—	◐
AMD	◐	—	◐	—	●	—	◐
Quantinuum	◐	—	◐	●	—	—	◐
IonQ	◐	—	◐	●	—	—	◐
ID Quantique	◐	—	◐	◐	—	—	—
Cloudflare	●	◐	◐	—	—	●	◐
Cisco / AI Defense	—	●	◐	—	—	◐	◐
HiddenLayer	—	●	◐	—	—	●	◐
CalypsoAI	—	●	◐	—	—	◐	◐
Anthropic	—	◐	◐	—	—	●	◐
OpenAI	—	◐	◐	—	—	●	◐
Kong	—	◐	◐	—	—	◐	◐
Promptfoo	—	◐	—	—	—	◐	◐
LaunchDarkly	—	◐	◐	—	—	—	◐
Dash Security	—	●	◐	—	—	◐	◐
NVIDIA / NeMo Guardrails	—	●	—	◐	◐	—	◐
Guardrails AI	—	●	—	—	—	—	◐
LLM Guard	—	●	—	—	—	—	—
Vigil	—	●	—	—	—	—	—
Rebuff	—	●	—	—	—	—	—
ReliaQuest / GreyMatter	—	◐	◐	—	—	◐	◐
GitLab / Duo / CI/CD	—	◐	◐	—	—	—	●
GitHub Enterprise / Actions / Copilot coding agents	—	◐	◐	—	—	—	●
Harness	—	◐	◐	—	—	—	●
Jenkins	—	—	◐	—	—	—	●
MLflow	—	◐	—	—	—	—	●
DVC	—	—	—	—	—	—	●
Weights & Biases / Models	—	◐	—	—	—	—	●
lakeFS	—	—	—	—	—	—	●
Databricks / Unity Catalog	—	◐	●	—	◐	—	●
IBM Quantum / Qiskit	—	◐	◐	●	—	—	●
Microsoft Azure Quantum	◐	◐	●	●	◐	—	●
Google Cloud	◐	◐	●	◐	●	◐	●
NVIDIA Confidential Computing / GPU	—	◐	—	—	●	—	◐
Oracle Cloud Infrastructure	◐	◐	●	◐	●	◐	●
Portkey AI Gateway	—	◐	◐	—	—	◐	◐

The matrix is intentionally broad: a company offering quantum computing is not automatically a quantum-security vendor, and support for a cloud security control does not mean every quantum workload is covered by that control.

This is a capability map, not a market-share ranking or endorsement. Product capabilities and current algorithm support must be verified directly before procurement.

Specialized security tools

Specialist tools fill gaps where broad enterprise platforms do not provide sufficient depth. They should be integrated with—not substituted for—identity, policy enforcement, logging, and incident response.

Tool / provider	Primary role in the reference architecture	Best fit
NVIDIA NeMo Guardrails	Conversation and workflow policy enforcement	Guardrails and agent behavior
Guardrails AI	Structured output validation	Output schemas and data integrity
LLM Guard	Input/output scanning for sensitive data and unsafe content	Model and prompt security
Vigil	Prompt-injection detection	Model and prompt security
Rebuff	Prompt-injection defense	Model and prompt security
Dash / Dash Security	AI discovery, governance, runtime controls, and data protection	AI inventory and runtime security
HiddenLayer	Model Scanning, AI Attack Simulation, AI Guardrails, AI Supply Chain Security, AI Discovery, and AI Runtime Security	Model and prompt security
LaunchDarkly	Runtime control layer for AI development	AI inventory and runtime security
ReliaQuest / GreyMatter	Security operations, threat detection, investigation, and response	Security operations and incident response

These tools are complementary rather than interchangeable. For example, a prompt scanner may identify malicious input but cannot by itself enforce least-privilege access to a quantum-job API. A SIEM/SOAR platform may detect suspicious behavior but should not be the only control preventing an agent from executing an unauthorized action.

Major Vendors for Model Distillation and Extraction Defense

The market is developing quickly, but an important distinction is necessary: few enterprise security products are dedicated exclusively to stopping model distillation. Most provide components of the defense—model-theft detection, inference monitoring, API abuse controls, model protection, and AI runtime security.

The strongest candidates for a quantum/AI security architecture are those that can detect coordinated extraction behavior and enforce controls at the model-serving boundary.

The following is a practical shortlist based on published product capabilities and current security-market information, not a ranking of independently validated effectiveness.

1. 1. HiddenLayer — AI Security Platform

Strong specialist candidate

Focuses specifically on protecting machine-learning models and AI systems. Its platform includes model scanning, AI threat detection and response, and runtime security. OWASP’s AI security solutions directory explicitly describes its focus as including model extraction and model theft.

Evaluate for: detection of suspicious inference patterns, protection of proprietary models, model-theft investigations, and integration with security operations.

2. Anthropic — Claude-side distillation defenses

Direct model-provider defense

Anthropic has publicly described detecting coordinated illicit-distillation campaigns using suspicious account and traffic patterns, extraction-specific classifiers, and broader campaign attribution. These are provider-side defenses for protecting its own models, rather than a generally available enterprise product that customers deploy to protect any model.

Evaluate for: lessons in coordinated abuse detection, account and API-key risk, proxy-network identification, and cross-account campaign analysis.

3. OpenAI — Model-extraction and adversarial-distillation defenses

OpenAI has publicly reported detecting and disrupting coordinated attempts to extract protected reasoning and model capabilities. Its approach illustrates the need to identify suspicious interaction patterns and attempts to elicit information beyond normal user-facing responses.

Evaluate for: provider-side abuse detection, model-output protection, account-level enforcement, and the controls available through the specific API or deployment contract.

4. Cisco — AI Defense

Provides AI security capabilities spanning AI asset discovery, model and application validation, supply-chain risk, and runtime protection. These can support a broader extraction-defense program, although specific model-theft detection coverage should be demonstrated rather than assumed.

Evaluate for: AI inventory, validation, inference monitoring, and integration with enterprise network and security controls.

5. CalypsoAI — Inference Platform

Focuses on testing, defending, and monitoring production AI systems. Its runtime controls may be useful for restricting risky inputs and outputs, but explicit detection of coordinated distillation campaigns should be a separate evaluation requirement.

Evaluate for: policy enforcement at inference time, output controls, monitoring, and red-team testing.

6. Palo Alto Networks — Prisma AIRS

Provides AI application and agent security capabilities, including AI discovery, runtime monitoring, and controls for AI interactions. It is a relevant supporting platform for governing access to models and tools; confirm whether the specific deployment identifies systematic model extraction rather than only general AI threats.

Evaluate for: securing agent-to-model access, controlling tool calls, and correlating AI activity with wider enterprise security telemetry.

Additional products that provide supporting controls for model distillation defense

These are worth considering, but they should not be represented as dedicated model-distillation prevention products without confirming the exact feature set.

Product / vendor	Relevant capability	Role in extraction defense
Microsoft Azure AI	Cloud identity, API governance, monitoring, and AI security controls	Supporting access governance and telemetry
AWS security services	Identity policies, API controls, logging, and anomaly detection	Limiting and investigating inference abuse
Cloudflare	API protection, rate limiting, bot management	Disrupting automated query harvesting
Kong	API gateway and traffic policy enforcement	Applying quotas and authentication at model endpoints
Promptfoo	LLM security testing and red teaming	Testing extraction resistance before deployment

These layers matter because model distillation frequently uses otherwise legitimate API requests. API gateways can limit abuse, but sophisticated extraction may distribute requests across accounts, IP addresses, or organizations. They should be paired with model-aware detection and coordinated abuse investigation.

For broader market discovery, the OWASP GenAI Security Solutions Landscape provides a useful directory of commercial and open-source AI security products.

Vendors and Products for Agent-Aware Change Control and Versioned Execution Provenance

Offerings must do more than preserve source-code history; they should identify which agent created a change, what authority it used, which model and dependencies were involved, how the change was validated, who or what approved it, and exactly which artifact was deployed or executed.

The market is beginning to address this through three overlapping product categories:

• Agentic DevSecOps: governs agent-generated code changes and release approvals.
• AI/ML and artifact lineage: versions models, datasets, prompts, configurations, and build artifacts.
• Quantum workflow reproducibility: records quantum programs, compiler settings, backend details, and execution results.

No single product in this landscape should be assumed to provide all three domains end to end; the architecture should explicitly integrate the relevant systems of record and evidence.

Leading agent-aware change-control platforms

1. GitLab Duo Agent Platform + GitLab CI/CD

Strong integrated candidate – GitLab combines repository history, merge requests, pipelines, security scanning, and agentic workflows. Its AI Governance capabilities include agent-session audit records and tool policies, while its change workflows preserve approval gates and audit trails.

Best fit: organizations that want a unified control point for agent-generated changes, automated security review, approval gates, and deployment.

2. GitHub Enterprise + GitHub Actions + Copilot coding agents

Provides Git-based history, pull requests, protected branches, required checks, code-owner review, and automated workflows. This is a strong foundation for controlling AI-generated changes, provided repository protections and workflow permissions are configured independently of the coding agent.

Best fit: teams already using GitHub that want to retain their existing development workflow while adding agent-generated pull requests and enforceable merge controls.

3. Harness — Software Delivery Platform

Focuses on CI/CD orchestration, deployment governance, release controls, verification, and rollback. It complements source control by governing whether a verified change is allowed to progress into production.

Best fit: high-velocity agentic development environments where deployment safety, progressive delivery, and rapid rollback are major concerns.

4. Jenkins

Provides an extensible automation engine for builds, tests, security scans, signing, and deployment. Agent-aware controls must be designed into the pipeline using credential isolation, explicit permissions, protected configuration, and auditable approval steps.

Best fit: organizations that need a customizable or self-hosted pipeline and are willing to engineer the control framework themselves.

Suggested approach: evaluate GitLab and GitHub as alternative source-of-truth platforms, then add a delivery-control platform if release complexity warrants it. Avoid creating multiple competing systems of record for the same commit and approval history.

Vendors for Model, dataset, and AI artifact versioning

Source control alone cannot reliably version large model weights, datasets, experiment configurations, and model lineage. These products fill that gap.

Vendor / product	What it versions or tracks	Role in agentic/quantum security
MLflow Model Registry / MLflow AI Platform	Model versions, experiment lineage, metadata, promotion, rollback, and artifact tracking	Establishes which model version and associated evaluation evidence were approved for a given agent or workload; additional agent/prompt/policy fields may need integration.
DVC	Dataset and model artifacts linked to Git commits	Data Version Control
Weights & Biases / Weights & Biases Models	Experiments, model artifacts, training runs and lineage	Tracks training and evaluation evidence across model iterations.
lakeFS	Versioned data and data-lake operations	Supports controlled dataset changes and reproducible data pipelines.
Databricks / Unity Catalog and MLflow	Model governance, lineage, access controls and lifecycle management	Connects model promotion and governance to the broader data platform.

These tools answer different questions from Git:

• Which exact model was used by the agent?
• Which dataset, parameters, and code produced that model?
• Which evaluation results justified its promotion?
• Can the organization restore the previous approved version?

For example, MLflow’s registry explicitly supports model versions, lineage, metadata, and controlled promotion workflows.

The registry should also record the agent configuration, system prompt or policy version, tool permissions, and the model’s cryptographic digest. These additional fields are architectural recommendations, not claims that every registry automatically captures them.

Vendors for quantum program and execution versioning

Quantum computing requires another layer of provenance. The classical source code may remain unchanged while the transpiler, optimization settings, backend, calibration state, or execution configuration changes. These quantum platforms are not substitutes for a dedicated, immutable version-control or provenance system. An organization should maintain an independent record of the source digest, build environment, agent identity, approved job configuration, provider job ID, and returned results.

1. IBM Quantum / Qiskit

Qiskit provides the quantum SDK, circuit representations, transpilation tooling, and execution workflow for quantum programs. IBM documents a workflow spanning problem mapping, hardware optimization, execution, and post-processing.

Use it for: versioning circuit source and parameters in Git, pinning Qiskit and transpiler versions, recording backend and execution metadata, and preserving result-validation evidence.

2. Microsoft Azure Quantum

Provides a cloud development and execution environment for quantum workloads. Use source control and CI/CD around the code, configuration, and job-submission pipeline; verify the available execution records and provider-specific metadata for each backend.

Use it for: governed hybrid workflows that combine classical services, AI orchestration, and quantum backends.

Recommended procurement approach

For the reference architecture, build a best-of-breed integrated stack rather than selecting a single vendor to cover every layer. Evaluate capabilities by control domain and validate supported versions, interoperability, certifications, and deployment constraints:

• Quantum-safe cryptography and cryptographic discovery: assess enterprise inventory, CBOM support, dependency mapping, risk prioritization, and migration orchestration. Test against NIST standards.
• PKI, HSM, and key management: validate required PQC algorithm support, module validation, throughput, signing-key protection, certificate lifecycle, and recovery.
• Network and cloud infrastructure: verify specific protocol and product-version support for PQC, segmentation, secure service communication, and logging.
• Agent security control plane: choose an enterprise platform for agent discovery, identity visibility, runtime monitoring, and tool-call enforcement; supplement it with specialist guardrails where needed. Test non-human identities, task-scoped authorization, delegation, revocation, privileged access, and auditability.
• AI runtime security: evaluate prompt-injection detection, tool-call inspection, data-loss controls, model and agent discovery, and enforcement across actual execution paths.
• Quantum service provider: establish responsibility boundaries for job broker, scheduler, hardware control, facility management, maintenance, incident notification, and audit evidence. implement a policy-enforcing quantum-job broker or gateway in front of provider APIs, with scoped credentials, approval rules, quotas, logging, and revocation.
• Trusted execution: use confidential computing and attestation where the selected platform supports them, while explicitly documenting what is and is not attested.
• Continuous assurance: integrate security operations, cryptographic posture management, agent red-teaming, and quantum-job telemetry into a shared response process.

The key selection criterion is enforceable coverage, not the number of advertised capabilities. Require demonstrations that show an unauthorized agent action being denied at the resource boundary, the decision being recorded, relevant authority being revoked, and evidence being preserved across classical and quantum-service boundaries.

Governance and operating model

A converged program needs shared ownership across security architecture, cryptography, identity and access management (IAM), AI engineering, cloud/platform engineering, research teams, procurement, legal/compliance, incident response, and quantum-service providers. A useful operating model includes:

• An architecture authority that owns the trust-domain model, approved algorithm profiles, and exceptions.
• A cryptographic migration owner responsible for discovery, risk ranking, supplier coordination, and crypto-agility testing.
• An agent governance owner responsible for agent registration, autonomy tiers, delegated authority, model/tool provenance, and lifecycle.
• A quantum platform owner responsible for job broker controls, scheduler integration, provider boundaries, hardware administration, and result handling.
• A security operations function that correlates agent, cryptographic, identity, workload, quantum job, and provider telemetry.
• An exception process with a named risk owner, compensating controls, expiration date, and a measurable retirement plan.

Automation should be used to scale policy checks, inventory, and containment—not to remove accountability. Changes to enterprise-wide trust anchors, cryptographic policy, production quantum control, or irreversible business actions require risk-appropriate approval, staged rollout, and recovery plans.

Conclusion

Securing the fusion of quantum computing and agentic AI requires a unified trust architecture. Quantum computing challenges the durability of some cryptographic mechanisms; agentic AI increases the velocity, autonomy, and complexity of operations that depend on those mechanisms; and quantum-computing services introduce specialized boundaries between research, job submission, orchestration, execution, hardware management, facilities, and results.

Zero Trust remains the organizing principle, but its practical application must become more granular and more context-aware. It must authenticate and authorize agents as well as people, preserve the origin and limits of delegated authority, evaluate every consequential tool call and job transition, and distinguish a research workload from privileged hardware administration. It must also treat cryptographic resilience as a dependency of identity and integrity decisions, with discovery, PQC migration, and crypto-agility embedded in day-to-day operations.

The most important architectural rule is that no identity—human, agent, service, or operator—receives unrestricted authority over a quantum-computing environment. Every job, data access, delegated action, software artifact, and administrative operation should cross an explicit, auditable authorization boundary appropriate to its risk. Autonomy must not exceed the enterprise’s ability to establish trust, enforce policy, observe behavior, and recover from failure.

---

Are you treating quantum computing and agentic AI as one security problem? Do you feel like there is no place to hide anymore as AI and quantum threats appear together over the tech horizon? How are you preparing for this double-edged threat? The organizations that succeed will likely be those that treat agent security and quantum security with a fused strategic approach. Give me your views on the future security architectures. And thanks to my subscribers and visitors to my site for checking out ActiveCyber.net! Please give us your feedback because we’d love to know some topics you’d like to hear about in the area of active cyber defenses, artificial intelligence, authenticity, quantum cryptography, risk assessment and modeling, autonomous security, digital forensics, securing OT / IIoT and IoT systems, Augmented Reality, or other emerging technology topics. Also, email chrisdaly@activecyber.net if you’re interested in interviewing or advertising with us at Active Cyber™.