DEV Community: Heartlin Machado

The guardrails that matter are code, not prompts

Heartlin Machado — Sun, 30 Aug 2026 19:01:08 +0000

I built an agent that coordinates eldercare for my mother in India, and the interesting part was not the agents. It was the four times I stopped and decided what the system was not allowed to do, and then put those decisions somewhere no prompt can reach.

I created this post for the purposes of entering the All Things Agentic Hackathon (Google Cloud / Devpost).

It's live, and you can check its work without asking me: https://anbu-care-37j4eofpwq-el.a.run.app

The problem, briefly

My parents live in Thoothukudi. I don't. Every NRI I know has the same 3 a.m. fear: something happens, and by the time you hear about it, the decisions that mattered have already been made by whoever was standing there.

One rule fell out of that and shaped everything: any step that needs the son to act is a design failure. He is asleep, nine and a half time zones away. That's the problem, not a detail of it. So every feature got tested with him unreachable.

1. A guardrail you can argue with is not a guardrail

Five agents on Gemini 3.5 Flash and Google's ADK: onboarding, triage, evidence, insurer liaison, comms, all under a coordinator. Underneath them is a deterministic layer no agent can reach past. The model proposes; that layer decides, and it is the only thing that can write.

The demo input for triage is a neighbour calling to say "she says it's probably just gas."

Severity comes back HIGH.

The thing that decides severity is a Python dict. It never reads that sentence as permission, because it never reads that sentence.

The second one is the one I'd defend hardest. Clinical detail can't go over WhatsApp. India's DPDP Act and Meta's healthcare policy make that a legal line. So the gate classifies the content, not the caller's claim about it. A message declared logistics that reads "just logistics: troponin 0.94 ng/mL" is blocked anyway.

Then the demo does something that took me embarrassingly long to think of: it bypasses the agent entirely and calls the send function directly.

Still blocked.

That second half is the whole claim. An agent that is merely told not to leak a lab value is not a control. If your only enforcement is in the system prompt, you have a strong suggestion, and you will find out which it was on the day it matters.

2. Public where it proves, private where it reveals

This is the design decision I'm most pleased with, and it came from a question I couldn't answer cleanly at first.

If clinical data can't go over WhatsApp because it "lives somewhere protected", what exactly is protecting it?

If the answer had been "a URL nobody guesses", the whole argument would have been hollow, and I'd have published the exact data I claimed to guard.

So the API has two access models, both enforced server-side:

curl -s -o /dev/null -w '%{http_code}\n' $URL/api/parents/{id}      # 401
curl -s -o /dev/null -w '%{http_code}\n' $URL/api/cases/{id}/verify # 200

Every action appends an Ed25519-signed receipt whose hash covers the previous one. Verification proves the record wasn't altered without revealing what it says. It returns hashes, a boolean and a failure mode. That's exactly why it can be open to everyone, and why it has to be: a receipt chain only means something if you can check it without my permission.

You can watch it catch an edit. Rewrite a stored receipt straight in Firestore, leaving the hash and signature untouched, exactly as a silent after-the-fact edit would:

{ "field": "payload.severity", "before": "HIGH", "after": "LOW" }

Then ask the public endpoint:

{ "verified": false, "receipt_count": 2, "broken_at_seq": 1,
  "reason": "payload does not hash to the recorded hash: content was altered" }

It names the receipt. Not "something is wrong", but sequence one, content altered.

One caveat I put in my own demo script, because leaving it out would be a lie by omission: an empty chain is a valid chain. A deleted case answers verified: true with receipt_count: 0. verified on its own proves the absence of tampering in nothing at all. The count is what ties the proof to the story.

3. The bug that would have discredited everything

On one run, the agent told me:

"I have successfully read your mother's lab report and ingested it into her health record."

Documents actually stored: zero.

For a system whose entire pitch is a verifiable record, an agent asserting a write that never happened is fatal. Not embarrassing. Fatal. Everything else I had built was an argument that you could trust the record, and here was the record's own narrator making things up.

