CTC AI Security Tool Targets Model Theft With West Point

CTC has joined West Point’s Robotics Research Center to build an AI security tool that attacks machine learning models before adversaries can. The collaboration targets model theft and privacy leakage, two risks that conventional software tests rarely measure well. That conflict gives the CTC AI security tool a demanding role: turn research attacks into repeatable evidence for defense decisions.

The project centers on a model-stealing pipeline within a broader assessment system. Concurrent Technologies Corporation, known as CTC, says the pipeline will automate developmental test and evaluation tasks. It will examine how model architectures, training methods, and defensive techniques respond to different stealing attacks.

The idea sounds straightforward, but the standard is unusually high. A useful defense assessment cannot merely show that an attack ran. It must measure what the attack recovered, compare results across configurations, and explain whether a model remains acceptable for its mission.

That requirement places the project against its primary opponent: subjective, labor-intensive AI security testing. Existing assessments often depend on experts reviewing reconstructed data and interpreting whether an attack succeeded. That approach becomes difficult to repeat across many architectures, datasets, and access conditions.

CTC and West Point are trying to make that work more systematic. Their challenge is proving that automation can scale security testing without hiding important context behind a convenient score.

The CTC AI Security Tool Turns Model Theft Into a Test

The collaboration treats model theft as a measurable engineering problem, not a hypothetical warning.

CTC announced the partnership with the U.S. Military Academy’s Robotics Research Center on September 9, 2026. According to the project announcement, the team is designing a machine learning model-stealing pipeline for automated developmental test and evaluation.

Model stealing describes attacks that recover information about a model, reproduce its behavior, or expose characteristics of its training data. NIST defines model extraction as a privacy attack that obtains details about a model’s architecture or parameters. Related model inversion attacks try to reconstruct information resembling the original training data.

Those distinctions matter because the damage can extend beyond intellectual property. A stolen model can reveal design choices, decision boundaries, or specialized capabilities. An inversion attack can expose sensitive patterns that the model learned from operational data.

The risks become more serious when a system handles military imagery or other restricted information. A model does not need to return a stored training record word for word to leak something valuable. Reconstructed class features can reveal what the system recognizes and how it separates targets.

CTC says its pipeline will help identify which architectures and training techniques are more susceptible to privacy leakage. The project will also test defenses, including differential privacy and adversarial training.

Differential privacy is a mathematical approach that limits how much any individual training example can influence an observable result. Adversarial training exposes a model to manipulated examples during development so it can better resist related attacks. Neither defense eliminates every risk, and both can affect model utility.

The assessment system is therefore supposed to compare more than attack success. It must support experiments across models, attacks, and defenses while preserving enough detail for specialists to understand the result. CTC says it is combining proprietary codebases into modular, reconfigurable components for that purpose.

CTC’s fiscal 2025 annual report identifies the broader system as PROTECT. The report says the company and West Point are developing PROTECT to automate and scale developmental test and evaluation tools and metrics.

That earlier reference shows the September announcement is not the beginning of an unexplored concept. It is a public description of a research path already represented in CTC’s development portfolio.

The announcement does not disclose a contract value, delivery schedule, operational customer, or deployment date. It also does not identify a certification process that systems would pass after using the tool. For now, the clearest deliverable is an experimental assessment pipeline, not a universal security seal.

That boundary is important. CTC and West Point are building machinery for producing evidence about privacy risk. They are not claiming that one assessment can establish the safety of every defense model.

The tension begins there. A scalable tool can widen testing coverage, but a standardized output can also create false confidence when users overlook assumptions behind the score.

Why Defense AI Needs Repeatable Security Evidence

Defense programs need testing that keeps pace with model development while still producing evidence commanders and evaluators can challenge.

The pressure comes from the widening use of machine learning in systems that analyze imagery, prioritize information, support autonomy, and inform operational choices. Each deployment creates a new combination of data, architecture, hardware, mission conditions, and attacker access.

Traditional software assurance remains necessary, but it does not cover the entire machine learning attack surface. A program can patch known software vulnerabilities and still deploy a model that exposes sensitive information through its outputs. It can also pass an average accuracy threshold while remaining vulnerable to carefully designed queries.

The U.S. military has already identified this testing gap as an institutional problem. Its responsible AI implementation pathway calls for test, evaluation, verification, and validation throughout an AI capability’s lifecycle.

