DEV Community: Arun KT

My AI agents kept re-verifying the same work. So I made verification a signed, reusable object

Arun KT — Sat, 04 Jul 2026 07:16:08 +0000

Here's a pattern I kept hitting while running a small fleet of agents:

Agent A needs market data. It finds a paid API, checks that the endpoint is alive, checks the price, makes the call. Twenty minutes later Agent B needs market data. It finds the same API… and checks that the endpoint is alive, checks the price. Same check, same result, new tokens, new latency, new cost. Multiply by every agent, every task, every session — because agents start cold, they re-derive trust from scratch every single time.

Humans solved this ages ago. We don't personally re-audit a CA certificate on every HTTPS request; we verify a signature over someone else's audit. Agents have no equivalent. Every agent is its own tiny, wasteful certificate authority.

Verification as an object, not an act

The fix I landed on: stop treating verification as something each agent does, and start treating it as something an agent can hold — a signed,portable, reusable object.

Concretely: my node continuously probes the paid (x402) agent services my agents actually use — a real HTTP 402 challenge every 10 minutes, recording liveness, latency, and the quoted price. Each probe is published as an attestation:

{
  "payload": {
    "type": "erabi.x402.probe/0.1",
    "slug": "exa-search",
    "ts": "{{ts}}",
    "alive": true,
    "http_status": 402,
    "latency_ms": {{latency}},
    "price_usd": {{price}},
    "window_24h": { "probes": {{probes}}, "uptime_pct": {{uptime}} }
  },
  "sig": "ed25519:…",
  "key": "…"
}

The signature is a detached ed25519 over the canonicalized payload (RFC 8785), verifiable against the node's published key. An agent that wants to know "is this API worth paying?" fetches this, verifies one signature, and moves on. No probe, no burned call, no re-derived trust:

curl https://erabi-production.up.railway.app/index/v1/services/exa-search/attestation

What {{N_days}} days of not re-verifying looks like

The index currently covers 16 real pay-per-call services (search,
browser automation, market data, inference…). Some things the data
already surfaced:

{{finding_1 — e.g. "a service listed as live on the x402 Bazaar has been dead for the entire measurement window"}}
{{finding_2 — e.g. "p50 latencies differ by 8x between services at the same price point"}}
{{finding_3 — e.g. "one service silently changed its quoted price mid-week — the attestation history caught it"}}

Everything is public: the human view at
https://erabi-explorer.vercel.app/services , the agent view at
/index/v1/services (JSON), and each service's attestation endpoint.

The bigger point

"Agents re-verify what other agents already verified" is not an x402
problem — it's everywhere. Test results, security scans, dependency
checks, doc freshness: agent fleets redundantly re-derive the same facts because there's no trusted medium of exchange for verification itself.

Signed attestations are that medium. Verify once, sign it, let everyone (and every agent) reuse it — and make the signer accountable for it.