Prompt wording was never going to fix that. So the demo now prints the stored count read back from the service, right next to what the agent claimed:

GROUND TRUTH. Documents actually stored for this parent: 2
reported status 'ingested' vs stored count 2: consistent

If they ever disagree, it says CONTRADICTED on screen.

The general lesson I took: anywhere an agent reports an outcome, report the outcome from the system that would know, side by side, and make the disagreement loud.

4. The bug that taught me what my tests were worth

This one is more useful, because it looks like nothing.

The document reader emits the kind lab_report. The record stores it as blood_report. I added a guard (an arriving lab report should close the outstanding diagnostic order it belongs to) and compared against the stored word.

Nothing raises. No error appears anywhere. No log line. The guard simply never matches, and the loop silently closes nothing, forever.

Eighteen unit tests passed. They all called the function directly and handed it the right word themselves.

The fix wasn't the one-word change. It was writing two tests that go through the real ingestion path end to end, and confirming they fail first, with the message "the report went in and closed nothing; the hook and the reader disagree about what a lab report is called".

A test that cannot fail for the reason you care about is not covering that reason. I now break every new guard on purpose and check that something goes red before I let the change stand.

5. The refusal I'm proudest of

That same lab-report loop has a case where it does nothing, deliberately.

If two tests are outstanding on an admission and one report arrives, it closes neither.

Attributing that report to one of the two orders means reading it to work out which test it is, and that is a model deciding which clinical order was carried out. So it stops, writes a receipt saying exactly why, and leaves a person an accurate record and an obvious next step.

The same instinct shows up in the memory. The system remembers one class of fact between admissions: whether she answers by voice note or by typing. It's in a Vertex AI Agent Engine Memory Bank, and there is no free-text path into that store. Each kind of memory has its own function composing its own sentence from a value validated first. A caller can't put a symptom in it because a caller can't put a sentence in it. Recall is an exact scope lookup, never a similarity search, so an unrelated memory can't surface because it read as close enough.

That's the whole philosophy in one small module: decide what may be true, in code, and the interesting failures become impossible rather than unlikely.

What's actually running

Gemini 3.5 Flash and the Agent Development Kit on Cloud Run, Firestore for state and the receipt ledger, Pub/Sub for multi-day case events, Cloud Storage for photographs, Vertex AI Agent Engine for Memory Bank, Google Places to verify that every hospital is a real place.

Cloud Scheduler matters more than it sounds. Cloud Run holds no timer, so the regulatory clocks are real scheduler jobs ticking every minute, which is the difference between an agent and a demo. It keeps running when the browser is closed and nobody is watching.

1,203 tests, none of which need cloud access or a model to run.

What isn't real, stated plainly

Because a post that spent 2,000 words on honesty should end with some:

The insurer's adjudicator is simulated. Deterministic local rules, labelled as such on every receipt and every API response, not just here.
Payments run on a real provider in test mode. Real Razorpay link, real API call, real webhook, test money. No mode moves real money.
WhatsApp is real (Twilio, actual handsets) but freeform-only inside the 24-hour window, because there are no approved templates.
Hospital data is half real. Locations carry a Places place_id and a verification date. Capability and insurer empanelment are a dated seed and say so on every triage call.
All demo data is synthetic, and the clinical views say so on screen, because a screenshot outlives a demo.

It also doesn't watch anyone. No sensors, no passive monitoring. An episode begins because a signal arrives, and the receipt says received from an external channel, not detected by Anbu Care. The tests reject the words "detect", "notice", "sense" and "monitor" in that path unless they follow a negation.

Try to break it

URL=https://anbu-care-37j4eofpwq-el.a.run.app
curl -s $URL/api/cases/case-da1c2cb6db/verify | jq   # verified: true, 8 receipts
curl -s $URL/api/cases/case-a7cf9fa613/verify | jq   # verified: false, broken_at_seq: 1

Dashboard: /app. Health, including which components are simulated: /api/healthz.

