PaperlayerView exact revision on arXiv

Source-linked AI summary

Securing the AI Agent: A Unified Framework for Multi-Layer Agent Red Teaming

Yong Yang, Xing Zheng, Huiyu Wu, Huangsheng Cheng, Xiaorong Shi, Jing Guo, Bo Yang, Yi Zhou, Xiangfan Wu, Zonghao Ying

arXiv:2606.31227v1cs.CR

TL;DR

AI agents now expose a broad, layered attack surface that existing security tooling does not cover uniformly. AI-Infra-Guard addresses this gap by matching detection paradigms to infrastructure, tools, behavior, and models, with skill-supply-chain auditing included; its skill scanner achieves over 0.98 loose F1 with recall near 1.0 for the strongest models.

  • Problem

    AI infrastructure has expanded faster than security tooling, while agent vulnerabilities require different evidence across infrastructure, tools, runtime behavior, and models.

  • Method

    AI-Infra-Guard red-teams four agent layers using rule matching, LLM-driven auditing, multi-turn black-box testing, and attack-operator enumeration.

  • Results

    Over 0.98 loose F1 with recall near 1.0 is achieved by the strongest base models on the skill scanner benchmark.

  • Takeaways & Limitations

    The open-source framework provides a shared foundation for assessing an agent’s full attack surface, including its external skill supply chain.

  • Takeaways & Limitations

    Skill scanning assumes strict execution boundaries that restrict file access, execution, tool invocation, file sizes, and output sizes.

Abstract

from arXiv · show

The fast growth of open-source AI infrastructure, from model serving engines and agent platforms to the Model Context Protocol (MCP) ecosystem and the language models themselves, has outpaced the security tooling available to defend it. We present AI-Infra-Guard, an open-source framework that organizes AI red teaming around a single observation: the attack surface of an AI agent is stratified across layers (infrastructure, protocol/tool, agent behavior, and model), and no single detection paradigm fits all of them. The framework therefore matches a paradigm to each layer, from deterministic rule matching over 75+ AI components and 1{,}400+ vulnerability rules, through LLM-driven agentic auditing of MCP servers and agent-skill packages and multi-turn black-box agent red teaming, to a jailbreak harness with 26+ attack operators over sixteen datasets. To our knowledge it is the only open-source framework to span all of these, including supply-chain auditing of the agent skills that increasingly extend AI agents. We release AI-Infra-Guard as open source so that \emph{layer-paradigm matching} can serve as a practical foundation for agent security and a shared base for the community to build on.

1. Introduction

AI systems have created a rapidly expanding class of network-exposed software whose novelty, irregular versioning, and layered risks exceed conventional security tooling. AI-Infra-Guard addresses this attack surface by matching detection paradigms to four layers and implementing the principle across its framework.

  • Motivation: AI infrastructure spans model servers, agent platforms, workflow engines, machine-learning infrastructure, and MCP servers.Examples include Ollama, vLLM, llama.cpp, Dify, LangFlow, Flowise, ComfyUI, MLflow, Kubeflow, and Ray.
  • Problem: Novel components evade conventional tooling because vulnerability databases lack their signatures and their irregular versioning complicates identification.The passage cites build identifiers, development tags, and release candidates as examples of irregular versioning.
  • Problem: The attack surface is stratified across infrastructure, protocol/tool, agent behavior, and model layers, each with distinct vulnerabilities.Examples include a misconfigured Ollama instance, MCP command injection, system-prompt disclosure, and encoded weapon-synthesis requests.
  • Thesis: The report’s thesis is that effective assessment requires matching a detection paradigm to each attack-surface layer rather than applying one technique universally.It assigns deterministic rule-based detection to known components and signatures, and LLM-driven agentic analysis to findings requiring semantic understanding.
  • Contributions: The framework applies layer-paradigm matching across four attack-surface layers within a unified server-agent architecture.The contributions explicitly articulate the principle and use it to structure the framework.
  • Contributions: For infrastructure security, the framework combines declarative fingerprinting, vulnerability matching, version normalization, and precision stratification.Findings are classified as verified, version-based, or inferred according to the matching engine’s treatment of empty rules.

2. Background and Motivation

