HRT Processor IP Exposure and Extractability Self-Test

A processor owner does not have to rely on general assurances that an API, binary, or protocol boundary is safe. The owner tests its own deployment and decides what can be exposed at each Human Runtime, or HRT, access tier.

The purpose of this self-test is to answer four practical questions:

1. What implementation information leaves the processor boundary directly?
2. What behavior can be inferred from permitted queries?
3. Can the exposed behavior be turned into a commercially useful substitute?
4. Which technical or policy changes reduce exposure without destroying utility, comparability, or legitimate research access?

The IP owner or a laboratory explicitly authorized by the owner runs the test with owned, synthetic, licensed, or otherwise approved inputs. It is not permission to test another provider.

The test is not a secrecy score

HRT does not define a universal score that labels a processor safe or unsafe. Exposure depends on what the owner is trying to protect, who receives access, how much utility the interface must provide, and what the relationship permits.

The self-test produces an exposure profile for a particular combination of:

• processor and method version;
• deployment form;
• access tier;
• output schema and precision;
• query and retention policy;
• task profile and input distribution;
• assumed recipient capability;
• test budget and duration.

A result is valid only for that configuration. A provider-hosted API, a customer-hosted container, and a research package are different exposure surfaces and are tested separately.

Step 1: define the protected assets

The owner begins by identifying what constitutes a meaningful loss.

Implementation IP

• source code;
• model graph or weights;
• feature engineering;
• signal-processing pipeline;
• thresholds and decision rules;
• calibration and normalization methods;
• provider-specific intermediate states;
• internal confidence calculation;
• optimization and deployment techniques.

Data IP

• training and calibration datasets;
• customer or participant records;
• labeled examples;
• proprietary task ontologies;
• reference distributions;
• rare or commercially important cases.

Functional IP

• the ability to reproduce useful processor behavior;
• decision-boundary behavior;
• performance in the owner's commercially important domains;
• mapping from inputs to provider states or recommendations;
• provider-specific explanations or ranking behavior.

This distinction matters. A test may fail to recover source code or weights but still produce a substitute with enough functional fidelity to affect the business.

Step 2: define authorized comparison and unacceptable extraction

Ordinary evaluation is not automatically an IP failure. Before testing, the owner classifies intended uses.

Expected and permitted

• conformance testing;
• latency and availability measurement;
• calibration and outcome evaluation;
• fixed benchmark runs;
• private head-to-head comparison;
• provider-approved research;
• agreed joint development.

Separately authorized

• bulk retention of input–output pairs;
• adaptive diagnostic querying;
• exporting a reusable training corpus;
• fitting a substitute processor;
• inferring internal thresholds or features;
• publishing provider-identified benchmark results;
• redistributing a local processor package.

The self-test measures whether separately authorized behavior is technically possible through an ordinary access tier. It does not declare all learning or reverse engineering illegitimate.

Step 3: enumerate every exposure surface

The owner tests more than the public API.

Protocol and discovery surfaces

• public HRT Processor Profile;
• public A2A Agent Card;
• authenticated extended Agent Card;
• API schema and documentation;
• capability negotiation;
• error messages and status endpoints;
• version and health information.

Result surfaces

• exact continuous scores;
• categories or quality bands;
• confidence or probability vectors;
• explanations and feature attribution;
• intermediate states;
• timestamps and validity windows;
• raw and aggregated history;
• comparison and evaluation exports.

Operational surfaces

• OpenTelemetry spans, logs, metrics, and baggage;
• support bundles and crash reports;
• debug endpoints;
• caches and temporary files;
• object storage and data-export paths;
• client-side analytics;
• monitoring dashboards and alerts.

Distributed artifact surfaces

• containers and virtual-machine images;
• mobile or desktop applications;
• native libraries;
• WebAssembly packages;
• model files such as ONNX;
• SDKs and example code;
• source maps, symbols, configuration, and dependency manifests;
• trusted-execution packages and attestation metadata.

Step 4: run the direct-disclosure review

The owner inspects everything available to a normal recipient at the tested tier.

Check whether the interface or distributed package reveals:

• internal metric names or feature names;
• model type, graph structure, or weight tensors;
• thresholds or calibration constants;
• training-data paths, labels, or record fragments;
• debug symbols, source maps, stack traces, or internal service names;
• embedded credentials, signing material, or decryption keys;
• proprietary prompts, rules, or configuration;
• high-precision intermediate results that are not needed by the application;
• undocumented endpoints or elevated capabilities;
• a method-version identifier that encodes sensitive internal detail.

This review includes telemetry. A carefully restricted API can be undermined if logs or spans record raw inputs, exact outputs, intermediate features, or hidden prompts and forward them to a customer-controlled backend.

