DEV Community: LayerCall

Who is responsible when an agent does something on your behalf?

Hira — Wed, 26 Aug 2026 14:00:00 +0000

This one is less technical and I think it matters more than the technical ones.

A user instructs an agent. The agent takes an action on a third-party service. The action turns out to be wrong — the wrong plan bought, the wrong data shared, terms accepted that the person would not have accepted.

Who is accountable? The user who gave a vague instruction? The agent operator whose model interpreted it? The service that accepted the request without checking there was a human behind it?

Right now the honest answer is that nobody has decided, and every party has an incentive to point at the other two.

What makes it more than a philosophical question is that it determines what we should be building. If the service is accountable, we need to be able to prove there was human intent behind a request — which is an engineering problem with real answers emerging. If the operator is accountable, they need auditable records of what was asked and what was done. If the user is accountable, then agents need to be far more explicit about what they are about to do than most currently are.

I lean towards: the operator carries it, because they are the only party who can see both the instruction and the action. But that puts enormous weight on agent operators, and I am not sure they have signed up for it.

Where do you think this lands? And is anyone building as though they already know?

What does "verified" actually mean in your stack?

Hira — Mon, 24 Aug 2026 14:00:00 +0000

I have started thinking the most dangerous word in a codebase is a field called verified.

Because it usually means one of two completely different things, and they get stored in the same column.

Sometimes it means proven: a signature checked out, a cryptographic assertion held. That is arithmetic. It is either true or the maths failed.

Sometimes it means inferred: heuristics agreed, the fingerprint looked normal, the score was low enough. That is judgement, and judgement a capable adversary patches in an afternoon.

Once those share a field, somebody downstream branches on it — and they are now treating a guess exactly like a certainty. That is how a system starts refusing real customers on a hunch while its own code reads as though it knew something.

What I do now is keep a single boolean that means only "this was settled cryptographically", and never let anything inferred touch it. Everything else lives in a score or a set of signals, where it is obviously an opinion. It costs an extra field and removes a whole category of mistake.

The same applies to is_bot, is_fraud, trusted — any name that sounds like a fact but holds an estimate.

Does anyone have a naming convention that actually holds up over a few years and a few engineers? _proven versus _likely suffixes feel clumsy but at least they are honest.

When did you last check who is actually calling your API?

Hira — Sat, 22 Aug 2026 14:00:00 +0000

Here is a question worth being uncomfortable about: if one of your API keys leaked right now, how would you find out?

Not "how would you rotate it" — that part is easy. How would you notice?

A stolen key does not look stolen. It authenticates correctly, because it is a valid key. It hits the same endpoints, because whoever took it wants the same functionality you built. It bills to the same account. Every row it writes to your usage log looks exactly like a row you wrote.

The only thing that differs is where it comes from. Someone else's server is not the one you deploy from.

Which means if you are not recording the caller's address alongside the usage, there is no evidence a theft ever happened. You find out from the bill, weeks later, and even then you cannot tell which calls were yours.

What makes this a nasty class of problem is that the fix is trivial and almost nobody does it until after the incident. One column. The hard part is the alerting: most legitimate integrations call from several addresses — a few app instances, a laptop, CI — so "more than one address" fires constantly and gets ignored, and then it is not there on the day it matters.

The heuristic I settled on: never flag the busiest source, and only flag a minority share once there is enough traffic for a share to mean anything. Quiet enough to still be believed.

What do you do — per-key IP allowlists, anomaly alerting, or nothing until something looks weird on the invoice?

The signal everyone blocks on is the one that is usually wrong

Hira — Thu, 20 Aug 2026 14:00:00 +0000

Datacenter IP is the first thing most teams block on, and on its own it is a terrible reason to refuse anyone.

It tells you the request did not come from a phone or home broadband — it came from a rented server. That is genuinely useful information. It is just not a verdict, because the population it catches is mostly VPN users, and VPN users are disproportionately the security-conscious, privacy-aware, technically-literate people you would quite like as customers.