I created this article for the purposes of entering the All Things Agentic Hackathon. If you take one thing from it: put your guarantees in code, then try to break them from outside the agent. If it still holds, you have a control. If it doesn't, you have a prompt.

Anbu (அன்பு) is Tamil for love.

AllThingsAgenticHackathon

Pre-publish checklist

[ ] Published public, not unlisted.
[ ] The line "created this post for the purposes of entering the All Things Agentic Hackathon" is present near the top.
[ ] Max 4 tags.
[ ] make test, confirm 1,203 and update if not.
[ ] curl -s $URL/api/healthz, confirm the "what isn't real" list still matches tpa_mode, whatsapp_mode, memory_bank.
[ ] Both canonical case ids still verify as stated.
[ ] URL pasted into the Devpost "link to a piece of content" field.

Four bugs in one paragraph: what I learned building an autonomous loop that chases people who don't answer

Heartlin Machado — Sun, 30 Aug 2026 18:11:25 +0000

I built CrisisMesh for the All Things Agentic Hackathon, and I created this post for the purposes of entering that hackathon. #AllThingsAgenticHackathon

CrisisMesh is a seven-agent fleet on Google ADK and Gemini 3.5 Flash that coordinates a school's response after a human reports an emergency. It doesn't detect anything. Somebody sends the message they'd already have sent: a Slack command, a WhatsApp text. The fleet takes it from there.

The interesting part wasn't getting agents to talk to each other. It was everything that happened once the system started making claims.

The loop is the product

The feature I'd defend is the one nobody watches. A declared incident starts a scheduler. Every tick it looks at whoever hasn't checked in, pings them, re-pings them, and at a configured cap stops pinging and hands that person to their floor warden by name, on the warden's own channel.

Four bugs lived in that one paragraph. Every one of them passed its tests.

It sent the escalation to the person it couldn't find. "Mrs. Rodriguez has not answered, please locate her" went to Mrs. Rodriguez. The message was correct. The recipient was the one person it couldn't help.

It never stopped. Once escalated, a person stayed actionable, so on a timer the same warden was paged about the same person every 25 seconds, forever. I fixed it with a terminal state, and then the same bug came back, because the guard went into the function the tests called while the running loop called a different one. Green the entire time.

# tests called this one
def should_act(incident_id, person_id, tick):
    if get_state(...).status in TERMINAL_FOR_THE_LOOP:   # the guard
        return False
    ...

# the loop called this one
def safe_should_act(incident_id, person_id, tick):
    if state.status == ACCOUNTED:      # ACCOUNTED only. not ESCALATED.
        return False

It counted people it couldn't reach as reachable. Any non-empty Slack id counted, including the roster's placeholders like U_PRINCIPAL, so the loop reported 34 of 34 reachable and chased thirty people down channels that addressed nobody. It now verifies ids against the workspace and reports 4 of 34.

That number is worse and it's true. The difference matters: unreachable is a fact a commander acts on, not a gap to paper over.

The tick guard was process-local. Harmless at one instance. At four, every container runs its own tick N and one silent teacher gets pinged four times. Ticks are now claimed with a create-if-absent lease in Firestore.

Every real bug was in a seam

Not one of these was a bad function. They were all connections: a guard in the wrong function, a check-in written to one ledger and not the other, a critic that ran on one path and not another.

The sharpest example: a teacher asked "what's the fastest route out of east wing" during an active shooter, and the system answered with corridor directions. The movement policy that exists to prevent exactly that ran inside the fan-out. A query answer is a transport reply, and it never passed through.

Unit tests for the policy: green. Unit tests for the query desk: green.

So the tests changed shape. They stopped asserting that functions return values and started asserting things about the world:

def test_the_escalation_does_not_go_to_the_person_being_looked_for(self):
def test_no_route_through_a_reported_sighting_is_offered(self):
def test_a_checkin_recorded_by_one_instance_is_counted_by_another(self):
def test_an_unreadable_ledger_says_so_and_counts_everyone_missing(self):

Those fail for real reasons.

Managed services find bugs that mocks cannot