That pathway also calls for tools that detect natural degradation and adversarial attacks. It describes a shared testing ecosystem with metrics for trustworthiness and confidence. CTC’s project fits that direction because it aims to convert one difficult attack class into repeatable experiments.

The immediate pressure falls on program managers, test organizations, and model developers. They must decide whether a system is ready while the relevant attack methods continue changing. They also need to document why a particular defense was selected and what residual risk remains.

A manual assessment can become a bottleneck. Model inversion results may include reconstructed images that require a specialist to inspect. One evaluator may regard an image as an obvious privacy failure, while another may see only a vague resemblance.

That disagreement is not a minor workflow issue. It makes comparisons difficult across test teams and development cycles. It also complicates decisions about whether a mitigation reduced risk or merely changed the appearance of reconstructed data.

Scale creates another problem. Testing one architecture with one attack provides a narrow result. A credible program may need to examine several architectures, access conditions, attack methods, datasets, and defensive configurations.

The number of combinations grows quickly, even before mission environments enter the picture. Human review cannot disappear, but it becomes increasingly expensive when every experiment requires bespoke interpretation.

The CTC AI security tool addresses this pressure by structuring the work as a pipeline. A pipeline can run attacks, capture outputs, calculate metrics, and preserve configuration details through a common process. That structure supports comparison and makes rerunning an assessment easier after a model changes.

Repeatability also matters for acquisition oversight. A security claim becomes more useful when reviewers can trace it to a defined model version, attack assumption, dataset, and measurement method. Without that traceability, a favorable result may say little about the fielded system.

West Point brings a combination of military context and technical research. Its Robotics Research Center sits within the Department of Electrical Engineering and Computer Science. The center supports robotics and autonomous-systems research and includes the Laboratory for Artificial Intelligence Research and Engineering.

CTC brings applied research, system engineering, and test experience. The pairing is useful because adversarial machine learning sits between research and operational assurance. Attack methods must be technically credible, while outputs must remain usable by people making program decisions.

The partnership does not remove the central difficulty. Defense organizations must decide how much evidence is enough for a specific mission. A model used for administrative classification carries different consequences from one supporting time-sensitive operational decisions.

A repeatable assessment helps teams ask that question consistently. It cannot answer the mission-risk question without human judgment.

Model Inversion Shows Why Manual Testing Struggles

Model inversion is difficult to assess because a reconstructed output can expose meaningful information without perfectly reproducing the original data.

The research behind the collaboration offers a clearer view of the mechanism. In September 2025, Tyler Shumaker, Jessica Carpenter, David Saranchak, and Nathaniel D. Bastian published work on an automated model inversion assessment pipeline.

Their published research describes model inversion as an effort to reconstruct training information by exploiting relationships among inputs, internal representations, and model outputs. Attackers may use predictions, confidence scores, gradients, or other available information.

Access conditions shape the attack. In a white-box scenario, the attacker has extensive knowledge of the target, potentially including gradients and parameters. In a black-box scenario, the attacker may see only outputs returned through an interface.

Limited access does not guarantee safety. The researchers note that modern attacks can combine optimization with generative methods and public data. Those supporting resources can help an attacker produce recognizable reconstructions even without complete internal access.

The paper focuses on a central measurement problem. Human observers can find inversions difficult to interpret, and their judgments can be subjective. A blurry reconstruction may still preserve class-specific information that helps an attacker understand the target model.

The authors introduced four adversarial risk dimensions for quantifying privacy loss. They combined model inversion methods with vision-language models, systems that jointly process images and text, to support automated analysis.

The pipeline used vision-language models for zero-shot classification and image captioning. Zero-shot classification asks a system to identify categories without task-specific examples in the immediate evaluation. Captioning converts visual content into text that can support further comparisons.

This approach changes the evaluator’s task. Instead of relying only on a person’s visual impression, the pipeline can measure whether reconstructed samples preserve information useful for identifying classes or describing sensitive content.

The researchers also examined whether reconstructed information could support a surrogate model. A surrogate attempts to imitate a target system’s behavior. If reconstructed data helps train an effective substitute, the attack has extracted operationally useful knowledge.

That is why model stealing and model inversion overlap without being identical. One attack may seek architecture details or parameters. Another may target training information. Both can help an adversary reproduce capabilities, study weaknesses, or reduce the cost of building a competing system.