The reliability index is my first concrete cut at this, built on an open intent-exchange protocol (Apache-2.0, https://github.com/HMAKT99/Erabi )
where identities are Ed25519 keypairs and outcomes are dual-signed on a public ledger. If your agents keep re-checking things other agents already checked, I'd genuinely like to hear what they re-check — that's the next thing the index should carry.

Apple locked hearing assistance inside AirPods. So I built an open-source version for any earbuds.

Arun KT — Sat, 04 Jul 2026 06:16:45 +0000

In 2024, Apple shipped something genuinely great: AirPods Pro can run a clinical-style hearing test and then act as hearing assistance, tuned to your ears. People love it. There's just one catch — it needs an iPhone to set up, recent AirPods to run, and if you're on Android you get nothing.

Meanwhile, the average pair of prescription hearing aids costs about $4,700, and surveys show a $1,500 device is simply out of reach for more than half the people who need one. There are a billion-plus Android phones out there, most of them sitting next to a pair of ordinary earbuds that already contain everything you physically need: a microphone, a DAC, and speakers.

The gap seemed absurd. So I've spent the past weeks building OpenHearing — a free, GPLv3 Android app that does the whole pipeline:

Hearing check — a pure-tone test using the modified Hughson–Westlake staircase (the same adaptive up-down procedure audiologists use), per ear, per frequency. Or skip it and type in the numbers from a real audiogram.
Sound profile — the results are fitted into a per-ear gain curve (half-gain rule for v1; NAL-NL2 is a pluggable strategy for later).
Real-time assist — mic in, per-ear DSP, earbuds out. Quiet speech gets louder. Works with whatever earbuds you already own. No root, no special hardware.

It is very deliberately not a medical device — no diagnosis, no treatment claims, big disclaimer before anything plays a tone. Think of it as the open, inspectable "gateway" tier below real hearing care.

This post is about the three engineering decisions that turned out to matter most.

1. The safety-critical DSP is pure Kotlin — and that's the whole point

An app that amplifies sound directly into human ears has exactly one unforgivable failure mode: being loud when it shouldn't be.

So the entire signal chain is plain Kotlin with zero Android dependencies, hidden behind a tiny I/O interface. AudioRecord/AudioTrack is a dumb shell; everything that can hurt someone is JVM-testable:

input → EQ (your profile) → WDRC compression → feedback guard → master gain → LIMITER → output

The lookahead limiter is always the final stage, and its test suite is the release gate. My favorite test names in the repo:

output never exceeds the ceiling even for loud input
master gain is hard-capped by safety limits (requesting +999 dB gets you the cap, not a lawsuit)
live master gain change never exceeds cap or ceiling
NaN and Infinity in → silence out, never noise

When I later added live gain adjustment (changing volume while the audio thread is running), the change was a single @Volatile field read once per block — because the limiter downstream makes it impossible for a mid-stream change to produce anything dangerous. Safety as architecture, not as code review vigilance.

Every limit lives in one file, SafetyConstants, and nothing else in the codebase is allowed to define its own. 88 JVM tests run on every push without an emulator in sight.

2. Per-ear stereo from a mono microphone

Most hearing loss is asymmetric — your left and right ears usually differ. Phones have one usable mic. The fix is embarrassingly simple and I haven't seen other amplifier apps do it: duplicate the mono capture into interleaved stereo and run a completely independent DSP chain per channel, each with its own fitted gain curve and its own limiter.

class StereoAssistChain(
    private val left: HearingAssistChain,   // fitted to your left ear
    private val right: HearingAssistChain,  // fitted to your right ear
    framesPerBlock: Int,
) : AudioProcessor { /* deinterleave → process → reinterleave, allocation-free */ }

Costs one extra chain of CPU (still trivial at 48 kHz mono-per-ear), buys correct per-ear correction.

3. Privacy you don't have to trust — you can check it

A hearing app is an always-listening microphone app, which is exactly the category people should be suspicious of. Promises are cheap, so OpenHearing makes the OS enforce the promise instead: the manifest declares no INTERNET permission. The app cannot phone home. Not "we don't collect data" — the platform will not let it transmit anything, ever.

aapt dump permissions OpenHearing-0.2.0-alpha01.apk
# RECORD_AUDIO, FOREGROUND_SERVICE(+MICROPHONE), POST_NOTIFICATIONS, MODIFY_AUDIO_SETTINGS
# ...and that's it. No INTERNET.

Any journalist, packager, or paranoid user can verify this in ten seconds. For health-adjacent software I think this should be table stakes.

The weirdest test harness I've written this year

The results screen draws an audiogram-style chart. To screenshot it honestly, I needed a completed hearing test — but the test is interactive and the emulator's mic is silent. Solution: since the Hughson–Westlake staircase is deterministic (start at 40 dB, drop 10 on "heard", rise 5 on "missed"), a shell script can mirror the staircase's internal state and simulate a listener with any hearing profile you want:

if [ $lvl -ge $target ]; then tap "Yes, I heard it"; lvl=$((lvl-10))
else                          tap "No, I didn't";   lvl=$((lvl+5)); fi

Ninety-seven taps later, the app believes it just tested someone with mild high-frequency loss, and the chart in the README shows realistic sloping curves instead of a flat line. Simulated patients as a UI test fixture.

An uncomfortable thing I learned about regulation

While writing the store copy I went through the FDA's hearing-device guidance, and one line stopped me cold: using "a hearing aid fitting formula to program the product output to match the user's hearing profile" is itself evidence that your product is a medical device — by design, regardless of your disclaimers. That's literally the pipeline described above.

The practical consequences for an open-source project are nuanced (enforcement has targeted commercial efficacy claims, and Apple went and got actual FDA clearance for exactly this software category), but it shaped every word of the app's copy: it's a "hearing check," not a diagnosis; a "sound profile," not a prescription; and it never, ever compares itself to hearing aids. If you're building anything health-adjacent, read the regulations before writing your marketing.

Honest status, and what I could use

This is an alpha. The full pipeline is built, 88 unit tests are green, every flow is verified on an emulator — and it has not yet been validated on real hardware, which for a real-time mic-to-earbud path means the two questions that decide everything (Bluetooth latency and feedback behavior) are still open.

If any of this interests you:

📱 Try it on real hardware — signed APK on GitHub, and there's a testers issue for reports. Start with low amplification.
🌍 Translate it — all strings just moved to strings.xml; one file per language.
⭐ Star it if you think open hearing assistance should exist: github.com/HMAKT99/OpenHearing

And if you know the Android audio stack better than I do — the issues tab is open, and I'd genuinely love to be told what I got wrong.

OpenHearing is a sound-amplification and hearing-assistance tool. It is not a medical device and not a substitute for a professional hearing exam. If you have concerns about your hearing, please see an audiologist.

My AI agents kept re-verifying work they'd already verified, so I gave them a memory for trust

Arun KT — Fri, 03 Jul 2026 06:53:56 +0000

Here's a pattern I kept hitting with coding agents (Claude Code, Cursor, doesn't matter which):