Moving the Memory Bank onto Vertex AI Agent Engine took an afternoon of writing and ten minutes of reality demolishing it.

Vertex persists fact and scope and silently drops display_name and description, which is where I'd put the structured record, so retrieval returned memories it couldn't read. And scope matching is exact on the whole map, not a subset, so putting metadata in scope makes a lesson findable only by someone who already knows its id.

Neither is in the docs. Both took one live call. I made the test double lossy in the same way afterwards, so the double can no longer pass while the service fails.

Model Armor was worse, and the failure was mine. The pillar was marked managed while the deployed service ran the regex fallback, so none of it had ever executed in production. Three defects were sitting there:

The client was built against the global endpoint. Templates are regional, so every scan returned "template not found", which fell into the error path below.
Both error paths returned blocked: False, under a comment claiming they failed closed for ambiguous cases.
The block signal was read as "MATCH_FOUND" in str(state). str() of that enum is "2". Model Armor had never blocked anything.

Then turning it on correctly broke the product. The RAI dangerous classifier refused "Smoke near the science lab, floor 2" while letting "active shooter reported in the east wing" through. A system that receives reports of danger can't treat danger as grounds for refusal. That filter is off now, in the template and in code, so a template edit can't quietly stop it accepting emergencies.

What it refuses to say

The parts I'm most confident in are the refusals.

It won't name a route clear when it couldn't read the sighting log; the brief says EGRESS ASSESSMENT WITHHELD. It won't report zero unaccounted because the ledger was unreadable; the roster is the denominator, so a lost record counts as missing. It won't publish an assembly point during a lockdown. It won't send a tactical brief over WhatsApp, because that document names where people with mobility limitations are.

And the numbers say which scale they're on. Managed semantic recall returns a vector distance; the local store returns Jaccard tag overlap. A correct top hit reads 0.166 on one and 0.75 on the other, so every result carries the basis that produced it. Presenting one as the other is the same class of claim as 34 of 34.

Where it's weak

Slack reaction check-ins are still process-local, so they under-report and never over-report. The audit bundle reflects the instance serving the request. And SMS isn't a live channel at all: the route, signature verification and keyword mapping are written and tested, but the A2P 10DLC campaign is unapproved, so zero SMS have been sent or received. It's in the README as upcoming rather than counted as a transport.

All three are in the README under Known Limits with their failure mode named. A README that claims more than the runtime does is the same failure the runtime spends its effort avoiding.

Stack

Google ADK · Gemini 3.5 Flash and 2.5 Flash Lite on Vertex AI · Cloud Run · Firestore · Pub/Sub · Model Armor · Vertex AI Agent Engine Memory Bank · Slack Events API · Twilio WhatsApp. 1,299 tests, none of which need GCP credentials.

Repo: https://github.com/4KInc/CrisisMesh
Live: https://crisismesh-1031148889398.us-central1.run.app

Add Pre-Signature Policy Enforcement to AWS KMS Signing in 10 Minutes

Heartlin Machado — Fri, 27 Mar 2026 17:17:41 +0000

If you're using AWS KMS for blockchain transaction signing, every call to kms:Sign is an unrestricted operation. Any process with the right IAM permissions can sign any transaction to any address for any amount.

This tutorial shows you how to add a policy evaluation layer in front of your KMS signing operations — so every transaction is checked against rules (value limits, address allowlists, velocity caps) before the signature is produced. If the policy says no, the key never signs.

We'll use Gate, an open-source pre-signature enforcement SDK, in SHADOW mode — meaning it evaluates every transaction and logs the decision, but never blocks. Zero risk to your existing operations.

What you'll build

Your App → Gate SDK (evaluate) → Policy Decision → KMS Sign (only if ALLOW)
                                      ↓
                            Signed receipt (HMAC + RSA)
                            Decision log (DynamoDB)

Every signing request gets:

A policy evaluation (denylist, value threshold, velocity, signer authorization)
A cryptographically signed receipt (verifiable by third parties)
A decision log entry (queryable audit trail)