Same for disposable email domains: often it is someone protecting their inbox from a product they have not decided to trust yet. Same for a freshly registered domain: sometimes it is a founder who launched last week and is signing up for tools.

Each of those in isolation is a reason to look closer. None is a reason to refuse.

Where it becomes unambiguous is combination. A disposable address, from a datacenter address, on a domain registered yesterday, as the fortieth signup from that subnet this hour — nobody is arguing that is a customer having a bad day.

The general shape: single strong signals are how you refuse real people who never tell you. Combinations are how you catch the thing you were actually looking for. And blocking on any one field is almost always a decision someone made because it was the easiest thing to query, not because it was the most accurate.

Which single signal does your stack block on that you suspect you should not?

A risk score is not a probability. Does your code know that?

Hira — Tue, 18 Aug 2026 14:00:00 +0000

A short one, but I keep seeing it cause real damage.

A fraud or risk score of 80 means "riskier than 40". It does not mean an 80% chance of fraud. It is an ordering, not a probability — and most scoring systems, ours included, do not claim otherwise anywhere in their docs.

Then someone builds arithmetic on top of it. Expected loss as score/100 × transaction_value. Averaging scores across a session. Multiplying two scores together for a combined risk. Every one of those operations is meaningful on probabilities and meaningless on an ordering, and none of them throw an error. You get a number. The number is confident. It means nothing.

The tell is any expression where you divide a score by 100, or where two scores get combined by anything other than max().

What makes it hard to catch is that the resulting system often behaves approximately right, because the ordering survives even when the arithmetic is nonsense. It fails at the edges, quietly, in the direction nobody is measuring.

If you want a real probability you have to calibrate against outcomes you have actually observed — which means feeding results back and measuring, not deriving it from the score.

Has anyone found a good way to stop this at review time? A lint rule feels too crude, but "remember scores are ordinal" in a doc nobody reads is clearly not working either.

Your API's redirect is eating the Authorization header

Hira — Mon, 17 Aug 2026 02:03:06 +0000

We shipped a bug last week where a valid API key arrived at our server as no key at all. The cause is a line in the fetch spec that most of us have read and none of us remember, and it will bite anyone whose API answers on both example.com and www.example.com.

Here is the whole thing, as it was before we fixed it. Our apex no longer redirects, so running this against us today no longer reproduces it — swap in any API of your own that answers on both hosts.

# apex, which 308'd to www
curl -s "https://example.com/v1/score/ip?ip=8.8.8.8" \
  -H "Authorization: Bearer $KEY" -L
# {"error":"Missing API key..."}

# www directly
curl -s "https://www.example.com/v1/score/ip?ip=8.8.8.8" \
  -H "Authorization: Bearer $KEY"
# {"error":"Invalid or revoked API key."}

The second error is the good one. "Invalid or revoked" means the key arrived and was judged. "Missing" means it never got there — and the only difference between the two calls is a redirect from the apex domain to www.

Why: when a redirect changes host, clients strip Authorization. It is in the fetch spec, it is in curl since 7.58, and it is in every browser. It is a good rule — following a redirect to an attacker-controlled host with your bearer token attached is how tokens leak — and it is invisible until it isn't.

What makes it nasty is the shape of the failure. X-Api-Key is a custom header and survives the hop. So our SDKs, which send X-Api-Key, were fine. Only Authorization: Bearer broke — which meant the people hitting it were the ones reading the docs and writing curl by hand, and the error they got said "missing API key" while they were looking straight at the key they had just pasted.

And it came back. We fixed this in July. It regressed in August because the redirect is a setting in a hosting dashboard, not a line in the repo — so no code review could catch it and no test was watching. That is the part worth taking away: a bug whose cause lives outside your codebase will come back, and the only defence is a test that asserts the behaviour from outside.

✗ the apex host does not redirect /v1 (a redirect strips the key)
    apex returned 308 -> https://www.example.com/v1/... ;
    a keyed request following this arrives unauthenticated

