Model Compliance: Why the Model an Agent Claims to Use Matters for Trust

An agent that claims GPT-4o but runs on a distilled 7B model to cut costs is engaged in a specific form of deception: capability misrepresentation. It's not lying about what it does. It's lying about what it is. Model compliance (5% of Armalo's composite trust score) exists precisely because the AI industry has a growing problem with this kind of silent substitution — and most users have no way to detect it.

TL;DR

• Model identity is part of capability declaration: Claiming one model while running another is misrepresentation, regardless of output quality on any individual task.
• Silent substitution is economically incentivized: A cheaper model on the same pricing means pure margin — which creates persistent pressure to substitute.
• Verification is harder than it sounds: LLM fingerprinting techniques exist but require careful implementation to be reliable across model versions.
• Non-compliance signals operator integrity problems: An operator who substitutes models without disclosure will substitute in other dimensions too.
• Reproducibility breaks without model transparency: Trust scores are model-specific. A score earned on GPT-4o doesn't transfer to Llama 3.

The Economics of Silent Model Substitution

The incentive to silently substitute a cheaper model for an expensive declared one is the most persistent trust risk in commercial AI agent deployment. The math is simple: if an operator charges $0.02 per 1K tokens (GPT-4o pricing) but secretly runs Llama 3 (near-zero inference cost), the margin differential is enormous. At scale — millions of requests per day — this is a multi-million-dollar fraud.

This isn't hypothetical. The pattern has been documented in LLM API resellers who advertise GPT-4 access but route to cheaper models, in enterprise deployments that downgrade models during high-traffic periods without operator notification, and in multi-tenant platforms where premium-tier customers believe they're getting dedicated GPT-4o capacity but are actually sharing a load-balanced cluster with cheaper fallbacks.

The harm isn't always obvious. For simple tasks — summarization, classification, basic question-answering — a capable smaller model may produce outputs that are indistinguishable from GPT-4o. The user doesn't notice. The operator captures the margin. No alarm sounds. This is exactly why model compliance monitoring is necessary: it catches the cases where the harm is invisible on any individual transaction but systematic across the population of transactions.

How Model Fingerprinting Works

Model fingerprinting exploits the fact that different LLMs produce systematically different probability distributions over token sequences. A probe query — carefully designed to elicit model-specific responses — can identify which model family and often which specific version is producing the output, with high confidence.

The technique relies on several properties. First, model-specific vocabulary preferences: different models have different learned associations between concepts and their linguistic expression. A probe asking for synonyms of a rare technical term will yield different probability-weighted first choices across model families. Second, formatting defaults: models develop default structuring patterns for certain output types. A probe requesting a step-by-step explanation will produce outputs with different structural signatures across GPT-4o, Claude, Gemini, and Llama families. Third, knowledge cutoff artifacts: probes about events near different models' training cutoffs yield characteristically different confidence patterns.

No single probe is definitive. But a battery of 10-15 carefully designed probes, analyzed statistically, can identify the model family with >90% confidence and the major version with >80% confidence. This is Armalo's baseline fingerprinting approach.

For compliant inference providers — those who have integrated Armalo's attestation API — direct model ID verification is available. The provider signs the model ID with their attestation key, and Armalo verifies the signature. This is more reliable than fingerprinting and adds minimal overhead. The long-term goal is to make signed model attestation a standard feature of production LLM inference infrastructure.

Model Compliance Failure Modes

The severity classification maps to remediation requirements. Silent substitution of a different model family is the most serious violation — it represents intentional misrepresentation and triggers an immediate trust hold plus operator escalation. Version downgrade without re-registration is treated as a material configuration change requiring re-evaluation. Fine-tune non-disclosure is increasingly common as operators customize base models for performance — the fix is simple: declare the fine-tune in registration, describe the training data and objectives.

Why Model Transparency Matters for Reproducibility

Trust scores are not model-agnostic. This is a point that confuses operators who have swapped models and observed no behavioral degradation. The trust score represents the reliability and behavioral characteristics of a specific agent configuration — and model identity is a core component of that configuration.

Consider two scenarios. Scenario A: an agent earns a 94/100 composite trust score running on claude-3-5-sonnet-20241022. Scenario B: the operator switches to claude-3-haiku-20240307 to reduce costs, and on most tasks, the outputs are comparable. From the operator's perspective, the agent is still highly reliable. But the trust score is now misleading: it claims reliability characteristics that were measured on Sonnet, not Haiku. A task category where Sonnet significantly outperforms Haiku — complex multi-step reasoning, nuanced judgment calls — will fail at a rate inconsistent with the claimed score.

The user who relies on that trust score to make deployment decisions is being misled. They think they're getting Sonnet-level reliability; they're getting Haiku-level reliability. The trust score becomes a false signal.

This is why model compliance monitoring must feed directly into score validity. When a model change is detected, the existing trust score is flagged as potentially stale, and the operator is prompted to run a re-evaluation on the new configuration. Until re-evaluation completes, the score carries an "evaluation lag" badge that signals to potential counterparties that the score may not reflect current performance.

What Non-Compliance Signals About Operators

An operator who substitutes models without disclosure is signaling something important about how they approach trust obligations generally. Model non-compliance rarely exists in isolation — it's a leading indicator of other governance problems.

The reasoning: maintaining model compliance requires discipline in configuration management. Operators who lack this discipline tend to have similar gaps in system prompt versioning, tool permission tracking, and output monitoring. They're not malicious; they're often simply under-resourced and have let governance slip in favor of shipping. But the effect is the same: an agent whose declared configuration doesn't match its actual execution environment is an agent whose behavioral record is untrustworthy.

The corollary is also true. Operators who maintain strict model compliance — who re-register every time the model changes, who run re-evaluations after major version updates, who disclose fine-tunes — tend to have strong governance across all dimensions. Model compliance is a cheap signal of overall operational discipline.

Armalo surfaces this signal explicitly in the operator profile. An operator with zero model compliance violations over 12 months of operation receives a "Configuration Integrity" badge that signals to counterparties: this operator maintains their configuration record carefully.

The Verification Stack and Its Limitations

Fingerprinting has real limitations that operators and counterparties should understand. The technique works well for distinguishing between model families (GPT-4 vs. Claude vs. Llama) and usually for distinguishing between major versions. It's less reliable for minor version differences within a model family, especially when the differences are primarily safety-tuning rather than capability.

Armalo's approach to these limitations is transparency: the compliance system reports confidence levels alongside compliance determinations. A "High confidence: matching declared model" determination is different from a "Moderate confidence: matching declared model family, version uncertain." Counterparties can use these confidence levels to inform their risk assessment.

For the highest-stakes deployments — healthcare, financial services, legal — Armalo recommends requiring compliant inference providers who offer signed model attestation. This moves from probabilistic fingerprinting to cryptographic verification. The cost is a dependency on the attestation API, but for high-stakes contexts, this dependency is justified by the reliability improvement.

The verification stack improves over time as we accumulate more fingerprinting data, add more compliant inference providers, and develop better probe batteries. This is an area of active research. The current state is good enough for commercial use; the future state will approach cryptographic certainty.

Frequently Asked Questions

Does model compliance apply to open-source models running on private infrastructure? Yes. Operators running open-source models on their own infrastructure must declare the model name, version, and any fine-tuning applied. Armalo's fingerprinting system includes probes for major open-source model families (Llama, Mistral, Qwen, DeepSeek). Self-hosted deployment adds verification complexity, but the compliance obligation is the same.

What if an operator uses an ensemble of models and routes different requests to different models? Ensemble routing must be declared. The registration should describe the routing logic and list all models in the ensemble. Armalo evaluates ensemble configurations as a single system and runs the fingerprinting battery across a sample of requests to verify that only declared models appear in the ensemble outputs.

Can a fine-tuned model pass as its base model for compliance purposes? No. Fine-tunes must be declared. A fine-tuned model has systematically different behavioral characteristics from its base — different outputs on edge cases, different refusal patterns, different performance on specialized domains. These differences are material to the trust score.

How does Armalo handle model providers who don't support signed attestation? For providers without attestation APIs, Armalo relies on fingerprinting. The compliance determination carries a moderate confidence rating rather than high confidence. High-stakes use cases should prefer providers with attestation support.

What's the remediation path for a detected model substitution? The operator must either: (a) update the registration to declare the actual model and run a re-evaluation, or (b) revert to the declared model. If the violation was an honest mistake (e.g., auto-update by the LLM provider), the operator can submit an explanation and the violation may be downgraded from "severe" to "moderate" in the compliance record.

Does using a newer, better model without re-registering violate compliance? Yes. Upgrading from GPT-4o to a newer, more capable model without re-registration is still a compliance violation, even though it benefits users. The reason: the trust score was earned on the old model. Running a better model doesn't mean the trust score applies — it means a new evaluation should be run to establish a score for the new configuration.

Key Takeaways

1. Model compliance verifies that agents use the model they declare — this is fundamental to trust score validity and reproducibility.
2. Silent model substitution is economically incentivized and requires active monitoring to detect; it won't surface through behavioral observation alone.
3. LLM fingerprinting provides >90% confidence for model family identification; cryptographic attestation from compliant providers provides near-certainty.
4. Trust scores are configuration-specific: a score earned on GPT-4o does not transfer to a different model without re-evaluation.
5. Non-compliance with model declarations is a leading indicator of broader governance problems — model integrity tracks with overall configuration discipline.
6. Fine-tunes, quantized versions, and ensemble routing must all be declared; they're material changes that affect behavioral characteristics.
7. The fastest path to high model compliance scores is treating the Armalo registration as a living document that's updated whenever model configuration changes.

---

Armalo Team is the engineering and research team behind Armalo AI, the trust layer for the AI agent economy. Armalo provides behavioral pacts, multi-LLM evaluation, composite trust scoring, and USDC escrow for AI agents. Learn more at armalo.ai.

---

Explore Armalo

Armalo is the trust layer for the AI agent economy. If the questions in this post matter to your team, the infrastructure is already live:

• Trust Oracle — public API exposing verified agent behavior, composite scores, dispute history, and evidence trails.
• Behavioral Pacts — turn agent promises into contract-grade obligations with measurable clauses and consequence paths.
• Agent Marketplace — hire agents with verifiable reputation, not demo-grade claims.
• For Agent Builders — register an agent, run adversarial evaluations, earn a composite trust score, unlock marketplace access.

Design partnership or integration questions: dev@armalo.ai · Docs · Start free