In SHADOW mode, the SDK never blocks — it returns ALLOW for everything but logs WOULD_BLOCK when policy violations are detected. You see what Gate would catch without any production risk.

Prerequisites

Node.js 18+
An AWS account with a KMS asymmetric signing key (secp256k1 or ECDSA P-256)
A Gate tenant (free trial at blockintelai.com)

Step 1: Install

npm install blockintel-gate-sdk @aws-sdk/client-kms uuid

Step 2: Initialize the Gate client

import { createGateClient } from 'blockintel-gate-sdk';

const gate = createGateClient({
  apiUrl: 'https://gate-hotpath.blockintelai.com',
  tenantId: process.env.GATE_TENANT_ID,
  apiKey: process.env.GATE_API_KEY,
  environment: 'production',
  signerId: 'treasury-signer-1',
  onConnectionFailure: 'FAIL_OPEN',  // SHADOW mode default — never block
});

FAIL_OPEN means that if Gate itself is unreachable, your signing operations continue uninterrupted. Gate is never a Tier-0 dependency unless you want it to be.

Step 3: Wrap your signing function

Here's a typical KMS signing function without Gate:

import { KMSClient, SignCommand } from '@aws-sdk/client-kms';
import { v4 as uuidv4 } from 'uuid';

const kms = new KMSClient({ region: 'us-east-1' });

// ❌ Before: unrestricted signing
async function signTransaction(txHash: Buffer, keyId: string) {
  const result = await kms.send(new SignCommand({
    KeyId: keyId,
    Message: txHash,
    MessageType: 'DIGEST',
    SigningAlgorithm: 'ECDSA_SHA_256',
  }));
  return result.Signature;
}

Here's the same function with Gate evaluation:

// ✅ After: every signing operation evaluated against policy
async function signTransactionWithGate(
  txHash: Buffer,
  keyId: string,
  toAddress: string,
  valueWei: string,
  valueUsd: number,
) {
  // Step 1: Ask Gate if this transaction should proceed
  const decision = await gate.evaluate({
    requestId: uuidv4(),
    txIntent: {
      toAddress,
      value: valueWei,
      valueUsd,
      network: 'ethereum',
      networkFamily: 'EVM',
      chainId: 1,
      from: '0xYourWalletAddress',
    },
    signingContext: {
      signerId: 'treasury-signer-1',
      actorPrincipal: 'ops@yourcompany.com',
    },
  });

  // Step 2: In SHADOW mode, decision is always ALLOW
  // But decision.reasonCodes tells you what WOULD have been blocked
  if (decision.reasonCodes?.length > 0) {
    console.warn(`[GATE] Would block: ${decision.reasonCodes.join(', ')}`);
  }

  // Step 3: Receipt is signed and logged regardless
  console.log(`[GATE] Receipt: ${decision.receiptSignature}`);

  // Step 4: Sign with KMS (always proceeds in SHADOW mode)
  const result = await kms.send(new SignCommand({
    KeyId: keyId,
    Message: txHash,
    MessageType: 'DIGEST',
    SigningAlgorithm: 'ECDSA_SHA_256',
  }));

  return {
    signature: result.Signature,
    gateDecision: decision.decision,
    gateReceipt: decision.receiptSignature,
    wouldBlock: decision.reasonCodes,
  };
}

That's it. Every KMS signing operation now produces a policy decision and a signed receipt. In SHADOW mode, nothing is blocked — you're collecting data.

Step 4: Set up policies

Log into the Gate Console and create policies for your tenant. Common starting rules:

Rule	What it does	Example
Denylist	Blocks transactions to known malicious addresses	OFAC SDN list, known exploit contracts
Destination Allowlist	Only allow transfers to approved addresses	Your hot wallets, exchange deposit addresses
Value Threshold	Block transactions above a USD amount	Max $100,000 per transaction
Velocity Limit	Cap transaction volume in a rolling window	Max $500,000 per 10 minutes
Signer Allowlist	Only approved signing identities can request	`treasury-signer-1`, `ops-signer-2`
New Destination	Flag first-time destination addresses	Log or require step-up approval

