Set spending limits
Approve one recipient, a per-call cap, a lifetime budget, an agent key and an expiry. The signature also binds the grant to its chain, vault and owner epoch.
OLD TECH. NEW ERA.
SIM signing
for AI agents.
AgentSIM explores using compatible SIM cards to sign an agent’s permissions. A small Java Card applet lets a compatible SIM sign messages with P‑256.
SIM SIGNING · NEAR SANDBOX · TEST FUNDS
AUTHORITY LINK OWNER → AGENT
AGENTSIM™
OWNER AUTHORITY
STAYS WITH YOU.01 / 98
STAYS WITH YOU.01 / 98
● P‑256 OWNER KEY
≠ AGENT SESSION KEY
≠ AGENT SESSION KEY
● WORKING SANDBOX DEMOJAVA CARD / P‑256EST. 2026
01 / HOW IT WORKSHow agent
How agent
permissions work.
A Java Card applet signs the owner’s permission with P‑256. The agent runs separately and signs requests with Ed25519. A Rust vault enforces the signed limits on a private NEAR sandbox.
AUTHORIZATION BUS ILLUSTRATED SANDBOX FLOW
01OWNERReview & sign
02GRANTSupplier · cap · expiry
03AGENTSign a request
04NEAR VAULTEnforce the budget
P‑256 → owner permissionEd25519 → agent requests
The vault checks each signed payment against the owner’s grant.
Owner and agent keys
The PC/SC host checks the pinned owner key, asks for the PIN and verifies the returned P‑256 signature. The same product applet can run in jCardSim for reproduction. The agent keeps a separate Ed25519 key.
Verify each request
The Rust vault checks signatures, recipient, nonce, expiry and budget before reserving funds. A restricted relayer key can call only this vault’s execute method, with zero attached deposit.
Revoke access
The owner can revoke a grant or pause the vault. Already accepted transfers may remain in flight; revocation cannot undo them.
Implementation: Verification guide ↗ · Signed protocol ↗ · Rust vault ↗
COMPATIBILITY MAP CARD PROVISIONING
Suitable card + provisioning permission + trusted approval
SIM support
and requirements.
A physical SIM signing path is implemented through PC/SC. Using it on a phone still requires a compatible card, authorized applet installation and a handset screen where the owner can review the recipient and budget.
COMPATIBLE SIM→INSTALL APPLET→USE
Not every SIM supports P‑256 or allows applet installation. The handset approval screen and authorized provisioning are not shipped. PC/SC provides transport, not device attestation.
8.8bn
wireless connections
5.8bn
Mobile ecosystem figures cited in the current project README. They do not count AgentSIM-compatible devices.unique mobile subscribers
Source: GSMA Mobile Economy 2026 ↗
03 / IMPLEMENTATION & RESULTSSIM signatures
SIM signatures
and NEAR payments.
The Rust vault was built and executed on agentsim-local, a private NEAR sandbox. Two recorded NEAR AI proposals each led to a transfer of 0.001 test NEAR and a successful settlement callback.
The November 15 capture records physical SIM signing over PC/SC; the November 14 run is the emulator control. Both keep the owner’s P‑256 key separate from the agent and relayer keys.
Rust NEAR vault
The checked-in WASM matches the deployed-code hash in the records. The verified flow covers signed authorization, agent spending, the transfer receipt, callback and revocation.
Built WASM ↗ · Contract source ↗SIM owner signer
The November 15 record includes the applet AID, pinned P‑256 public key, PC/SC transport and verified grant and revocation signatures. jCardSim is the separate reproduction path.
PC/SC host ↗ · Java Card applet ↗Tests and proof checks
All 48 core tests passed in the reviewed revision. Both recorded NEAR AI payments and the local sandbox transfer passed their offline verifiers. The records include four relay-permission denials, overspending rejection and rejection after revocation.
Run the checks →Recorded payment runs
Emulator control
0.001 test NEAR settled
NEAR AI proposal, jCardSim owner signer, Rust vault and successful callback.
5K5Uz1Evew8wNKsYyKQjj7wTDtgnmWzWbzu8U11mnmJzOpen the payment record ↗PC/SC signing capture
0.001 test NEAR settled
NEAR AI proposal, recorded physical SIM owner signer, Rust vault and successful callback.
uZ5xPztcDMj2MYpwgXjzPQxQH2WhuupFA2vUxw1qUgqOpen the payment record ↗Scope: private local NEAR execution with test funds. No public-chain payment or compute delivery. The proof checks signed messages, transactions, recorded receipts and final policy states; it does not independently attest the card or AI provider.
PAYMENT TRACE ILLUSTRATED RECORDED FLOW
01 OWNER GRANT P‑256 SIGNED
02 AGENT REQUEST Ed25519 SIGNED
03 RUST NEAR VAULT LIMITS CHECKED
04 LOCAL TRANSFER CALLBACK SUCCESS
05 OVERSPEND / REVOKED REJECTED
Local NEAR transfers use test funds.
Source: Current README ↗ · Verification and limits ↗ · Watch the recorded demo ↗
Reviewed against revision f81d2e3 on 15 November 2026.
04 / SPENDING DEMOTry the agent’s
Try the agent’s
spending limits.
A research agent needs compute. You approve the supplier and limit its allowance. Try a valid spend, then try breaking the rules. This browser illustration uses pretend credits and performs no signing or payment. The recorded Rust-vault run uses local NEAR test funds.
PER PURCHASE 100 creditsTOTAL 150 creditsSUPPLIER compute.local
▣ permission_control.exe
PERMISSION STATUS● ACTIVE
REMAINING150 CR
> Ready. Choose an action below.
ILLUSTRATION ONLY · NO SIGNING · NO REAL FUNDS
05 / SECURITYSecurity risks
Stolen agent key Untrusted relay Misleading approval Contract & admin risk
Security risks
and limitations.
A signature proves control of a key. It does not prove the device is a SIM, establish legal identity, or guarantee that purchased compute was delivered.
The remaining grant allowance is at risk. The owner’s unrestricted authority stays separate.
A relay can delay or censor requests. Signed bytes prevent it from silently changing the authorization.
The owner needs a trusted view of exact amounts and recipients. A SIM usually has no trusted display.
Contract bugs and deployment keys can defeat application controls. Production needs an explicit upgrade and recovery policy.
The signed grant carries public keys and spending rules; no phone number, IMSI, ICCID, passport or raw identity credential is needed. Public account links and timing can still be sensitive. The operator keeps contract administration authority, and the prototype is not audited for production.
Security and verification limits ↗ · Security policy ↗Run the demo.
Browse the code.
Run these commands from the root of the linked public repository with Node.js 22 or later. The proof verifier reads the recorded evidence; it does not start a chain or send a payment.
C:\AGENTSIM> quick_start.txt
# Software spending example
npm run demo
# Core tests and recorded payment proof
npm ci --prefix tests/near-sandbox
npm test
npm run verify:proof
# Optional: applet tests with JDK 17+
npm run card-sim:setup
npm run card-sim:testExpected: 48 core tests pass, followed by the verifier’s “Verified restricted key setup…” message. Recorded-proof verification needs no card or JDK. Applet setup downloads a pinned, hash-checked jCardSim dependency.
▣ src/Protocol, spending model and AI proposal validation▣ card/Java Card applet and physical PC/SC host▣ contracts/agentsim-vault/Rust vault, Cargo lock and tested WASM▣ tests/near-sandbox/Restricted relayer, sandbox guide and proof verifiers▣ evidence/Signed payment records, receipts and hardware captureImplementation and verification guide ↗
Verify both recorded NEAR AI payments
node tests/near-sandbox/verify-restricted.mjs evidence/near/2026-11-14-live-near-ai.json
node tests/near-sandbox/verify-restricted.mjs evidence/near/2026-11-15-live-near-ai.jsonThe checks reconstruct signed actions, verify owner and agent signatures, compare WASM hashes and assert the recorded settlement and policy results. They verify stored evidence without rerunning the sandbox.
Run a new sandbox payment
Follow the restricted relayer guide ↗ for the dedicated loopback-only sandbox and explicit simulator or PC/SC signer selection. A new run needs the sandbox and signer setup. Live AI mode additionally needs a privately configured NEAR AI credential. This is separate from verifying the supplied records.
Windows dependency setup
If local package links are restricted, install the proof dependencies with:
npm ci --prefix tests/near-sandbox --install-links --bin-links=falseThe core tests and recorded-proof verifiers were checked from a separate copy of the public revision on this platform.
Next steps
- Phone approval: show the exact recipient, amount, budget and expiry on a handset before signing.
- Provisioning: validate supported SIMs and authorized applet installation for a phone deployment.
- Public network: deploy and verify receipts on a public NEAR testnet. The supplied payment records are local sandbox runs.
- Production review: audit the contract, administration policy, recovery and settlement edge cases before putting real funds at risk.
Commands and source paths checked against package.json ↗ at f81d2e3. Applet test guide ↗ · Sandbox setup guide ↗
Reveal all safe squares. Click or press Enter to reveal; right-click or press F to flag. On touch, use Flag mode. Arrow keys move between squares. Your first reveal and its neighbors are safe. Opening a revealed number with enough adjacent flags clears its neighbors.
9 × 9 · 10 mines
You found the secret. Your first move is safe.
Best time: —
Done.Local prototype · 2026