AI systems are surrounded by a rapidly evolving supply chain whose exposures include unauthenticated access, credential disclosure, code execution, and agent-specific misuse. Existing tools fall short because AI components require dedicated catalogues and version handling, while their risks span distinct layers best matched with complementary detection paradigms.

  • Attack surface: AI infrastructure spans inference servers, orchestration platforms, data services, and gateways, many of which are young, fast-changing, and operated outside hardened production environments.These components expose endpoints, consoles, workflow APIs, and provider access layers, creating a substantial software supply chain around deployed language models.
  • Attack surface: Unauthenticated services can enable GPU-resource abuse, model exfiltration or poisoning, and host code execution, while exposed configuration files can disclose provider endpoints and API keys.The passage identifies both infrastructure compromise and direct financial consequences from credential exposure.
  • Tooling gaps: AI components expose a cataloguing gap because mainstream fingerprint databases largely lack signatures for systems such as Ollama and Dify.Purpose-built signature corpora are required to identify these AI endpoints and consoles.
  • Tooling gaps: AI projects create a versioning gap by using build numbers, development snapshots, release candidates, and moving latest tags that violate semantic-version ordering assumptions.The passage gives llama.cpp build b7824 and 2.3.dev snapshots as examples of version formats that complicate vulnerability matching.
  • Agent-specific risks: MCP and deployed agents add behavioral attack surfaces, including malicious tool descriptions, prompt or credential disclosure, tool misuse, indirect prompt injection, and action beyond caller authority.MCP tool descriptions are consumed as trusted model context, while agents mediate between users, tools, and data sources.
  • Detection paradigms: Deterministic rule matching fits infrastructure, LLM-driven analysis fits protocol and agent layers, and attack enumeration with model-based judgment fits alignment robustness.The techniques are complementary because each addresses characteristics that the others do not capture effectively.

3. System Overview

AI-Infra-Guard decomposes the AI attack surface into four layers and matches each with a distinct detection paradigm. Its modules run as distributed server-agent tasks while sharing a common target-to-detection-to-results workflow, with agent skills audited alongside MCP servers.

  • Layer-paradigm matching: AI-Infra-Guard organizes the attack surface into four abstraction layers, each served by a different detection paradigm.This layer-paradigm correspondence is the system’s conceptual core and organizes the report.
  • Layer-paradigm matching: Detection becomes less deterministic and more semantically demanding from infrastructure to model, shifting evidence from known signatures to judged interactions.The passages state that the paradigms are not interchangeable across layers.
  • Layer-paradigm matching: Agent skills are a distinct external-capability target alongside MCP servers but use the protocol/tool layer’s LLM-driven static-analysis paradigm.Skill supply-chain auditing is treated as its own module immediately after the MCP auditor.
  • System architecture: The four modules operate as task types in a distributed server-agent architecture with a central web server, WebSocket-connected workers, and streamed structured results.Infrastructure scanning runs in-process within the agent, while the other modules are LLM-driven.
  • Common module workflow: Each module accepts a layer-appropriate target and configuration, gathers information, performs detection, and emits results through a shared external workflow.Target types include network targets, code repositories or live MCP endpoints, agent-provider configurations, and model endpoints.

4. Toward a Theory of AI Agent Security Assessment

AI systems have heterogeneous attack surfaces whose risks require different evidence and assessment paradigms. AI-Infra-Guard therefore adopts layer-adaptive assessment, matching each layer with the least expensive method capable of producing sound findings.

  • Security heterogeneity: AI systems span infrastructure, protocol and capability, behavior, and model layers with qualitatively different security properties.Examples include unauthenticated inference servers, malicious MCP tool descriptions, runtime system-prompt disclosure, and model alignment robustness.
  • Implication: No universal scanner using one assessment paradigm can provide complete coverage over the modern AI stack.The framework uses deterministic scanning for reproducibility and speed, LLM reasoning for semantics, interactive testing for runtime weaknesses, and statistical enumeration for probabilistic robustness.
  • Evidence classes: Different vulnerabilities require signature, semantic, behavioral, or statistical evidence, progressing from direct observation to repeated adversarial trials.Signature evidence covers fingerprints and exposed configurations; semantic evidence covers artifacts; behavioral evidence covers runtime interaction; statistical evidence covers probabilistic robustness.
  • Layer-evidence correspondence: Infrastructure, protocol, behavior, and model vulnerabilities respectively require observable signatures, semantic reasoning, adversarial interaction, and many adversarial trials.Each layer is associated with the weakest evidence class sufficient to establish sound security findings.
  • Layer-paradigm matching: AI-Infra-Guard matches deterministic rule matching, LLM-driven semantic auditing, multi-turn black-box red teaming, and large-scale attack enumeration to the four layers.These paradigms produce signature, semantic, behavioral, and statistical evidence, respectively.