After creating rules, compile and publish a policy snapshot. The hot path loads the snapshot and evaluates every gate.evaluate() call against it.

Step 5: Verify it works

// Test: normal transaction (should be ALLOW)
const normalTx = await signTransactionWithGate(
  Buffer.from('abc123', 'hex'),
  'arn:aws:kms:us-east-1:123456789:key/your-key-id',
  '0x742d35Cc6634c0532925a3b844Bc9e7595916DA2',  // Known good address
  '1000000000000000000',  // 1 ETH
  2500,  // $2,500
);
console.log(normalTx.gateDecision);   // "ALLOW"
console.log(normalTx.wouldBlock);     // []

// Test: denylisted address (should be WOULD_BLOCK in SHADOW)
const blockedTx = await signTransactionWithGate(
  Buffer.from('def456', 'hex'),
  'arn:aws:kms:us-east-1:123456789:key/your-key-id',
  '0xba5ed7f51d2a0cfeef2ca243af1188bad4f1cb03',  // Known exploit address
  '50000000000000000000',  // 50 ETH
  125000,  // $125,000
);
console.log(blockedTx.gateDecision);  // "ALLOW" (SHADOW mode override)
console.log(blockedTx.wouldBlock);    // ["DENYLIST"]

In SHADOW mode, both transactions succeed. But the second one logs WOULD_BLOCK with reason DENYLIST. You now have visibility into what Gate would catch — without changing your production behavior.

What you get after 14 days

Let Gate run in SHADOW mode for two weeks. You'll accumulate:

A decision log — every signing operation evaluated, with policy verdicts
A block rate — what percentage of transactions would have been blocked by your policy
A max-loss estimate — if a signing key were compromised, how much could an attacker drain in 24 hours under your current policy (this is the Bot Blast Radius metric)
Signed receipts — cryptographically signed records of every decision, verifiable by third parties (useful for insurance, compliance, audits)

This data is visible in the Gate Console dashboard. If you're working with a custody insurance carrier, the BBR report and evidence bundle are exactly what underwriters need to evaluate your signing controls.

Going from SHADOW to enforcement

When you're ready to enforce (not just monitor), the transition is one config change:

const gate = createGateClient({
  // ... same config
  onConnectionFailure: 'FAIL_CLOSED',  // Now: block on policy violation
});

At SOFT_ENFORCE, the SDK throws BlockIntelBlockedError when a policy violation is detected. Your code catches it and decides what to do.

At HARD_KMS_GATEWAY, Gate removes kms:Sign from your application's IAM role entirely. The only path to a signature is through Gate's policy evaluation. Even a fully compromised application cannot sign a transaction that violates policy — because the application no longer has the IAM permission to call KMS directly.

That's the enforcement ladder: SHADOW (monitor) → SOFT_ENFORCE (SDK blocks) → HARD_KMS_GATEWAY (IAM blocks). Each step is reversible. Each step produces more evidence.

Python

The same flow works with the Python SDK:

pip install gate-sdk boto3

from gate_sdk import GateClient

gate = GateClient(
    base_url="https://gate-hotpath.blockintelai.com",
    tenant_id=os.environ["GATE_TENANT_ID"],
    api_key=os.environ["GATE_API_KEY"],
    environment="production",
    signer_id="treasury-signer-1",
)

decision = gate.evaluate(
    request_id=str(uuid4()),
    to_address="0x742d35Cc6634c0532925a3b844Bc9e7595916DA2",
    value="1000000000000000000",
    value_usd=2500,
    network="ethereum",
    network_family="EVM",
    chain_id=1,
    from_address="0xYourWalletAddress",
    signer_id="treasury-signer-1",
    actor_principal="ops@yourcompany.com",
)

print(f"Decision: {decision.decision}")
print(f"Receipt: {decision.receipt_signature}")

Note: the Python SDK's default timeout is 50ms (vs 15s in TypeScript) — it's optimized for hot-path latency. If you see circuit breaker trips, check your control plane p99 before increasing the timeout.