Direct-disclosure result

Record each finding as:

• intended disclosure;
• unnecessary disclosure;
• secret or credential exposure;
• implementation disclosure;
• data disclosure;
• uncertain and requiring owner review.

Any exposed credential, private key, source archive, model weight file, or identifiable training record stops the test and triggers remediation before broader querying continues.

Step 5: run the black-box extractability test

This is the core functional test. The owner treats its own exposed processor as a queryable system and attempts to train a surrogate using only information available at the tested access tier.

Test design

1. Create a representative but approved input pool.
2. Keep a separate holdout set that the surrogate-building process cannot inspect.
3. Establish a simple baseline that does not query the protected processor.
4. Query the processor under the real access policy and budget.
5. Train several reasonable surrogate families using the collected input–output pairs.
6. Evaluate the surrogates on the hidden holdout set and on commercially important edge cases.
7. Plot fidelity and task utility against query count, time, and financial cost.
8. Repeat the test for each proposed output mode and disclosure tier.

The test includes both ordinary representative sampling and an adaptive phase that concentrates permitted queries where the surrogate is uncertain or where outputs change. Adaptive querying is important because extraction risk is often driven by the ability to probe boundaries rather than by average traffic.

Measures for categorical outputs

• agreement with the protected processor;
• macro and per-class precision, recall, and F1;
• agreement on rare or high-value cases;
• decision-boundary agreement;
• task-outcome performance relative to the original processor;
• calibration of the surrogate where probabilities are available.

Measures for continuous outputs

• mean absolute and squared error;
• rank correlation;
• explained variance;
• agreement within operationally meaningful tolerances;
• agreement around intervention or category thresholds;
• downstream task utility relative to the original processor.

Query-efficiency measures

• queries required to exceed the no-query baseline;
• queries required to reach 80%, 90%, and 95% behavioral fidelity;
• wall-clock time and cost to reach each level;
• gain from adaptive queries over ordinary sampling;
• gain from precise confidence values, explanations, or history;
• transfer to devices, populations, and tasks not used for surrogate training.

Exact parameter recovery is not required for a serious finding. A surrogate that reproduces the commercially important behavior at low cost can represent high functional exposure even if it uses a completely different architecture.

Step 6: test behavioral and threshold inference

Some processor IP can be inferred without training a complete surrogate.

Using approved synthetic or controlled inputs, test whether an ordinary recipient can infer:

• intervention thresholds;
• category transition points;
• normalization ranges;
• baseline adaptation behavior;
• window length and update frequency;
• missing-data rules;
• sensor-priority rules;
• which features dominate an output;
• whether a person or session identifier changes the calculation;
• model-version changes from output behavior alone.

Record how many queries and how much prior knowledge each inference requires. Separate obvious semantic behavior that must be documented from provider-specific behavior that is not necessary for interoperability.

Step 7: test data and privacy leakage separately

Processor IP exposure and participant-data leakage are related but distinct risks. The owner runs a separate approved test for:

• training-membership inference;
• recovery of rare labels or memorized examples;
• reconstruction of sensitive input attributes;
• leakage through explanations, confidence, errors, or nearest-example features;
• cross-person or cross-customer information revealed by shared baselines;
• historical state available beyond its authorized retention period.

Use synthetic canaries or records created specifically for the test wherever possible. Do not place real participant data into a security exercise unless the authorization and safeguards explicitly cover it.

Step 8: test access-tier isolation

Verify that the system enforces graduated disclosure rather than merely documenting it.

Test whether a result-tier client can:

• request metric-tier precision;
• recover exact confidence from repeated categorical queries;
• enumerate history beyond its retention window;
• access research or debug endpoints;
• change task purpose without reauthorization;
• combine exports to reconstruct a restricted corpus;
• reset quotas through new sessions, credentials, organizations, or agents;
• obtain privileged extended-card information from the public Agent Card;
• cause raw data or intermediate values to appear in errors or telemetry.

The owner tests both one identity and several authorized test identities to determine whether budgets are enforced at the correct organizational and processor levels.

Step 9: test distributed and local deployments

A local package receives a stronger test because the customer controls the host.

The owner assumes that a determined recipient can inspect files, processes, memory, system calls, network behavior, update packages, and execution timing. The test evaluates whether the local deployment exposes materially more than the agreed tier.

For ordinary binaries, containers, or WebAssembly packages, measure how much protection remains after removing superficial packaging and obfuscation. Do not treat successful obfuscation against one tool as proof of non-extractability.

For a trusted execution environment, verify:

• the attested code identity;
• key release policy;
• rollback protection;
• debug-state handling;
• allowed outputs;
• failure behavior when attestation is absent or invalid;
• what the host can still learn from timing, sizes, and invocation patterns.

