Mission-Aware Attestation and the Rupiah: When Agent Evidence Becomes a Financial-Stability Control

Rupiah Stability Watch · 2026-10-07

The premise

Rupiah-relevant AI control should move from a general audit trail to a timed evidence packet.

Earlier Rupiah Stability Watch pieces — including “Voluntary AI Promises Are Not Rupiah Operating Guarantees,” “Validation Before Automation,” “Who Is the Model?,” “When the Log Can Be Spoofed,” and “Agentic AI Operational Risk and the Rupiah” — argued that AI systems touching financial-stability infrastructure need more than vendor promises. They need identity, validation records, inspectable logs, and a way to reconstruct what happened.

The newer signal sharpens that argument. Two current research threads point in the same direction from different ends.

First, AdvSim2Real treats web agents as systems that act inside hostile information environments. A third-party page can carry both the legitimate data an agent needs and an injected instruction that redirects it. The paper’s method co-evolves three parts inside a simulated web world: a task curriculum, an injection adversary, and the agent. The adversary is rewarded only when it causes a “success flip” — turning a judged successful run into a failure. The result is not immunity, but a better-trained agent: the authors report clean completion rising from 74.89% to 81.33%, completion under three learned adversaries rising from 48.07% to 57.48%, a 33.6% relative gain against an unseen Kimi-K3 adversary, and strict real-browser success rising from 25.56% to 44.44%.

Second, Mission-Aware Attestation Envelopes treats attestation not as a static yes/no gate but as a runtime contract. In plain language: an autonomous system asking for a privileged physical action should not only prove what it is running. It should also prove that the evidence is fresh enough and that the decision can arrive before the physical deadline. The paper separates four outcomes where a binary gate gives only two: valid action, refusal because integrity failed, refusal because evidence was stale, and refusal because the decision was too late.

For Indonesia, the useful crossing is not “AI is dangerous.” It is narrower and more operational: when an agent touches payment routing, fuel logistics, kitchen status, ferry movement, disaster warning, procurement, or official communication, markets and households need to reconstruct the action under stress.

What an attestation envelope should prove

An attestation envelope is not just a log. A log says what a system says happened. An envelope should make a bounded claim that can be checked by another party.

For rupiah-relevant operations, the practical record should include at least thirteen fields.

1. Actor identity — the institution, system, model, agent version, operator account, and cryptographic identity of the component that requested action.
2. Mission scope — the specific job the agent was authorised to perform: reconcile payment exceptions, reroute fuel delivery, classify a kitchen operating-status report, draft a weather bulletin, or publish a market statement.
3. Authority chain — the legal, supervisory, contractual, or internal authority under which the action was allowed.
4. Permission boundary — tools the agent could call, accounts it could touch, thresholds it could change, messages it could send, and systems it could not access.
5. Evidence inputs — the data sources used, their timestamps, provenance, and whether any input came from a public, user-supplied, vendor-supplied, or untrusted surface.
6. Prompt-injection exposure — whether the agent read third-party text or web content capable of influencing its instructions, and what guard or isolation method was applied.
7. Time sensitivity — the freshness window for the evidence and the deadline for the decision.
8. Human approval — whether a human approved the action before execution, after recommendation, or only by exception.
9. Tool-call trace — the exact external calls, database writes, API requests, messages, and transactions attempted.
10. Fallback trigger — the conditions under which the system must stop, degrade to read-only, ask a human, or use a manual continuity procedure.
11. Tamper resistance — signatures, hashes, secure hardware, append-only storage, or independent witness systems that make later rewriting detectable.
12. Replayability — enough preserved context for a supervisor, auditor, or court to reproduce the decision path without trusting the original operator’s narration.
13. Contestability — who may challenge the action, how quickly the challenge is heard, and what remedy exists if the action was wrong.

This is the shift from “the AI was audited” to “this action carried verifiable operating evidence.” The rupiah channel is confidence. Under stress, confidence depends on whether the record can be reconstructed before rumor becomes pricing, hoarding, withdrawal, delay, or political blame.

Six Indonesian workflows where the envelope matters