5. Infrastructure Scanning

Infrastructure scanning identifies AI components and versions, matches them against vulnerability rules, and prioritizes deterministic, scalable detection for observable exposures. Its recall-oriented confidence tiers surface risks even when versions or public advisories are unavailable.

  • Detection architecture: Deterministic rule matching identifies known AI components, extracts versions, and evaluates vulnerability conditions with speed, reproducibility, and near-zero false positives on encoded signatures.Detection knowledge is stored in declarative YAML rules and evaluated by a compact Go engine.
  • Rule evaluation: The matching language combines body, header, icon, and hash fields with boolean operators, favoring substring containment while caching costly regular-expression patterns.Evaluation is short-circuiting and case-insensitive, and the interpreter is reused for vulnerability rules.
  • Detection architecture: Fingerprinting first establishes component identity, after which a separate version rule issues a follow-up request and extracts the version string.A component can be identified even when its version remains unknown, affecting subsequent vulnerability matching.
  • Vulnerability matching: Version normalization converts irregular strings into comparable numeric forms before vulnerability predicates are evaluated.Development and release-candidate suffixes are reduced, leading nonnumeric tokens are stripped, and empty results default to zero.
  • Vulnerability matching: Recall-favoring admission reports relevant advisories on identity alone when versions cannot be extracted, while confidence tiers distinguish verified, version-based, and inferred findings.Verified rules validate sensitive responses, whereas inferred rules can flag issues affecting all versions or lacking public proof-of-concept evidence.

6. MCP Server Auditing

MCP Server Auditing matches LLM-driven agentic analysis to a layer where vulnerabilities require understanding code behavior, tool metadata, and externally triggerable risk. Its static and dynamic harnesses use staged workflows, bounded reasoning, model routing, and review controls to produce focused, machine-readable findings.

  • Motivation: MCP-server vulnerabilities can expose command injection, credential exfiltration, or poisoned tool descriptions that deterministic infrastructure rules cannot express.These flaws require tracing inputs to dangerous sinks or judging whether natural-language descriptions match implementations.
  • Harness Design: The harness turns a general-purpose LLM into a domain security auditor through a bounded, multi-stage reasoning-and-tool-use workflow.Within each stage, the agent reasons, invokes tools, observes results, and repeats until completion, with history compaction for large repositories.
  • Audit Modes: Auditing supports static white-box analysis of source repositories and dynamic black-box analysis of live endpoints, whose available information differs fundamentally.Static analysis reads implementation, whereas dynamic analysis uses enumerated tool names, descriptions, schemas, and call results.
  • Reliability and Scale: The harness improves practicality and reliability through heterogeneous model routing, context compaction, dedicated review, and a parseable output contract.Different models handle difficult judgment, code reading, and lightweight filtering, while review removes false positives and preserves machine-readable downstream results.
  • Detection Paradigm: Prompt-as-Rule represents vulnerability knowledge as natural-language criteria containing definitions, code indicators, and explicit exclusion conditions.The rules emphasize remote attacker reachability and discard or downgrade locally exploitable issues, focusing reports on externally facing risk.

7. Agent Skills Scanning