Session 1: the agent fixes an auth module. Runs the tests. 42/42 pass. Great.

Session 2, next morning: a different agent (or the same one, fresh context) touches the same area. It doesn't know the tests passed yesterday. So it re-reads the file, re-runs the suite, re-derives the same conclusions — burning a few thousand tokens to rediscover state that already existed.

Multiply that by every file, every session, every agent in a multi-agent setup. Agents have no memory for what's been verified. Everything is Groundhog Day.

The fix: stamps as cached verification

A stamp is ~15 tokens of JSON that travels with the file (YAML frontmatter in markdown, XMP in images, OOXML part in docx, sidecar for everything else):


bash
# Session 1 — agent finishes, stamps what it verified
$ akf stamp auth.py --agent claude-code --evidence "42/42 tests passed"

# Session 2 — any agent, any tool, checks before building on it
$ akf check auth.py
OK trust=0.65 agent=claude-code evidence=test_pass age=1d claims=1

One line, ~20 tokens to read, exit codes for scripting (0 = trust it, 1 = re-verify, 2 = no metadata). The math that made me build this: a stamp costs ~15 tokens; re-verifying costs 15,000.

The parts that turned out to matter

Evidence is weighted, not binary. A bare "AI generated this" stamp scores low no matter how confident the model claims to be — that's by design, it's unverified inference. A test-run receipt lifts it. A human review lifts it more:

$ akf stamp report.md --agent claude-code               # bare
$ akf check report.md
LOW trust=0.21 reason=below_threshold                    # don't trust it

$ akf stamp report.md --evidence "tests pass"            # verified
$ akf check report.md
OK trust=0.65 evidence=test_pass

Staleness is mechanical. If the file changed after it was stamped, the stamp no longer describes the file:

$ echo "quick edit" >> auth.py
$ akf check auth.py
STALE trust=0.65 reason=modified_after_stamp             # exit 1 → re-verify

Memories decay. This one surprised me with how useful it is. Agent memory files get a trust half-life — a fact stamped three months ago about a since-refactored codebase shouldn't rank like one from yesterday:

$ akf stamp memory/project-facts.md --preset memory --agent claude-code
# fresh:        OK trust=0.75 age=2d
# two months:   LOW trust=0.17 age=61d → agent re-verifies instead of trusting a stale memory

Zero-effort mode. Nobody stamps by hand at scale, including me. akf init wires a git post-commit hook and a Claude Code hook so every file an agent writes gets stamped automatically.

What I'll be honest about

- Stamps are claims, not proofs. An agent can lie in a stamp exactly like a developer can lie in a commit message. There's Ed25519 signing for the who, but "were the tests actually run" is an accountability trail, not a cryptographic guarantee.
- Staleness is mtime-based right now, which false-positives on fresh git checkouts. Content-hash comparison is the next fix.
- It's a metadata format, so it has the standard chicken-and-egg problem. The single-player value (your own agents across your own sessions) has to carry it until the network effect exists — that's exactly why check had to be worth running selfishly.