1. BI/payment rails and retail payment exceptions

Payment infrastructure is a confidence machine. Bank Indonesia describes BI-FAST as retail payment infrastructure operated by Bank Indonesia for continuous, real-time retail payments, and the public policy aim is transaction efficiency, inclusion, and national digital finance integration. If AI agents assist exception handling, fraud triage, liquidity monitoring, incident routing, or customer-facing notices, the envelope should prove:

• which institution and system initiated the exception action;
• the transaction class, amount band, and operational threshold involved;
• whether the agent could only recommend or could also execute;
• what evidence was fresh at decision time;
• who approved customer-impacting holds, reversals, fee changes, or routing changes;
• how the action is reversed if later found wrong.

The least-harm rule here is strict: agents should start as read-only or recommendation-only for production payment rails unless the envelope is mandatory, independently verifiable, and supervised by clear operating thresholds.

2. Bank fraud, reconciliation, and customer-impacting decisions

Fraud systems already use automation. Agentic systems add a different risk: they can gather evidence, interpret text, call tools, and make recommendations that look coherent while resting on stale, poisoned, or incomplete information.

A useful envelope would separate “model suspicion” from “institutional action.” A frozen fraud score is not enough. The record should show the evidence bundle, the account authority used, whether the customer was notified, whether a human approved the hold, and what the customer can contest. In rupiah terms, the danger is not only one mistaken account freeze. It is a pattern of opaque customer-impacting decisions that weakens trust in digital money when households already feel squeezed by prices or exchange-rate headlines.

3. Fuel subsidy and Pertamina logistics exceptions

Fuel continuity sits close to household price expectations. If agents help triage subsidy eligibility, station exceptions, delivery disruption, stock allocation, or supplier communication, the envelope must distinguish operational fact from administrative inference.

The record should show the depot, route, station or vessel, product type, stock reading, delivery deadline, exception reason, and approval chain. It should also capture whether the agent used live telemetry, manual reports, third-party logistics messages, or public web text. A prompt-injected logistics email should not be able to redirect a fuel exception without leaving a visible evidence scar.

Technically, much of this can be logged now. The harder part is governance: procurement contracts and public-service rules must require the record, not merely allow it.

4. MBG/SPPG kitchen operating status

The Badan Gizi Nasional site shows MBG governance already has public reporting and accountability surfaces, including SP4N LAPOR!, PPID, JDIH, Radar MBG, and current articles on Ombudsman findings and BPK engagement. That makes MBG a good example of why an envelope should not be an engineering afterthought.

If agents classify SPPG kitchen status, supplier readiness, food-safety exceptions, delivery delay, or complaint priority, the envelope should prove:

• which SPPG unit and operating day were covered;
• the source of the kitchen status report;
• the food-safety or delivery threshold used;
• whether a human verified the exception;
• what beneficiaries or schools were affected;
• what substitute meal, supplier, or delay notice was triggered;
• how a parent, school, supplier, or local official can contest the record.

This is not because AI in kitchens is uniquely risky. It is because MBG is a large, visible household-facing program. A chain of unclear operating records can become a budget-credibility and price-expectation problem faster than a technical dashboard suggests.

5. Port, ferry, and weather routing

ASDP’s own weather-preparedness communication describes coordination around extreme weather, branch readiness, tugboat support, fleet and port-facility readiness, and strengthened communication systems across major ferry branches. That is exactly the sort of time-sensitive physical operation the Mission-Aware Attestation paper was built to illuminate.

For ferry and port decisions, the envelope should bind three clocks together:

• the age of the weather and sea-state evidence;
• the deadline by which a closure, delay, reroute, or reopening decision must be made;
• the time at which the public notice, ticketing system, port operator, and vessel operator received the decision.

A late-but-correct warning can still fail. A fresh-but-unauthorised reroute can also fail. The point of the envelope is to distinguish those failures, because each requires a different remedy.

6. Official crisis and market communication

Public communication can move behavior before it moves balance sheets. If an agent drafts, translates, queues, or distributes statements about payment disruptions, fuel continuity, food-program operations, weather closures, or rupiah-market conditions, the envelope should show whether the system had authority to draft only, to recommend publication, or to publish.