The fix, if you have this: serve your API on whichever host was asked for, and redirect only the pages. Machine surfaces — your API, your JS snippet, your OpenAPI file, .well-known — should not redirect at all. Canonicalise the HTML and leave the machines alone.

That is what we did, and the assertion above is now green. A page on the apex still 308s to www, so there is still one canonical URL in the index; /v1 and the other machine paths answer on whichever host you ask.

If you would rather not change your hosting: at minimum, say so in your 401. Ours now reads "check you called https://www.layercall.com" — because the developer hitting this has no way to guess, and the header they lost is not visible from where they are standing.

We treat a missing signature as suspicious. Should we?

Hira — Sun, 16 Aug 2026 14:00:00 +0000

As request-signing standards land for automated traffic, a question is going to come up fast: what do you do with everything that is not signed?

The tempting answer is to treat unsigned as untrusted, then gradually squeeze it. It feels like a migration path.

I think it is a mistake, and the reason is a distinction worth naming: absence of a claim is not a false claim. An unsigned request has told you nothing. It has not lied. Most traffic on the internet is unsigned and most of it is completely fine — including, for a long while yet, most legitimate agents whose operators have not adopted anything.

Where it gets genuinely difficult is that this is exactly how good standards die. Nobody adopts because there is no benefit; there is no benefit because nobody adopts. Signing only pays off if verifiers do something meaningfully better for signed traffic than unsigned.

So the honest position seems to be: signed and verified earns you a faster path, higher limits, fewer challenges. Unsigned earns you the normal path, not a penalty. Reward the claim, do not punish its absence.

But I hold that loosely, because "reward, never penalise" might just be too slow to bootstrap anything.

Where do you land? Is there a version of penalising unsigned traffic that is not just breaking the web for everyone who has not caught up?

Your false positives never complain. So how do you find them?

Hira — Fri, 14 Aug 2026 14:00:00 +0000

Any system that blocks people has two failure modes, and only one of them is loud.

Fraud that gets through arrives as a chargeback, a support ticket, a cleanup job. It has a cost you can put in a spreadsheet and a person whose week it ruined. It gets reviewed.

A real customer wrongly refused closes the tab. They do not file a bug. They do not email support. Nothing in your dashboard records that they existed, and the metric that would have caught it is the absence of an event.

The structural consequence is what bothers me: if the only feedback reaching you is the loud kind, then every review concludes the rules are too loose, and they tighten. Forever. Not because anyone decided to be aggressive, but because one side of the ledger is invisible and the other is not.

Things I have seen actually work against it:

Count challenges issued against challenges passed. People passing your step-up at a high rate means the band is doing its job; people abandoning it means it is set too wide.
Run in log-only mode for a period and look at the score distribution before acting on it, so the cutoff comes from your traffic rather than someone else's.
Sample blocked traffic and actually look at it, on a schedule, as a job someone owns.

None of these are clever. They just require someone to go looking for the thing that does not announce itself.

What do you use? I am genuinely collecting approaches here.

Should a customer's AI assistant be allowed to sign up for them?

Hira — Wed, 12 Aug 2026 14:00:00 +0000

Genuine question, and I do not think there is consensus yet.

A user tells their assistant: find me a tool that does X, make an account, start the trial. The agent does exactly that. It fills in the form with the user's real details, receives the verification email in the user's real mailbox, clicks the link.

Is that a signup you want?

The case for yes: it is a real person who genuinely wants your product, and the only difference from a normal signup is which fingers typed. Refusing it means refusing a customer for the crime of using a tool. That reflex gets more expensive every month, and it is invisible in your metrics — refused signups do not complain.

The case for no: your terms probably say a human must accept them. Nobody read your onboarding. Nobody saw the pricing page. The person may not even know which product got chosen. And whatever the agent agreed to on their behalf, you may struggle to enforce.

My own position is that the signup is fine and the terms acceptance is the actual unsolved bit — but I hold it loosely.

There is also a version that is straightforwardly not fine: the same assistant, told to open fifty trial accounts. It will honestly declare itself user-initiated every single time, because it is telling the truth. Identity does not catch that; only volume does.