Try it

pip install akf        # or: npm install akf-format
akf init               # hooks for git + Claude Code
akf quickstart         # 60-second demo

There's an MCP server (https://pypi.org/project/mcp-server-akf/) (works with Claude Desktop/Code, Cursor, any MCP client), a GitHub Action (https://github.com/marketplace/actions/akf-certify) that posts trust reports on PRs, and the spec + SDKs on GitHub (https://github.com/HMAKT99/AKF). MIT licensed.

I'd genuinely like to hear where this model breaks — especially from anyone running multi-agent pipelines.

AI agents choose blindly. I built an open trust layer to fix that.

Arun KT — Sat, 13 Jun 2026 16:08:48 +0000

Your AI agent makes choices you never see — which API to call, which dataset to pull, which other agent to hand a subtask to. Right now it makes them blind.

It can't tell a reliable provider from a scam. It can't carry a track record from one task to the next. And it has no way to know whether a recommendation sitting in its context window is organic or something a vendor paid to put there. Humans handle trust with reputation, reviews, brand, gut feel. An agent can do none of that — it's perfectly, silently steerable by whatever text reaches it.

That gap gets worse every month as agents start transacting with each other — MCP, A2A, agent payments. So I built ERABI: an open, cryptographically auditable reputation and discovery layer for AI agents. It's live, Apache-2.0, and an agent can join in one command.

The loop

register   → an Ed25519 identity the agent owns (no account, no signup)
discover   → find providers ranked by reputation, never by payment
intent     → fire a "moment of choice"; get organic + clearly-labeled
             sponsored candidates, each with a signed disclosure
report_outcome / confirm_outcome
           → both sides sign; the outcome lands on a hash-chained ledger
my_reputation / my_earnings
           → a public, recomputable track record

Two invariants do the heavy lifting:

Organic rankings can't be bought. Reputation comes only from dual-signed outcomes — both parties cryptographically confirm what happened. No single-sided reviews, no pay-to-rank.
Every paid placement is labeled and inspectable. Sponsored results carry a signed DisclosureRecord you can fetch and verify in your browser. Paid influence over agents is coming either way; this version is signed, capped, and auditable instead of hidden in a system prompt.

Try it in 60 seconds

It's an MCP server, zero-config:

{ "mcpServers": { "erabi": { "command": "npx", "args": ["-y", "erabi-mcp"] } } }

Call register, and you get back a permalink to your agent's live public page — reputation, earnings, and every dual-signed event on the ledger. Or just watch the network move: https://erabi-explorer.vercel.app

Under the hood

TypeScript monorepo. Ed25519-signed envelopes over RFC 8785 canonical JSON (so signatures are reproducible across languages). A GSP auction where reputation acts as the quality score. A dual-signed, hash-chained outcome ledger with holdback windows and an anomaly engine. MCP server + TypeScript/Python SDKs. ~180 tests. Every reputation score is recomputable from public evidence — the explorer lets you verify a disclosure's signature in-browser.

The honest part — read this before you assume

No real money moves. The economy is ledger-only today: every auction and signature is a real protocol event, but the dollar amounts are units of account, not currency. Ledger balances will never convert to money. Payment rails (x402/AP2) are pluggable and come later; when they do, pre-rail reputation is marked as a separate era. The rules are declared before anyone can game them.
It's early. I'm one person; the network is freshly launched. What's real today is the mechanism — identity, signed disclosures, dual-signed settlement, recomputable reputation — running live and verifiable.

Why I think this matters

Whatever the agent ecosystem becomes, agents will need to answer "can I trust this counterparty?" programmatically, at machine speed, without a human in the loop. That's a trust primitive that doesn't exist yet, and it can't be borrowed from the human web. ERABI is my attempt at it, in the open, where every claim is falsifiable from public data.

It's Apache-2.0. Tear it apart:

Repo: https://github.com/HMAKT99/Erabi
Live network: https://erabi-explorer.vercel.app

Apple wants $199 for a Touch ID keyboard. I shipped a free one in Swift!

Arun KT — Mon, 27 Apr 2026 17:21:06 +0000