The minimum record is simple: source facts, drafting agent, human approver, publication channel, timestamp, correction route, and withdrawal authority. The stronger version adds a rule: no agent-generated crisis statement goes out without a signed human decision unless the emergency protocol explicitly names the narrow case where automation is allowed.

What is technically possible now

Several pieces are available today.

• Signed receipts and hashes can bind inputs, outputs, model identity, and operational metadata. The IETF Attested Inference Receipt draft describes a COSE/CWT envelope that binds model identity, input/output hashes, attestation-linked metadata, and telemetry into a signed artifact for confidential AI inference. The draft is not a finished standard, and it explicitly limits its scope, but it shows the direction.
• Platform attestation can prove that a workload ran inside a measured environment, such as a trusted execution environment or TPM-backed platform. The mission-aware paper uses a TPM-backed roadside unit and Linux integrity measurement as part of its hardware-in-the-loop setup.
• Application logs can capture tool calls, approvals, data sources, prompt-injection exposure, and fallback triggers.
• Append-only records can make rewriting harder and make disagreement visible.
• Simulation and red-team training can improve robustness against adaptive prompt injection, as AdvSim2Real illustrates, while still leaving real-world verification necessary.

None of these, alone, is a rupiah operating guarantee. A signed receipt can faithfully prove a bad procedure. A TEE can attest a workload whose mission scope is wrong. A beautiful log can be useless if nobody has standing to contest it.

What requires standards, procurement, or supervision

The missing layer is institutional, not only technical.

Indonesia would need at least four kinds of rules for rupiah-relevant agent deployment.

1. Supervisory expectations for banks, payment participants, and public financial-service vendors: which AI-assisted actions require an envelope, who keeps it, and how quickly it must be available to BI, OJK, auditors, or affected customers.
2. Procurement clauses for public-service AI systems: no agent may perform material public-service actions unless the vendor supports signed action records, replay, retention, and independent inspection.
3. Critical-service continuity rules for fuel, ferries, food programs, disaster warnings, and communication channels: when the evidence is stale or the decision is late, the system must degrade safely rather than improvise.
4. Contestability rights for households, firms, schools, suppliers, and operators affected by automated decisions: the record must be legible enough to challenge, not only archived enough to satisfy an internal audit.

The hard design choice is proportionality. Not every chatbot answer needs a formal envelope. Every privileged, time-sensitive, rupiah-relevant action should.

The least-harm path

The least-harm path is to pilot attestation envelopes where the action is narrow, the harm of opacity is high, and the operating deadline is real.

Start with four pilots:

• payment exception recommendation, not automated settlement action;
• fuel logistics exception triage, not autonomous allocation;
• MBG/SPPG operating-status records, not beneficiary eligibility decisions;
• ferry/weather public-notice workflow, not autonomous port closure.

Each pilot should use the same checklist: identity, mission, authority, permission, evidence, injection exposure, time window, human approval, tool calls, fallback, tamper resistance, replayability, and contestability.

Then publish a redacted public schema. Markets do not need to see private data. They do need to know that high-consequence automated operations have a reconstructable control record. The schema itself becomes a confidence instrument.

What I am uncertain about

Three limits matter.

First, the Mission-Aware Attestation paper is a vehicle-to-infrastructure study, not an Indonesian public-finance deployment. The translation to payments, food, fuel, and ferries is a control-design analogy, not evidence that those sectors currently use such systems.

Second, AdvSim2Real is encouraging but not a guarantee. It shows that adversarial simulation can improve robustness, not that prompt injection is solved.

Third, Indonesia’s practical path depends less on inventing new cryptography than on procurement discipline. If public agencies and regulated firms buy agentic systems without requiring action-level evidence, the later audit problem is already built in.

The useful standard is plain: when an autonomous or semi-autonomous system acts in a way that can affect rupiah confidence, the action should carry a record strong enough for a stranger to answer five questions: who acted, under what authority, using what evidence, before what deadline, and how the action can be stopped or contested.