What are you doing in your product right now — allowing, blocking, or has it not come up yet?

My health check passed for weeks while reading nothing

Hira — Mon, 10 Aug 2026 14:45:44 +0000

One of my monitoring checks reported "all clear" on every run for weeks. It was reading an empty list and calling that good news.

Here's the whole bug:

// The alarm: is any real customer on our email provider's suppression list?
const res = await fetch(
  "https://api.provider.com/v3/suppressions?limit=500",
  { headers: { "api-key": key } },
);
const body = await res.json();
const blocked = body.contacts ?? [];        // <-- the bug lives here

The provider caps limit at 100. Ask for 500 and you get HTTP 400 with {"code":"out_of_range"}. There's no contacts key on an error body, so ?? [] turned a failed request into an empty list, and the step went off and reported:

ok | suppression list holds no real customer — 0 blocked

Zero blocked. Beautifully green. It had never successfully read the list in its life.

The thing that gets me is that it would have gone green in exactly the same way if every single customer had been suppressed. The output had nothing to do with the thing it was watching, and no way to say so.

That's worse than having no check at all, because the green tick is doing active harm — it's answering a question you now think you've covered.

These are hard to spot. They never fail, so they never show up in an incident. They never flap, so they look like your most stable check. And the code reads fine — ?? [] is idiomatic, it looks defensive, it's the kind of line you skim past approvingly. Reading the diff would not have caught this.

What caught it was a second check disagreeing.

I'd just added a different step that picks a genuinely suppressed address off the live list and asserts our login form refuses it with a reason. It ran in the same fifteen-minute cycle and found one. The older step, same run, said zero. One check saying "here's one" next to another saying "there are none" is what made it visible.

The fix is two lines and slightly embarrassing. Cap the limit at 100 and paginate. And treat a failed read as a failure:

if (res.status !== 200) {
  return {
    ok: false,
    detail: `provider would not return the list (HTTP ${res.status})`,
  };
}

An alarm that can't read its input has to say so. "I don't know" and "nothing is wrong" are different answers and only one of them is safe to paint green.

The other thing I'd do differently: test the check against something you know is broken. Every one of these I've found had never been run against a true positive. If your alarm has never once fired on purpose, you don't actually know it can.

I made that exact mistake twice in one day, incidentally. The replacement check I wrote first looked up a single address and treated HTTP 200 as suppressed — except that path 404s for suppressed and healthy addresses alike, because it only exists for DELETE. Would have reported "fine" for every customer, forever, without ever failing. I only found out because I pointed it at an address I already knew was on the list.

If you want to go looking tonight, the shape to grep for is anywhere a failure can be read as an empty or zero result. ?? [] on a parsed response. data?.rows?.length ?? 0 where 0 means healthy. A try/catch returning a default. Any count-based alert where "we got nothing back" and "there's nothing to report" produce the same number.

The unsubscribe link you can't remove is also your login

Hira — Mon, 10 Aug 2026 14:43:46 +0000

Someone can click "unsubscribe" on a sign-in code and lock themselves out of their own account. You won't find out. The send reports success, same as always.

Here's how that happens.

Our email provider is CSA-certified, which means it attaches a List-Unsubscribe header to everything it relays. Not just marketing. Everything. There's no setting to turn it off for a transactional-only account, and when I set my own List-Unsubscribe it got quietly replaced with theirs. I pulled the raw source of a delivered message to check, because I didn't believe the docs.

Mail clients turn that header into a button. Apple Mail puts an Unsubscribe banner across the top of the message. Gmail does its own version.

So the six-digit code you send someone to get into their account arrives with an unsubscribe button stapled to it.

Click it and the address goes on the provider's suppression list. After that every message to that person is dropped at the relay. The API still returns 2xx. Nothing in your app notices. They ask for a code, your login form says "check your inbox", and nothing is ever going to arrive. They can't get in, and they can't tell you either, because your support flow emails them too.

No error, no bounce, no log line. From your side everything looks fine. From theirs your product is just broken.