I have a Mac mini.

Apple's official path to fingerprint authentication on a Mac mini is buying their $199 Magic Keyboard with Touch ID. The new MacBook Neo charges $100 extra for the variant with the sensor. Mac Studio and Mac Pro never ship with one at all.

The fingerprint sensor I actually use 50 times a day already lives in the phone in my pocket.

So I spent two weekends building TouchBridge — an open-source macOS daemon and PAM module that lets any phone, watch, or browser act as Touch ID for any Mac.

This post is the technical write-up. Repo: github.com/HMAKT99/UnTouchID.

What it actually does

After a one-line install, this just works:

$ sudo rm -rf ~/.cache
TouchBridge: check your phone…
[phone vibrates, you press the sensor, the prompt clears]
$ _

sudo got authenticated by the Secure Enclave on my iPhone over local Bluetooth. No password. No cloud round-trip. No Apple ID. The same flow works for the screensaver unlock and (soon) the App Store / System Settings prompts that go through Authorization Services.

If my phone is dead, out of range, or refuses biometric, the PAM stack falls through to the normal password prompt. You're never locked out.

The architecture

flowchart LR
    A[sudo / loginwindow] --> B[/etc/pam.d]
    B --> C[pam_touchbridge.so]
    C -- Unix socket --> D[touchbridged]
    D <-- BLE: ECDH + AES-256-GCM --> E[TouchBridge app]
    E --> F[Secure Enclave / StrongBox]

Three pieces:

pam_touchbridge.so — a tiny PAM module written in C. Drop a single line into /etc/pam.d/sudo and sudo now consults it before falling through to the password module.
touchbridged — a Swift launchd daemon that owns the BLE connection, the paired-device list, and the audit log. PAM talks to it over a Unix socket.
Companion apps — Swift on iOS / Apple Watch, Kotlin on Android / Wear OS, and a JavaScript fallback for any browser that supports WebAuthn. Each one holds a non-extractable ECDSA P-256 keypair in secure hardware.

The handshake, end to end

When you type sudo:

PAM invokes pam_sm_authenticate in pam_touchbridge.so. The module connects to the daemon's Unix socket and asks: anyone paired and online?
The daemon picks the highest-priority paired device (your iPhone first, watch as fallback) and generates a fresh 32-byte cryptographic nonce.
It encrypts the nonce under a session key derived via ECDH-on-pair (rotated periodically) with AES-256-GCM, then sends it to the device over BLE.
The companion app shows a system biometric prompt — Face ID, Touch ID, fingerprint sensor, whatever the device has.
On approval, the device signs the nonce with its non-extractable ECDSA P-256 key in the Secure Enclave or StrongBox / TEE Keystore. The private key never leaves secure hardware.
The signed nonce comes back over the same encrypted BLE channel. The daemon verifies the signature against the public key it cached during pairing.
If verification passes, the daemon writes a one-line entry to ~/.touchbridge/audit.log and returns PAM_SUCCESS. PAM lets sudo proceed.

End-to-end latency on a recent iPhone over BLE: 80–250 ms. Faster than typing my password.

What `pam_touchbridge.so` actually looks like

PAM_EXTERN int pam_sm_authenticate(pam_handle_t *pamh, int flags,
                                   int argc, const char **argv) {
    const char *user = NULL;
    if (pam_get_user(pamh, &user, NULL) != PAM_SUCCESS || !user)
        return PAM_AUTH_ERR;

    int sock = tb_connect_daemon();
    if (sock < 0)
        return PAM_AUTHINFO_UNAVAIL;   // PAM falls through

    if (tb_send_request(sock, user, getpid(), tb_surface(argv)) < 0) {
        close(sock);
        return PAM_AUTHINFO_UNAVAIL;
    }

    pam_info(pamh, "TouchBridge: check your phone…");

    tb_response_t resp;
    int rc = tb_recv_response(sock, &resp, /*timeout_ms=*/30000);
    close(sock);

    if (rc < 0)                  return PAM_AUTHINFO_UNAVAIL;
    if (resp.status == TB_OK)    return PAM_SUCCESS;
    if (resp.status == TB_DENY)  return PAM_AUTH_ERR;
    return PAM_AUTHINFO_UNAVAIL;
}

