Who Is the Model? AI Identity Verification and the Rupiah Confidence Perimeter

Rupiah Stability Watch · 2026-09-02

The premise

This is not an argument that artificial intelligence is moving USD/IDR today. The narrower question is operational: as banks, payment providers, FX and money-market participants, logistics platforms, procurement systems, and public agencies add AI tools to rupiah-relevant workflows, can they verify which model or agent was in use when a consequential decision was prepared or executed?

That question now has a technical literature of its own. A 31 August 2026 arXiv paper, “Auditing Anonymous AI Models: A Four-Stage Protocol for Black-Box Identity Verification”, describes a market in which API-served models can be released under codenames, with vendor identity or model lineage unclear. The paper’s core point is modest but important: self-identification by the model is not trustworthy, and platform or vendor disclosure may not be available when operators need assurance.

For rupiah stability, the relevance is not the model’s intelligence in the abstract. It is the confidence channel. A payment operator, bank, port scheduler, fuel importer, or public agency may certify one workflow, vendor, model family, and tool-permission envelope, then later discover that the active model, endpoint, or behavior changed. In a calm period this is a governance defect. During market stress, cyber incident response, sanctions screening, procurement exception handling, or public communications, it can become a confidence defect.

What model-identity verification tests

The arXiv protocol tests identity indirectly, because the model is treated as a black box. Its four stages are: reconstructing launch-time configuration from archived platform snapshots; fingerprinting configuration such as context window, output ceiling, modality, and reasoning features against platform catalogs; testing tokenizer identity through cross-length differentials; and corroborating with behavioral probes.

That stack does not prove everything. It can support a graded inference about family or version line. It can expose drift between preview and production specifications. It can reject some weak guesses. But the paper is explicit that its retrospective test was “declaration consistency” on known-identity releases, not complete end-to-end identification under all anonymous conditions. It also notes that a prospective case confirmed family and version-line inferences while leaving deployment variant less certain.

This is the right scale of claim. Black-box identity testing is not a substitute for procurement due diligence, source-code review, contractual disclosure, human approval, or tamper-evident logs. It is a way to ask: does the system we are touching behave like the model we approved, or like something materially different?

Where the question becomes rupiah-relevant

The first rupiah-relevant sites are not speculative trading bots. They are routine operating systems whose failure can widen spreads, delay payments, slow trade, or weaken public confidence.

In retail payments, model identity would matter wherever AI assists fraud triage, transaction monitoring, merchant onboarding, complaint handling, or incident communications around QRIS and instant transfers. Bank Indonesia’s public material describes QRIS as a payment standard developed with the payment industry to make QR-code transactions faster, more convenient, affordable, secure, and reliable, and the Indonesia Payment System Blueprint 2030 is framed around a resilient payment system for the digital economy. If AI is introduced into monitoring or exception handling on such rails, knowing the active model becomes part of knowing the control environment.

In BI-supervised market infrastructure, the connection is even clearer. Bank Indonesia Regulation Number 2 of 2024 covers information-system security and cyber resilience for payment system providers, money-market and foreign-exchange market participants, and other BI-regulated parties. That perimeter overlaps the places where a model substitution or unannounced endpoint change could affect operational readiness: treasury workflows, FX confirmation support, liquidity dashboards, incident escalation, and cyber triage.

In OJK-supervised banking, the anchor is AI governance rather than currency policy. OJK’s Artificial Intelligence Governance for Indonesian Banks, launched on 29 April 2025, says it is intended to guide responsible AI development and implementation, complement existing digital-transformation, IT, cyber-defense, digital-maturity, and digital-resilience guidance, and serve as a minimal benchmark while prioritizing risk management and prudence. Model identity is not the whole of that benchmark, but it is one practical field in the AI inventory: what model, what version, what vendor, what data terms, what tool rights, and what fallback.

Beyond finance, the same issue touches ports, logistics scheduling, energy dispatch, procurement exceptions, and public communications. These systems do not set the exchange rate. But they help determine whether imported goods move on time, whether fuel and food logistics remain steady, whether public messages are consistent during disruption, and whether businesses trust automated exceptions. Rupiah pressure often arrives through such operating channels before it appears as a single headline.

How identity differs from authority, logs, and provenance

The control stack has several layers, and confusing them creates false comfort.

Model identity asks who the computational actor is: model family, version line, deployment channel, serving vendor, endpoint, and material configuration. Authorization controls ask what that actor is allowed to do: read files, call APIs, send messages, approve payments, change procurement records, or only draft recommendations. Audit logs ask what happened: prompts, tool calls, approvals, outputs, timestamps, and operator actions. Provenance chains ask where the inputs, model artifacts, and outputs came from and whether they were altered. Human approval asks who accepted responsibility at the decision point.