AI-Infra-Guard audits agent skills as portable supply-chain artifacts by comparing declared purpose with implemented behavior through staged static retrieval and constrained semantic analysis. SkillTrustBench evaluates this scanner on real-world artifacts, showing that stronger base models improve detection under a fixed audit specification.

  • Threat Model: Agent skills create a portable supply-chain attack surface through poisoning, silent updates, excessive permissions, and adversarial instructions embedded in SKILL.md manifests.The scanner audits complete skill projects, including manifests, scripts, dependencies, configurations, external downloads, archives, and binary artifacts.
  • Audit Method: The scanner determines whether implemented behavior matches the declared skill purpose and classifies artifacts as normal, suspicious, or malicious.Its reasoning covers hidden instructions, unauthorized behavior, worst-case impact, and risks including credential theft, data exfiltration, persistence, and unsafe dependencies.
  • Audit Method: AI-Infra-Guard uses staged preprocessing, static risk-clue retrieval, agentic auditing, constrained tools, and structured risk classification without executing the target skill.The auditor explores files, decodes obfuscated payloads, compares behavior with purpose, and operates under directory, whitelist, size, and output limits.
  • Evaluation: 5,520 evaluation cases from 62,652 skills across nine threat categories comprise SkillTrustBench, a benchmark for agent-skill trustworthiness and scanner effectiveness.The benchmark is derived from skills collected across mainstream marketplaces and provides an objective reference for improving safety.
  • Evaluation: >0.98 loose F1 and recall near 1.0 are achieved by the strongest models, while model-dependent FPR differences separate base-model capability from the fixed audit procedure.The same scanner specification is evaluated with different base models, and improving the underlying model improves detection without changing the audit specification.

8. AI Agent Red Teaming

AI agent red teaming targets runtime behavioral vulnerabilities that are discoverable only through conversation with a black-box agent. AI-Infra-Guard uses adaptive multi-turn LLM-driven probing, parallel attack-family workers, budget-aware escalation and objective evidence to produce cost-aware findings.

  • Application-layer scope: Runtime agent weaknesses include system-prompt or credential disclosure, tool misuse, indirect-instruction obedience, and actions beyond the caller’s authority.These vulnerabilities are behavioral, often lack available source code, and must be discovered through dialogue alone.
  • Adaptive multi-turn red teaming: LLM-driven red teaming uses an attacking agent that observes each reply and adaptively chooses the next adversarial dialogue move.The interface exposes only a single-turn message-and-reply primitive, while multi-turn behavior arises from a bounded reason-act loop.
  • Attack-family execution: Four concurrent skill workers test data leakage, tool abuse, indirect injection, and authorization bypass under bounded concurrency.Each family is represented by a staged skill manifest specifying required capabilities, probes, escalation, and vulnerable-versus-safe judgments.
  • Budget-aware probing: Capability awareness, escalation, and stop rules focus dialogue spending on relevant attack surfaces and avoid unnecessary probing of absent capabilities.For system-prompt extraction, the worker progresses from direct requests to role framing and encoding bypasses, stopping after confirmation.
  • Evidence and reporting: Objective evidence strengthens findings through actual secrets, command output, SSRF canary tokens, and planted indirect-injection markers.The review report records taxonomy-mapped findings, severity, remediation, exact evidence turns, and total dialogue count as a cost measure.

9. LLM Jailbreak Evaluation

The jailbreak-evaluation module measures model safety alignment under adversarial prompting using a composable red-teaming harness with simulator, target, and evaluation models. It combines broad attack coverage, sixteen datasets, specialized LLM judges, and comparable attack-success-rate profiles.

  • Evaluation framework: The harness uses three roles—simulator, target, and evaluation models—and three composable ingredients selected and combined per run.The ingredients include a vulnerability, an attack operator, and a target model configuration.
  • Attack operators: 70+ encoding and obfuscation operators complement behavioral, single-turn, and multi-turn techniques in the attack library.Operators include base64, hexadecimal, classical ciphers, exotic scripts, invisible-text encodings, role play, system-prompt override, and prompt injection.
  • Judging success: Specialized LLM-as-judge endpoints evaluate jailbreaks and harm-specific outcomes rather than applying one uniform judgment across harms.Provided judges cover toxicity, bias, misinformation, illicit activity, PII, and agent-oriented checks, among others.
  • Datasets and harms: 16 red-teaming datasets contain approximately 7,000 harmful prompts spanning more than a dozen vulnerability types, including toxicity, illicit activity, misinformation, PII, and intellectual property.The datasets are loaded through a common loader supporting JSON, CSV, and related formats.
  • Outputs and contribution: Attack-success-rate profiles enable direct quantitative comparison of safety robustness across models, while the integrated harness consolidates attacks, datasets, and judges at scale.Each run also produces per-attempt records and an aggregate safety score.

10. System Architecture