Returning PAM_AUTHINFO_UNAVAIL instead of PAM_AUTH_ERR when the daemon isn't reachable tells PAM to keep walking the stack — so if the daemon's down, the password prompt still works. This is what makes it safe to install.

The Swift signing path

func sign(nonce: Data) async throws -> Data {
    let access = SecAccessControlCreateWithFlags(
        nil,
        kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
        [.privateKeyUsage, .biometryCurrentSet],
        nil
    )!

    let key = try SecureEnclave.P256.Signing.PrivateKey(
        accessControl: access
    )

    let sig = try key.signature(for: nonce)
    return sig.derRepresentation
}

biometryCurrentSet hardware-enforces biometric at signing time. If the enrolled fingerprint or face changes, the key invalidates — so a stolen phone can't be re-enrolled to keep using TouchBridge.

What it can't do — being honest

FileVault unlock happens before any user-space daemon is alive. No PAM hook there.

The macOS login screen — same reason: loginwindow boots before launchd user agents.

Apple Pay runs on a dedicated hardware path that only Apple's signed components can touch.

Keychain biometric items — the crypto wall is enforced in the kernel and binds to the local Secure Enclave.

1Password biometric unlock — SIP sandboxes prevent any third-party module from injecting into 1Password's prompt path. (Bitwarden works because its CLI uses the OS PAM stack.)

If you see a tool that claims any of those, be skeptical and read its source.

Try it in 60 seconds (no phone needed)

brew tap HMAKT99/touchbridge
brew install --cask touchbridge

# in one terminal
touchbridged serve --simulator

# in another
sudo echo "this just prompted touchbridge instead of my password"

The cask is signed with a Developer ID and notarized; the formula pins SHA256.

What I'd love help with

Linux PAM port. The protocol is portable; pam_touchbridge.so builds on Linux, but the daemon needs a BlueZ adapter. Friendly first contribution if you've poked at BlueZ.

MDM / fleet pairing. Provisioning the paired-device key over MDM for shared lab Macs. Open RFC.

Hardware test reports. Comment with Mac model + paired device + result so the README's compatibility table grows.

Why I'm posting here

DEV.to has the largest concentration of people who actually understand the difference between PAM, PolicyKit, and Authorization Services. The threat model is in SECURITY.md and I'd love to have it picked apart.

If TouchBridge saves you the price of a Magic Keyboard, a star on the repo is the cheapest way to say thanks.

Repo: github.com/HMAKT99/UnTouchID
License: MIT
Built because I refused to pay $199 for a sensor my phone already has.

Every era creates its file format. AI doesn't have one yet.

Arun KT — Fri, 20 Mar 2026 16:35:40 +0000

Print gave us PDF. Photography gave us JPEG. Music gave us MP3.

The AI era generates more content than any previous era — but has no format to carry
trust, provenance, or verification with that content.

Today I'm releasing AKF — Agent Knowledge Format. Open source. Open spec.

What is it?

AKF is EXIF for AI. ~15 tokens of JSON that embed directly into any file:

Trust scores — how reliable is this content? (0-1)
Source provenance — where did it come from? (SEC filing → analyst → AI summary)
Security classification — who can see it? (public, internal, confidential)
AI attribution — which model generated it?
Compliance metadata — does it meet EU AI Act, SOX, NIST requirements?

Install

pip install akf          # Python
npm install akf-format   # TypeScript

30-Second Demo

# Stamp a file
akf stamp report.md --agent claude --evidence "generated from quarterly data"

# See what's inside
akf inspect report.md

# Check compliance
akf audit report.md --regulation eu_ai_act

# Embed into Word
akf embed report.docx

Zero Touch

eval "$(akf shell-hook)"
# Now every file Claude, ChatGPT, OpenClaw, Aider, Ollama creates is auto-stamped

Why Now

The EU AI Act Article 50 takes effect August 2, 2026. AI-generated content
published for public interest must carry transparency metadata. Penalties: up to
€35M or 7% of global turnover.

Colorado's SB 205 follows on June 30, 2026. DORA is already enforced.

AKF maps directly to these requirements. One command gives you a compliance report.

Integrations

Ships with integrations for LangChain, LlamaIndex, CrewAI, MCP (Model Context
Protocol), VS Code, and GitHub Actions.