The clean fix is a separate provider for auth mail only, and that's where I'm heading. It's not a quick job though. Your auth provider sends its own confirmations and magic links, so pointing that at a different relay means new credentials, new DNS, a warm-up period and a second sender reputation to look after. Until that's done your sign-in codes and your newsletters live or die together.

So here's what I did in the meantime.

First, check the suppression list before triggering the code. You might not be able to ask about one address — on mine, GET /blockedContacts/{email} returns 404 whether or not the address is on the list, because that path only exists for DELETE. The list endpoint ignores an email filter too. So you fetch the whole list and match locally.

// Cached, because this sits on the login path.
let cache = null;

async function suppressed(email) {
  const key = process.env.ESP_API_KEY;
  if (!key) return null;                    // fail open, always

  if (!cache || Date.now() - cache.at > 300_000) {
    const rows = await fetchWholeSuppressionList(key);   // paginate it
    if (rows) cache = { at: Date.now(), map: rows };     // keep stale on failure
  }
  return cache?.map.get(email.toLowerCase()) ?? null;    // reason, or null
}

I got this wrong the first time in a way worth stealing. I checked for HTTP 200 on the per-address path, and since that path 404s for suppressed and healthy addresses alike, my check reported "fine" for every customer, forever, without ever failing. I only caught it because I tried it against an address I already knew was on the list. Do that.

It also has to fail open. A login form that turns people away because a third-party API timed out is a worse outage than the one you're preventing.

Second, say which reason it is. A hard bounce and an unsubscribe are opposite situations. Telling someone "you unsubscribed" when their mailbox actually rejected us is wrong and a bit insulting — their address is fine. So: unsubscribed gets "this address was unsubscribed from our messages, which also stops sign-in codes", and a bounce gets "earlier mail to this address bounced, so our provider stopped trying — if the address is right, ask us to re-enable it."

Third, give them a way back that doesn't need email. This is the part people skip. A support form works while they're suppressed, because filing a ticket doesn't require you to email them. A support email address obviously doesn't. And say plainly on the confirmation screen that no confirmation email is coming, since that's the exact thing they're writing in about.

One thing I'd argue against: don't automate the un-suppression.

A hard bounce means the mailbox doesn't exist, and re-sending to it damages your sending reputation for every other customer. That's how a domain ends up filtered. An unsubscribe means they chose, and reversing that automatically is what GDPR and CAN-SPAM specifically prohibit — doing it systematically on a CSA-certified account puts the account itself at risk, and that account is carrying your sign-in codes. The blast radius of getting it wrong is much bigger than the problem.

"A customer says they clicked it by accident" is real and common. That's a person's call. One click in your admin tool, not a cron job.

The email specifics here are mine, but the shape isn't. Somewhere in your system is an action that reports success while doing nothing, and the only symptom is a customer who goes quiet.

There is no such thing as a good fraud score threshold

Hira — Mon, 10 Aug 2026 14:00:00 +0000

"What threshold should I set?" gets answered with a number far too often. Any number given without knowing the flow is someone guessing on your behalf.

The score is identical everywhere in your product. What changes is what a mistake costs.

Wrongly blocking a newsletter signup costs you an email address. Wrongly blocking a password reset costs you a customer who already pays you, cannot get into their account, and now needs support. Same score, completely different arithmetic — and any single cutoff is wrong for one of them by construction.

Two things I would argue for:

Work out the exchange rate before the number. How many real customers will you turn away to stop one bad signup? You do not need precision, but you need to know which way it leans, and that falls out of the two costs rather than out of a vendor's docs.

Three bands, not two. One line forces every borderline case into one of two wrong answers, and borderline is exactly where real customers and attackers overlap. A middle band routes ambiguity to a step-up — an emailed code, an SMS — which is cheap when you are right and recoverable when you are wrong.

The part I find most people have not solved: how do you measure the mistake you cannot see? Fraud that gets through arrives as a chargeback. A customer wrongly refused closes the tab, and nothing in your dashboard records they existed.

How are you counting that one?