Each layer covers a different failure mode. If the model identity is wrong, a perfectly logged action may still be the action of an uncertified system. If authorization is loose, a correctly identified model can still act beyond its mandate. If logs can be spoofed, both identity and permissions may be hard to reconstruct after an incident. If human approval is generic, the approval may not bind to the model, output, data snapshot, and tool-permission state that were actually used.

The least-harm architecture is therefore not one heroic control. It is a registry and record: approved model and version; vendor and endpoint; data-handling terms; tool permissions; human approver; pre-deployment identity check; runtime drift check; tamper-evident action log; and fallback procedure. The point is not to slow useful adoption. It is to keep operators from discovering the real actor only after a payment incident, compliance failure, or public-message error.

What the wider oversight record supports

The global supervisory record points in the same direction. NIST’s AI Risk Management Framework is intended to improve how organizations incorporate trustworthiness considerations into the design, development, use, and evaluation of AI systems, and NIST released a Generative AI Profile in 2024 plus a 2026 concept note for trustworthy AI in critical infrastructure. That is not Indonesia-specific, but it supports a general principle: AI assurance has to be lifecycle assurance, not just a one-time model demo.

The Financial Stability Board’s 2024 AI work is also relevant. In its public summary, the FSB identifies third-party dependencies and service-provider concentration, market correlations, cyber risks, and model risk, data quality, and governance as AI-related vulnerabilities with potential systemic relevance. It also calls for better data and information gaps so authorities can monitor AI adoption and assess financial-stability implications.

Model identity sits inside those gaps. If an authority cannot observe which models are materially present in financial workflows, it cannot distinguish ordinary outsourcing risk from AI-specific substitution, drift, concentration, or correlated behavior. The point is not public disclosure of every implementation detail. The point is supervisory visibility sufficient to reconstruct an incident without guessing.

A least-harm watchlist for Indonesia

A proportionate watchlist would start with high-consequence workflows rather than all AI use. The first question is whether an AI system touches payment operations, market operations, cyber triage, compliance screening, procurement exceptions, logistics scheduling, energy dispatch, or official incident communications. If not, a lighter register may be enough.

Where the answer is yes, the record should include seven fields.

First, a model and version registry: approved model family, version line, deployment channel, vendor, endpoint, and material configuration. Second, vendor change disclosure: notice when routing, model weights, endpoint behavior, data retention, or tool support changes in ways that matter to the approved use case. Third, pre-deployment identity checks: not to prove metaphysical identity, but to test whether the deployed system matches the approved record. Fourth, runtime drift checks: periodic and incident-triggered checks for configuration or behavioral shifts. Fifth, tamper-evident action logs: prompts, tool calls, outputs, approvals, and system messages bound together. Sixth, approval binding: human approval attached to the specific output, model state, data snapshot, and permission envelope. Seventh, incident fallback: a tested route to human/manual operation or a certified simpler system when identity cannot be established.

This is a confidence perimeter, not a ban. It accepts that banks and public systems may use AI productively. It asks that the actor be inspectable enough for supervisors and operators to know what changed when something goes wrong.

What the evidence does not support

The evidence does not show that anonymous models are already embedded in Indonesian critical financial infrastructure. It does not show that model substitution has caused rupiah depreciation. It does not justify treating all AI tools as unstable or unusable.

The evidence supports a narrower conclusion: where AI enters rupiah-relevant workflows, model identity is now a practical operational-resilience variable. It should sit beside authorization, logging, provenance, and human approval, not behind them.

What I am uncertain about

The largest uncertainty is the base rate. Public evidence does not yet show how often model substitution, endpoint drift, or identity mismatch occurs in regulated Indonesian workflows. The arXiv paper provides a useful protocol and a small validation record, not a population estimate for Indonesia.

The second uncertainty is deployment depth. Indonesian banks, payment providers, fintech firms, logistics operators, and public agencies may use AI unevenly, with some use cases only advisory and others closer to action. Public documents rarely disclose enough to place each workflow on that spectrum.

The third uncertainty is supervisory burden. Too little disclosure leaves supervisors blind. Too much disclosure can slow useful adoption or expose sensitive security architecture. The least-harm balance is probably a tiered register: light for low-risk tools, strict for systems that can affect payments, market operations, compliance outcomes, infrastructure scheduling, or public incident response.