The paper benchmarked the pipeline in a computer-vision image-classification setting described as typical of military applications. It tested multiple inversion methods and multiple vision-language model configurations. The public abstract does not establish equivalent results across every data type or mission.

The work received the best paper award at a 2025 NATO Science and Technology Organization symposium on AI security and assurance for military systems. CTC reported that the event received 60 abstracts, accepted 30 for papers or presentations, and received 23 full papers.

That recognition supports the research contribution, but it is not an operational validation of PROTECT. A reviewed paper can establish that a method is technically interesting and reproducible within its experimental scope. It does not show how the method performs against classified models or unfamiliar deployment conditions.

The mechanism also introduces dependencies. When one model evaluates leakage from another, evaluators must understand the reviewing model’s errors. A vision-language model can misclassify an image, overlook a subtle reconstruction, or respond differently after an update.

Automation therefore moves some subjectivity rather than eliminating it. Human judgment once applied directly to reconstructed images may reappear in metric selection, prompt design, thresholds, and evaluator-model choice.

That shift can still be valuable. Explicit assumptions are easier to inspect than undocumented impressions. A pipeline can record the chosen evaluator, attack settings, and decision thresholds for later review.

The important question is whether users treat those settings as part of the evidence. If they focus only on a final risk label, the tool may compress uncertainty too aggressively.

Automation Creates a New Security Tradeoff

The tool’s value depends on whether it makes uncertainty visible instead of turning an incomplete test into a reassuring score.

NIST’s adversarial ML taxonomy organizes attacks by lifecycle stage, attacker objective, capability, knowledge, and data modality. It covers model extraction alongside reconstruction, membership inference, poisoning, evasion, and other threats.

That breadth illustrates the first limitation facing the CTC AI security tool. A strong model-inversion assessment does not constitute a complete adversarial AI evaluation. A model may resist reconstruction while remaining vulnerable to manipulated inputs, poisoned training data, backdoors, or supply-chain compromise.

The second limitation concerns threat assumptions. A black-box test can underestimate a captured system’s exposure when an adversary could obtain its parameters. A white-box test can overstate a remote attacker’s practical access if the deployed architecture prevents comparable interaction.

Test designers must therefore connect each attack to a credible operational scenario. They should record what the attacker knows, what interfaces are available, how many queries are allowed, and what supporting data exists.

The third limitation is metric validity. Four risk dimensions create a richer view than one visual score, but decision-makers still need evidence that those dimensions track meaningful harm. A metric should distinguish harmless resemblance from disclosure that changes an adversary’s capabilities.

That validation becomes especially difficult when training data is sensitive. Researchers may be unable to publish representative datasets, operational model details, or realistic attack outcomes. Public benchmarks can support method development while missing the characteristics that matter most in restricted environments.

Differential privacy introduces its own tradeoff. Stronger privacy protection can reduce leakage, but it can also affect accuracy or increase training complexity. The correct balance depends on mission consequences, data sensitivity, and available alternatives.

Adversarial training is similarly conditional. It can improve resistance to attack patterns represented during training. It does not automatically generalize to every future technique, and it can create a cycle in which defenders optimize against yesterday’s tests.

A modular pipeline offers one response. Teams can add attack methods, models, and metrics as the field changes. CTC says its components are reconfigurable, which should support varied experimental designs.

Modularity also expands the validation burden. Every new component can alter results or introduce dependencies. An updated vision-language evaluator may change risk scores without any change to the target model.

Version control and provenance become essential. Test reports should identify the target model, attack implementation, evaluator, dataset, configuration, and software revision. Otherwise, two assessments with the same label may not be comparable.

Security teams must also protect the assessment environment. A model-stealing pipeline contains attack code, target interfaces, experimental data, and potentially sensitive findings. Weak controls around that system could create a new path to the assets it evaluates.

The announcement does not describe access controls, isolation, deployment architecture, or handling rules for assessment data. It also does not say whether PROTECT will operate in disconnected environments. Those omissions are understandable for an early public announcement, but they prevent conclusions about operational readiness.

Another uncertainty is the intended user. Researchers can tolerate complex configuration and ambiguous outputs. Program offices and operational test teams often need documented procedures, stable interfaces, and decision thresholds tied to requirements.