The test report states explicitly whether protection depends on contract, software obfuscation, operating-system isolation, hardware isolation, or provider custody.

Step 10: compare mitigations experimentally

The owner reruns the same extraction test across alternative interface designs.

Recommended comparison matrix:

The objective is not to minimize information at any cost. It is to find the lowest disclosure that still supports the intended application, scientific interpretation, fair comparison, and partner relationship.

Recommended result classes

The owner sets numerical thresholds based on its own business and technical risk. HRT provides descriptive classes without pretending that one threshold fits every processor.

Controlled

• no unintended direct disclosure;
• the permitted query budget does not produce a surrogate with material task utility beyond baseline;
• access tiers and retention limits hold;
• required comparison and application utility remain intact.

Review

• a surrogate gains meaningful fidelity or task performance;
• thresholds or features can be inferred more easily than expected;
• telemetry or history provides unnecessary precision;
• exposure may be acceptable for the intended partner but not for general access.

High exposure

• a commercially useful substitute can be produced within an ordinary customer's expected budget;
• model artifacts, weights, source, secrets, or proprietary intermediate features are directly recoverable;
• access-tier restrictions can be bypassed;
• training or participant data can be recovered beyond the authorized purpose.

High exposure does not automatically mean the processor cannot participate in HRT. It may mean that the deployment belongs at a research or development tier, requires a hosted boundary, needs different output precision, or needs explicit licensing and commercial terms.

Minimum private test report

test: hrt.processor.ip_exposure
test_version: 0.1.0
illustrative_only: true
owner: example-provider
processor:
  id: example.cognitive-processor
  version: example-profile-4f2
deployment: provider_hosted
access_tier: metric
task_profile: aviation.training.example.v1
inputs:
  source: synthetic-and-owner-approved
  records: 12000
query_policy:
  total_budget: 10000
  rate_limit_per_minute: 60
outputs:
  precision: categorical
  quality: three-band
protected_assets:
  - feature_pipeline
  - calibration_method
  - commercially_useful_functionality
results:
  direct_disclosure_findings: 0
  best_surrogate_fidelity: 0.68
  baseline_fidelity: 0.61
  task_utility_ratio_to_original: 0.54
  threshold_inference: partial
  tier_bypass: false
classification:
  owner_assigned: controlled
publication: private
tested_at: 2026-09-24T00:00:00Z

The detailed report remains with the owner unless it chooses otherwise. HRT may receive only a signed attestation containing the tested processor version, deployment type, access tier, test version, date, result class, evaluator identity, and expiry.

Recommended cadence

Run the self-test:

• before exposing the first HRT processor interface;
• for every materially different access tier;
• before distributing a local package;
• after meaningful changes to outputs, confidence, explanations, or query policy;
• after a major processor or calibration revision;
• when adding a new device, population, or vertical profile;
• after changes to telemetry, logging, support, or export paths;
• periodically for long-lived production interfaces.

What HRT provides

HRT can make the test inexpensive for small providers by supplying:

• synthetic input generators;
• an owner-run query harness;
• baseline surrogate templates;
• fidelity and query-efficiency reports;
• telemetry and artifact disclosure checklists;
• access-tier isolation tests;
• a private report template;
• a minimal signed attestation format;
• an optional independent-review procedure.

The harness runs locally or inside the provider's environment by default. HRT does not require the provider to upload the processor, raw dataset, extracted surrogate, or detailed vulnerability report.

Initial specialist-provider test

Begin with a narrow, owner-operated comparison of three interfaces over synthetic or provider-approved episodes:

1. exact score plus exact confidence;
2. score plus an uncertainty band;
3. categorical state plus declared quality and validity.

Use the same query budget and holdout outcomes for all three. Measure application utility, outcome prediction, surrogate fidelity, threshold inference, and query efficiency. Also inspect every resulting HRT span and log to confirm that the more restrictive interface is not undermined by telemetry.

This test gives the provider evidence for choosing its first HRT profile. It also shows which additional detail can safely be offered to validation or research partners.

Bottom line

The owner tests the interface as both a product surface and a potential learning surface.

A good processor boundary permits use, evaluation, and authorized learning. It makes unintended implementation disclosure and low-cost substitution measurable before the interface is opened more widely.

The goal is not to promise that reverse engineering is impossible. The goal is to let the provider see where functional exposure begins, choose that boundary deliberately, and verify that the deployed controls match the chosen relationship.

Related reading

• Competition and Composability Between Processors While Protecting Their Implementations
• When Open Interfaces Protect IP—and When They Expose It
• You Do Not Need to Own the Mind to Observe the Runtime
• Human Runtime Cognitive Metrics