AI-Infra-Guard uses a shared backend delivered through centralized server-agent deployments and conversational agent skills, supporting heterogeneous detection tasks through one interface. Its skill distribution also includes pure-host and hybrid options, while the skill layer is itself subject to auditing.

  • Delivery forms: The framework offers centralized CLI/web server-agent deployment and agent-skill delivery, with both forms sharing one backend and differing only in scan triggering and user placement.Agent skills let host agents invoke infrastructure, tool and skill, agent, and jailbreak scans through conversation.
  • Server-agent architecture: A central server persists task state, manages WebSocket-connected workers, and streams structured results to clients, while Go and Python executors provide fault isolation and horizontal scalability.Infrastructure scans run in-process in Go; LLM-driven modules run as Python subprocesses on workers distinct from the server and other tasks.
  • Server-agent architecture: O(1) lock-free round-robin dispatch sends fast scans and multi-minute LLM red-teams through the same task-assignment and result-reporting path.Workers route task descriptors to named executors, allowing new task types to use the uniform mechanism.
  • Observability: Typed execution events are pushed immediately through server-sent events, making plans, status, tool use, action logs, and result updates visible during multi-minute LLM tasks.The server persists streamed events and relays them with periodic heartbeats rather than waiting for batch completion.
  • Skill deployment: Agent-skill delivery supports pure-host execution and hybrid local/cloud operation, with cloud threat-intelligence use optional and constrained by data minimization.The skill auditor can run without a server, while the OpenClaw environment-health skill combines local checks with an optional service.
  • Skill deployment: The skill layer is both the distribution mechanism and an audited artifact, requiring skills that ship AI-Infra-Guard to be trustworthy themselves.This links distribution and detection through the framework’s self-protection theme.

11. Discussion

AI-Infra-Guard argues that detection paradigms should match the evidence available at each agent-security layer. Its transferable design patterns include progressively structured Prompt-as-Rule detection, objective anchors for subjective judgments, and defenses that treat the scanner itself as an attack target.

  • Layer-paradigm matching: Detection paradigms should follow the evidence required for findings: deterministic signature matching at infrastructure, model-based interpretation at protocol, and behavior elicitation at application.The discussion distinguishes layers by the kind of evidence that establishes a finding, making paradigm selection layer-dependent.
  • Transferable patterns: Prompt-as-Rule knowledge matures from boolean predicates to natural-language criteria, structured dynamic tasks, and staged attack playbooks.The progression is labeled M1, M2, M2 dynamic, and M3, respectively.
  • Transferable patterns: Objective anchors replace model judgment with deterministic checks, including SSRF canaries, planted injection markers, and content-based configuration-disclosure verification.These checks provide self-evident proof and support confidence tiering in M1 and M3.
  • Transferable patterns: LLM-driven scanners must defend against adversarial inputs through untrusted-data prompting, structural instruction-observation separation, path sandboxing, and output-focused evidence analysis.M2’s two-level defense against indirect prompt injection embodies this scanner-as-target requirement.
  • Future directions: Future work includes measuring exposure across the public AI deployment landscape and making findings at one layer inform probing at the next.The proposed directions use infrastructure-scale scanning and cross-layer cooperation to extend the framework’s reach.

12. Related Work

Related work largely addresses individual layers of the AI-agent attack surface, whereas AI-Infra-Guard combines layer-specific paradigms across infrastructure, protocol/tool, agent, and model security. Its modules build on established scanning, auditing, MCP-security, and jailbreak research while operationalizing these capabilities in a unified framework.

  • Comparative coverage: Existing open-source tools are generally strong within one attack-surface layer but do not provide comparable cross-layer coverage.Network and code scanners target infrastructure or source code, MCP auditors target the protocol layer, and LLM red-teaming frameworks probe agent and model behavior.
  • Fingerprinting and vulnerability scanning: AI-Infra-Guard adapts declarative scanning while adding AI-specific fingerprints and version-aware infrastructure coverage.Its infrastructure module follows the declarative-rule spirit of Nuclei, Semgrep, and CodeQL but uses a signature corpus built specifically for AI components.
  • LLM-driven program analysis and security auditing: The MCP auditor extends LLM-based security analysis into an agentic harness with explicit tools, a bounded reason-act loop, and Prompt-as-Rule detection knowledge.It also treats indirect prompt injection as a central risk within MCP auditing.
  • MCP and agent security: M2 and M3 operationalize detection of tool poisoning, shadowing, rug pulls, and conventional flaws through a deployable auditor and black-box agent red-teamer.This complements MCP research that catalogs the protocol’s attack surface and benchmarks tool-poisoning susceptibility on real servers.
  • Jailbreak attacks and benchmarks: The model-layer module unifies optimization-based, query-based black-box, tree-search, multi-turn, and sampling jailbreak strategies using reproducible benchmark foundations.It builds on established jailbreak techniques, SafeBench, JailbreakBench, and an open-source red-teaming framework.