Moving from a research pipeline to a shared test resource requires more than packaging code. It requires training, governance, benchmark maintenance, and a process for contesting results. Users need to know when a test is inapplicable and when a specialist must intervene.

There is also a risk of assessment gaming. Once a score influences acquisition or deployment, developers have an incentive to optimize for that test. A model can perform well against a known suite without gaining broader resilience.

Independent evaluation can reduce that risk. So can rotating attack methods and separating development benchmarks from acceptance tests. The public materials do not say how CTC or West Point will manage those questions.

None of these limitations makes automation a poor goal. They define the conditions under which automation improves assurance. The strongest version of PROTECT would produce structured evidence, preserve uncertainty, and make retesting inexpensive.

The weaker version would generate a polished label whose assumptions remain difficult to inspect. The project’s significance rests on which version emerges.

Three Signals Will Show Whether PROTECT Moves Beyond Research

The next test is not another broad promise about secure AI. It is evidence that PROTECT can support repeatable decisions outside its original experiments.

The first signal is a detailed technical release connecting the 2025 research pipeline to the broader PROTECT architecture. CTC has disclosed the project’s focus, modular design, and intended defenses. It has not published a full system specification or evaluation protocol.

A useful release would explain which attacks the tool supports, how the four risk dimensions are calculated, and how evaluator uncertainty is represented. It would also define the relationship between model inversion, model extraction, and the broader assessment suite.

That information would strengthen the project’s central claim. It would show that the collaboration is translating a reviewed method into an engineering process rather than applying a new name to isolated experiments.

A release that offers only a summary score would weaken the case. Security specialists need enough detail to reproduce results, identify invalid assumptions, and compare assessments over time.

The second signal is validation across more architectures, data types, access conditions, and defensive methods. The published work focuses on computer vision and image classification. That is a meaningful defense use case, but it does not represent every model that military organizations deploy.

Future evaluations should show how results change between white-box and black-box access. They should also compare unprotected models with versions using differential privacy, adversarial training, or other mitigations.

The most persuasive evidence would include failure cases. A credible assessment project should disclose where its metrics become unstable, where automated evaluators disagree with specialists, and where an attack falls outside the pipeline’s scope.

Such reporting would strengthen confidence because it would define the tool’s operating boundaries. A claim of uniform effectiveness across unrelated models would instead raise questions about whether the evaluation captures mission-specific risk.

The third signal is adoption within a formal test environment. The announcement names CTC and West Point’s RRC, but it does not identify an acquisition program, operational test organization, or fielded system using the assessment.

A pilot with defined acceptance criteria would show whether the output helps real decision-makers. Evaluators should be able to connect findings to mitigations, requirements, and a documented deployment choice.

Operational adoption would also expose workflow questions that laboratory research cannot settle. Teams must decide who configures attacks, who reviews results, how long assessments take, and what happens after a model update.

If PROTECT becomes part of recurring lifecycle testing, the project’s broader argument gains support. It would show that adversarial AI assessments can move from specialist studies into repeatable program practice.

If adoption remains limited to research demonstrations, the method can still contribute to the field. However, it will not yet have solved the institutional testing bottleneck that makes the collaboration noteworthy.

Developers and enterprise buyers should care even if they never handle defense systems. Commercial teams face the same underlying problem when models process proprietary documents, customer records, medical imagery, or internal operational data.

They need to know whether an exposed interface leaks training information and whether a mitigation works under realistic access conditions. They also need test records that remain useful after models, prompts, and surrounding applications change.

The CTC AI security tool points toward a practical standard: treat privacy attacks as repeatable tests with explicit assumptions. That principle applies beyond military procurement. It can inform vendor reviews, model selection, internal red teaming, and deployment gates.

The harder lesson is equally important. An automated assessment does not replace threat modeling or accountable human review. It gives those processes a more consistent body of evidence.

Watch for a published PROTECT methodology, broader benchmark results, and a named operational pilot. Together, those signals will show whether CTC and West Point have built a reusable assurance system or an effective research instrument with further work ahead.

Teams evaluating sensitive AI should ask the same question now: can their security claims survive a repeatable model-stealing test? If the answer depends on informal judgment or a single benchmark, the evidence is not mature. PROTECT’s progress will matter because it tests whether that gap can close without reducing complex risk to a misleading badge.