13. Conclusion … E. Jailbreak Attack-Operator Inventory

AI-Infra-Guard red-teams the full AI-agent attack surface by matching infrastructure, protocol/tool, agent-behavior, and model layers to appropriate detection paradigms. The paper presents the framework as an extensible foundation for agent security as the attack surface expands.

  • 13. Conclusion: AI-Infra-Guard covers infrastructure, protocol and tool, agent behavior, and model layers using layer-specific detection paradigms.The framework matches deterministic rule matching, LLM-driven agentic auditing, and multi-turn black-box red teaming to the evidence required at each layer.
  • 13. Conclusion: Layer-paradigm matching is presented as a practical foundation for agent security as the AI-agent attack surface expands.The authors hope the framework helps the community keep pace with that expansion.
  • B. Fingerprint Matching Language: The fingerprint interpreter tokenizes expressions, builds an abstract syntax tree, and evaluates it against probe responses.It supports short-circuiting expressions, while identity matching is separated from follow-up version extraction.
  • B. Fingerprint Matching Language: A Dify fingerprint can match either a title substring or favicon hash, with version extraction performed only after identity is established.The example uses body="<title>Dify</title>" || icon="97378986".
  • A. Contributions and Acknowledgments: AI-Infra-Guard was developed by Tencent Zhuque Lab, with Table 7 listing core members and their contributions.An asterisk marks members who have since left the lab.
  • C. Version Normalization: Version rules normalize irregular AI-software version strings before comparison and intersect multiple constraints into the tightest consistent range.The procedure reports failure when constraints are disjoint.
  • D. MCP Static-Audit Detection Patterns: The static MCP auditor applies ten natural-language detection patterns aligned with the OWASP MCP Top 10 where applicable.It reports only remotely triggerable flaws under the network-reachability principle, using detection criteria, high-risk code patterns, and exclusions.
  • E. Jailbreak Attack-Operator Inventory: The model-layer harness combines algorithmic and model-driven single- and multi-turn attack operators, judged across generic and harm-specific criteria.Success is reported as an attack-success-rate profile over vulnerability × attack combinations; judges cover toxicity, bias, misinformation, illicit activity, PII, and agent-oriented checks.

F. Infrastructure Scanning: Engineering Details · G. Extensible Plugin System

The infrastructure scanner combines concurrent probing, resilient HTTP handling, passive identity signals, and bounded-memory scaling mechanisms. The jailbreak evaluator is extensible through validated plugins loaded from local or remote sources.

  • F. Infrastructure Scanning: Engineering Details: The infrastructure-scanning mechanisms are presented as engineering support for Section 5 rather than as central contributions to its argument.This appendix emphasizes robustness and scalability.
  • F. Infrastructure Scanning: Engineering Details: The probing pipeline expands CIDR targets, optionally scans AI-relevant ports with nmap, concurrently probes fingerprint paths, and evaluates boolean matchers.It determines component identity and retrieves versions only for matched components, while sharing each root document across applicable rules.
  • F. Infrastructure Scanning: Engineering Details: The hardened HTTP client accepts self-signed certificates, detects and transcodes GBK/GB2312, supports HTTP/1.1 and HTTP/2, and retries transient failures.Client errors are not retried.
  • F. Infrastructure Scanning: Engineering Details: Favicon hashing provides a passive component-identity signal by hashing FOFA-compatible base64-encoded icon bytes with MurmurHash3.The resulting icon value is used by the matching language and survives across versions.
  • F. Infrastructure Scanning: Engineering Details: Million-address target sets use a hybrid memory-and-disk map streamed from storage, bounding memory independently of input size.A sized wait group caps active probes and a rate limiter bounds throughput, tuning scans to the target environment.
  • G. Extensible Plugin System: The jailbreak-evaluation framework accepts new attack operators, vulnerabilities, and metrics through plugins without modifying its core.Plugins are discovered from a local directory, configuration file, or remote archive, then validated through source analysis and a runtime subclass check.
Loading 2606.31227v1…