DEV Community: Kumar Deepanshu

Sequential IDs Are a Security Decision

Kumar Deepanshu — Thu, 10 Sep 2026 06:00:07 +0000

Originally published at lumbox.co

A convenient helper, of a kind that exists in most codebases:

function findByRef(ref) {
  if (/^\d+$/.test(ref)) {
    return db.get("SELECT * FROM runs WHERE id = ?", Number(ref));
  }
  return db.get("SELECT * FROM runs WHERE public_id = ?", ref);
}

Take an id or a public handle, return the row. Scripts pass the numeric id, the web passes the handle. It reads as a kindness.

Now route an HTTP path segment through it:

app.get("/api/runs/:id", (req, res) => {
  const run = findByRef(req.params.id);
  res.json({ run, leads: leadsOf(run.id), shareUrl: shareFor(run.id) });
});

Every URL the application generates contains a random handle with 72 bits of entropy. Nobody guesses one. But the route also accepts 1, and 2, and 3, and now the entire table is walkable with a for loop.

Why the gate did not catch it

The route was deliberately unauthenticated, and for a defensible reason: the page for a run polls its own status, and running that poll through the authenticated, rate-limited path would have made a page consume its own quota. Public reads were an intentional design decision.

That decision is completely fine, and it is only fine while the identifier is unguessable. The auth rule and the identifier scheme were two separate choices made by two different people at two different times, and the security property lived in the space between them where nothing tested it.

The matcher did not help either. It was anchored:

const COSTLY = /^\/api\/(runs|run|brief)\/?$/;

That matches /api/runs and nothing below it. The collection was rate limited. Every individual resource under it was not.

The fix is a second function, not a check

The instinct is to add a validation branch to the handler. Better to make the unsafe capability unreachable from the network:

/** The only lookup a request off the network may use. */
function findByPublicId(ref) {
  return db.get("SELECT * FROM runs WHERE public_id = ?", ref);
}

Internal callers keep the flexible helper. HTTP handlers get the narrow one. The rule is now expressed in the type of thing a handler can call, rather than in a check somebody has to remember to write in each new route.

Write the test against the vulnerability

A test asserting the new function works is nearly worthless, because it would pass before the bug existed and after it was reintroduced somewhere else. Assert the distinction instead:

assert.ok(findByRef(String(row.id)), "the numeric path still exists internally");
assert.equal(findByPublicId(String(row.id)), undefined, "and is unreachable publicly");

That test documents why the two functions exist. Delete the second one and it fails.

Two things worth taking away

First, a helper that accepts several kinds of identifier is a fine internal convenience and a poor public boundary. The flexibility is the vulnerability.

Second, when you deliberately leave something unauthenticated, write down what is carrying the security instead. If the answer is "the identifier is unguessable", then any code path that accepts a guessable identifier for the same resource is a bug, and it is worth a test that says so.

Plan Then Execute: One LLM Call Instead of Thirty

Kumar Deepanshu — Wed, 09 Sep 2026 18:00:12 +0000

Originally published at lumbox.co

If you have built a browser agent, you have probably shipped this loop: send the current page to the model, ask what to do next, execute that one action, repeat. It is the default across browser-use, Stagehand's agent mode, and most framework browser tools. The model is the brain, the browser is the body, and every step is a round trip.

There is a different shape. Make one model call that writes the whole plan down as JSON, then run that plan with a deterministic executor that never calls a model at all. This post is what that looks like in practice, including the exact schema we run in production, and honest arithmetic on what it saves.

Why the loop is expensive twice over

The obvious cost is the round trips. The less obvious one is what you send on each of them.

An agent loop has to include the current page state on every call, because that is the only thing telling the model where it is. A serialised DOM or accessibility tree for a real signup page is commonly ten to fifty thousand tokens. Twenty steps at twenty five thousand tokens each is half a million input tokens for one task.

The structural cost is worse. At every step the model has to re-derive the plan it already held implicitly one step earlier. Ask it to sign up for a product and it sketches the same sequence in its head each time: go to the signup page, fill the email, submit, wait for the code, paste the code, verify. Then it picks one action and throws the rest away. Next step, it sketches it again. Most of the time it lands in the same place. Sometimes it picks the login link instead of the signup link, and every subsequent step compounds that.

Linear goals do not need this. "Sign up with this address" has one obvious sequence. The model is very good at writing that sequence down once. It is mediocre at re-deriving it twenty times without drifting.

The shape

goal --> planner (1 LLM call) --> JSON plan --> executor (0 LLM calls) --> result

The planner gets one shot and is told so in its system prompt. It has no follow-up call to correct itself, which is deliberate: it makes the model plan defensively rather than optimistically.

The ten step types, exactly

This is the real schema, not a simplification. A plan is { "reasoning": string, "steps": Step[] } and a step is one of:

{ "type": "navigate", "url": string }
{ "type": "click", "describe": string, "text"?: string, "selector"?: string }
{ "type": "fill", "describe": string, "selector"?: string, "label"?: string, "value": string }
{ "type": "wait_seconds", "seconds": number }
{ "type": "wait_for_text", "text": string, "timeout_seconds"?: number }
{ "type": "wait_for_email", "inbox_id"?: string, "from"?: string, "subject"?: string, "timeout_seconds"?: number }
{ "type": "use_otp_from_inbox", "inbox_id"?: string, "selector": string, "timeout_seconds"?: number }
{ "type": "open_link_from_inbox", "inbox_id"?: string, "from"?: string, "timeout_seconds"?: number }
{ "type": "extract_text", "describe": string, "selector"?: string }
{ "type": "done", "summary": string }

Three constraints in the planner prompt do most of the quality work:

Every plan ends with done. The executor breaks out of its loop on done and takes the summary as the task result. A plan without one runs to the end of the array and returns a generic summary.
Prefer text over selector on a click. Humans see text, and text survives a CSS refactor. Selectors are the fallback, not the default.
Keep plans under fifteen steps. Long flows fail. If the goal is bigger than that, the planner is told to plan the first sub-goal only and emit done with a summary of what is left, so the caller can decide whether to continue.

Values can carry {{inbox_address}}, which the executor substitutes before each step runs. That is what lets a plan be written before the inbox it will use exists.

The three steps that cross into email

Six of the ten types are ordinary browser actions. Three are not, and they are the reason this architecture is worth describing at all:

wait_for_email blocks until a message matching the filter lands in the bound inbox
use_otp_from_inbox waits for the mail, extracts the code, and fills it into a selector
open_link_from_inbox waits for the mail, finds the verification or magic link, and navigates to it

In an agent loop, "check the email" is not an action the browser can take. You break out of the loop, poll a mail API in your own code, feed the result back in as text, and hope the model picks up where it left off. That handoff is where a lot of signup automation actually breaks.

Here it is one step in the plan, because the inbox and the browser session are in the same runtime. A full email-verified signup:

{
  "reasoning": "Standard email signup with a code sent to the inbox.",
  "steps": [
    { "type": "navigate", "url": "https://example.com/signup" },
    { "type": "fill", "describe": "email field", "label": "Email", "value": "{{inbox_address}}" },
    { "type": "click", "describe": "submit the signup form", "text": "Sign up" },
    { "type": "wait_for_email", "from": "example.com", "timeout_seconds": 120 },
    { "type": "use_otp_from_inbox", "selector": "input[name='code']" },
    { "type": "click", "describe": "confirm the code", "text": "Verify" },
    { "type": "wait_for_text", "text": "Welcome", "timeout_seconds": 30 },
    { "type": "done", "summary": "Account created and email verified." }
  ]
}

No glue code between the browser and the mailbox, because there is no boundary to glue across.

The arithmetic

We have not run a published benchmark, so here is the calculation instead of a number to take on faith. Substitute your own figures; the shape holds.

Take a twenty step task, twenty five thousand tokens of page state per step, priced at Claude Sonnet rates of $2 per million input tokens and $10 per million output.

Agent loop. Twenty calls carrying 25k tokens each is 500,000 input tokens, or $1.00, before a single output token. Add roughly 500 output tokens per step and you are at about $1.10.

Plan then execute. One call. The system prompt is roughly 600 tokens and is marked for caching, so it costs about a tenth of that on every call after the first. The goal plus inbox context is perhaps 1,000 tokens. Output is capped at 2,048. Call it 1,700 input and 800 output: about $0.011.

That is roughly two orders of magnitude, and the dominant term is not the number of calls. It is that the loop pays for the page state twenty times and the planner never pays for it at all. If your pages serialise smaller, the gap narrows proportionally. If you run more steps, it widens.

One thing that is easy to get wrong here: the planner call is a good candidate for prompt caching precisely because the system prompt is frozen and comes first, while the volatile part (the goal, the inbox context) goes last. Reverse that order and the cache never hits.

What this architecture does not do

Being straight about the limits, because they are the reason to keep a loop around for some jobs.

There is no replanning. The executor runs each step, and on the first failure it records the error, stops, and returns everything up to that point. It does not retry, ask a model for a fix, or improvise. When a page has changed since the plan was written, the plan is wrong and the task fails. That is a deliberate trade: predictable failure with a full step-by-step event log beats an agent that quietly does the wrong thing for another fifteen steps.

There is no plan cache. Every call plans from scratch today. Caching by goal and domain is the obvious next win and it is not built.

Exploratory goals do not fit. "Find a product under fifty dollars" or "research this site and report back" have no linear sequence to write down. The whole premise is that the plan is knowable in advance. When it is not, you want the loop, and you should pay for it.

The fifteen step cap is real. Longer plans get noisier and the model starts over-explaining. Splitting into sub-goals with an explicit handoff summary works better than raising the cap.

When to use which

Goal shapeUse
Linear and repeatable: signups, email verification, password resets, form fills, single page extractionPlan then execute
Branchy and exploratory: research, comparison, navigating an unfamiliar menu treeStep level agent loop

Most production browser automation is the first row. It is worth knowing that the first row does not need an agent at all.

The general version

This is not really about browsers. Whenever a model's strength is sketching a sequence once and its weakness is re-deriving that sequence repeatedly, plan then execute wins: multi step API workflows, file operations, migration scripts. The test is simple. Ask whether the plan is knowable before you start. If it is, write it down once and run it with an interpreter you control. If it genuinely is not, that is what the loop is for.

The runtime described here is the browser act endpoint: one call, one planner hit, deterministic execution, with the inbox in the same runtime so the verification steps are primitives rather than glue.

Pagination Is an Agent Experience Problem

Kumar Deepanshu — Wed, 09 Sep 2026 18:00:11 +0000

Originally published at lumbox.co

A list endpoint returning everything is a familiar, forgivable shortcut. A human calling it gets a slow page and scrolls. A browser handles a 794KB JSON response without complaint.

An agent does not. The response goes into a context window, and a large one either truncates the conversation, evicts the instructions that came before it, or fails outright. The tool call does not return data, it returns a wall.

We had this on list_inboxes. An account that provisions an inbox per task accumulates them quickly, and one had 3,219. The response was 794,423 characters across 28,975 lines. It exceeded the caller's limit and returned nothing usable, on the MCP surface we describe as the reason to use the product.

The costs are different

For a human API the cost of a big response is latency and bandwidth, both of which degrade gracefully. For an agent the costs are:

Context. Finite and shared with everything else the agent needs to remember. A large response can evict its own instructions.
Money. Tokens are billed. A response nobody reads is still paid for.
Attention. Even within limits, burying three relevant rows in three thousand measurably degrades what the model does next.

Graceful degradation does not exist here. It works, or the turn is destroyed.

What a paginated response owes an agent

Human pagination assumes a UI that renders "next". An agent has to decide, from the response alone, whether to continue. So say so explicitly:

{
  "data": [ /* 50 rows */ ],
  "cursor": "inb_a1HjMJs44WShWc3CpEeI",
  "has_more": true,
  "total": 3226
}

total is the field people leave out and it is the one that changes behaviour. Without it, the agent knows there is more but not whether that means one page or sixty five. With it, it can decide to filter instead of paging, or tell the user the list is large, or stop. Return it on the first page only, since recounting on every page is wasted work.

Make the tool description carry it

The schema is not enough. The model reads the description, so the description has to explain the protocol:

"List the email inboxes you have created, newest first. Paginated: the
first page reports 'total', and 'has_more' with 'cursor' means there are
more. Pass that cursor back to continue."

Do not break the SDKs

Adding a default limit changes behaviour for everyone who was relying on getting everything. A method documented as returning all inboxes should keep doing that, which means the SDK follows the cursor internally:

async listInboxes() {
  const out = [];
  let cursor;
  for (;;) {
    const res = await this.get("/v1/inboxes?limit=200" + (cursor ? "&cursor=" + cursor : ""));
    out.push(...res.data);
    if (!res.has_more || !res.cursor) return out;
    cursor = res.cursor;
  }
}

The agent-facing tool exposes the pages. The library-facing method hides them. Those are different audiences and it is fine for them to differ.

One implementation note

If your ids are random, a cursor of WHERE id < :cursor is not correct, because random ids do not sort in the order you are returning rows. Use your database's cursor primitive, which walks the ordered result, or key the cursor on the actual sort column. This bug is quiet: it works for page one and silently skips or repeats rows later.

We Buy the Browser and Build the Inbox

Kumar Deepanshu — Wed, 09 Sep 2026 06:00:32 +0000

Originally published at lumbox.co

An agent that can act on the web needs two things that are easy to confuse. It needs a browser that does not get blocked, and it needs an identity that can receive mail, because almost every meaningful action behind a login starts with a code or a link sent to an address.

They look like two halves of one product. They are not. One of them is a commodity and one of them is not, and getting that backwards is an expensive way to spend a year.

The commodity half

Stealth browser runtimes are a solved and crowded category. Steel ships a self-hostable stealth Chromium. Browserbase ships the hosted version. Browser-use added stealth sessions. Anthropic and Microsoft both expose browser-level primitives directly to a model. These products differ on price, on residential proxy quality, on geography, and on how quickly they respond when an anti-bot vendor ships an update. They do not differ on what they fundamentally are.

When four or five funded teams ship the same primitive, the honest read is that it is infrastructure now. The correct move for a small team is to buy it.

So we run on Steel. browser-executor.ts opens a Steel session with stealth on, runs the plan against it, and deletes the session in a finally block so a thrown step cannot leak a browser. That is the entire relationship. It is about a hundred lines of client code, and if the anti-bot landscape shifts, that is Steel's problem to solve and ours to benefit from.

We would not win a stealth arms race against five better-resourced teams. Entering it would have cost us the thing we can actually win.

The half that is not a commodity

Now the other side. An agent needs an address that can receive a verification code. The available options are worse than they look:

A real mailbox on a consumer provider. Automating a personal account is against terms, and consumer providers are aggressive about flagging automated access. This works until it very suddenly does not.
A disposable inbox service. Built for humans testing signup flows. Public inboxes, addresses on domains that half the internet already blocks, and no API contract you would put in a production path.
A raw transactional email provider. Excellent at sending. Receiving means running your own MX, parsing MIME, and building everything above it yourself.

None of these is a mailbox an agent can reason about. That is a different object, and the gap between "an email arrived" and "the agent knows what to do" is where the work actually is.

The test we used

One question, applied to each half: if we do nothing here, does someone else's roadmap solve it for us within a year?

For the browser, the answer was clearly yes. Five teams are already sprinting at it and their output arrives as a version bump.

For the agent mailbox, the answer was no. Every adjacent vendor is optimising for a different customer. Transactional email vendors optimise for sending at volume. Disposable inbox tools optimise for a human watching a test run. Nobody in that set has a reason to build long-poll retrieval or structured extraction, because their users do not need it.

Build where the answer is no. Buy where the answer is yes. It is not a sophisticated test, but applied honestly it kills a lot of appealing projects, including our own stealth browser.

What "a mailbox an agent can reason about" means concretely

The difference is not the mail. It is what sits between the mail arriving and the agent continuing.

Blocking retrieval instead of polling. An agent waiting for a code should not run a sleep-and-check loop, burning tokens re-reading an empty inbox and guessing at an interval. It should make one request that returns when the mail lands or times out. A polling loop is a retry policy the caller has to invent; a long poll is one line.

Extraction as part of the contract. The agent wants the six digit code, not a MIME tree. Handing a model the full HTML body of a marketing-styled verification email and asking it to find the code costs tokens and introduces a failure mode that did not need to exist. Pulling the code out is deterministic string work. Do it once, server side, and return the code.

The same for links. Magic link flows need the link extracted and followed, not summarised.

That is why the browser plan has wait_for_email, use_otp_from_inbox, and open_link_from_inbox as first class steps rather than as escape hatches into user code. Because the inbox and the browser session are in one runtime, the verification step in a signup flow is a step in the plan, not a handoff out of the plan and back into it. Most signup automation breaks at exactly that handoff.

What we are honest about

Buying the browser is a real dependency. If Steel has an outage, browser tasks fail; a provider abstraction is on the roadmap and it is not built today, so a swap would mean a code change, not a config change. That is the price of the decision and it is the right price to pay at our size. Writing an abstraction layer for a second implementation you do not have yet is how small teams accidentally build frameworks instead of products.

Some things are worth owning. A stealth Chromium is not one of them when five teams already ship it. The mailbox the agent thinks with is.

If you want the second half without building it, that is what Lumbox is: a real inbox per agent, with blocking retrieval and structured extraction, on one API key.

Email Verification When You Are One Person

Kumar Deepanshu — Wed, 09 Sep 2026 06:00:31 +0000

Originally published at lumbox.co

Email verification pricing is built around a particular customer: a sales team that has bought a list of 50,000 strangers and needs to know which addresses are real before burning their domain on it. Per-credit pricing, bulk tiers, enterprise plans.

If you are one person with a signup form, you have a different problem, and most of what that product sells solves something you do not have.

Three different questions

"Verify this email" is really three questions with very different costs.

Is it syntactically an address? Free, instant, and you should already be doing it. Do not use an elaborate regex. Check for one @, a domain with a dot, and no whitespace. Over-strict validation rejects real addresses, and plus-addressing and newer TLDs are the usual casualties.

Can the domain receive mail at all? Free, fast, and this is the highest value check available to you. Look up the domain's MX records. No MX means no mail, ever, and that catches the entire class of typos that matters: gmial.com, hotmial.com, a domain that expired. One DNS query, no vendor.

Does this specific mailbox exist? This is the expensive one, and it is what you are actually paying vendors for.

Why the third question costs money

Proving a mailbox exists means opening an SMTP conversation with the receiving server and getting as far as RCPT TO without sending anything. It is a normal protocol interaction, and it is also exactly what someone harvesting addresses does, so mail servers defend against it.

They defend by refusing connections from IP addresses that are not established senders. Residential and most cloud IPs are refused outright. Some providers accept every address regardless, which tells you nothing.

What a verification vendor sells is a pool of IP addresses with enough reputation that mail servers will still talk to them. That is a real asset and genuinely hard to build. It is not clever code.

The dangerous failure

If you write this yourself and run it from your laptop, you will get 5xx rejections and it is tempting to record them as "invalid". They are not. A 5xx at RCPT TO from an unestablished IP is the server declining to talk to you. Marking those addresses invalid deletes real customers from your list.

Only treat a rejection as a bad address when the response names the recipient, typically a 5.1.x code with text about an unknown user. Everything else is unknown, and unknown is a legitimate answer that any honest verifier should return.

What to actually do

For a signup form:

Syntax check on the client for immediate feedback.
MX lookup on the server. Reject with a helpful message when the domain cannot receive mail, and offer the obvious correction for common typos.
Send a confirmation email. This is the only check that proves both that the address exists and that the person asking controls it, and it costs one email.

You do not need a verification vendor for a signup form. Confirmation email is verification, and it is stronger than anything a vendor can sell you.

For a list you already have and want to mail, the calculus changes. If it is a few hundred addresses collected through your own signup flow, mail them and let the bounces suppress themselves. If it is tens of thousands of addresses of unknown provenance, verify first, because a 13.8% bounce rate will get your sending account reviewed and the vendor fee is cheaper than that.

The honest summary

Syntax and MX are free and catch most real-world mistakes. Mailbox-level verification needs clean sending IPs, which is a thing you rent rather than build. And if you control the signup, a confirmation email beats all of it.

How to Warm Up a New Sending Domain

Kumar Deepanshu — Mon, 07 Sep 2026 18:00:30 +0000

Originally published at lumbox.co

A domain that has never sent mail is not trusted or untrusted, it is unknown. Receiving servers treat unknown senders cautiously, and the way you move out of that category is by sending mail that people engage with, in gradually increasing volume, consistently.

Before you send anything

Get authentication right first, because a warm-up on a misauthenticated domain teaches receivers the wrong lesson.

SPF: a TXT record authorising your sending service. Keep it under the 10 DNS lookup limit or it fails silently.
DKIM: the provider gives you a key to publish. Verify it is actually signing by checking a received message's headers, not by trusting the dashboard.
DMARC: start at p=none with a reporting address so you can see what is happening, then move to quarantine and reject once the reports are clean.
Reverse DNS and a valid return path, if you run your own infrastructure.

The ramp

Volume roughly doubles every few days, with the exact numbers mattering far less than the shape. A workable four week ramp:

Week 1:  50 -> 200 per day
Week 2:  500 -> 2,000 per day
Week 3:  5,000 -> 10,000 per day
Week 4:  20,000+ per day

Two rules matter more than the numbers. Send every day, because a domain that sends 2,000 on Monday and nothing until Friday looks like a burst, not a business. And never skip a rung because you are in a hurry.

Who you send to matters more than how many

This is the part people miss. During warm-up, send to your most engaged recipients first, and expand outward. Opens and replies are positive signals. Deletions without opening are neutral at best. Spam complaints are severely negative.

Order your ramp by engagement:

People who opened or replied in the last 30 days.
Last 90 days.
Last 180 days.
Everyone else, if at all.

Sending to a two year old list on day three of a warm-up will produce bounces and complaints at exactly the moment receivers are deciding who you are.

Watch the right numbers

Bounce rate under 2% and complaint rate under 0.1% are the working targets, not the published limits. The published limits are where enforcement begins, which is far too late to be your alarm.

Segment by receiving domain too. Gmail, Outlook and Yahoo form independent opinions, and it is normal to be doing fine at one and badly at another. An aggregate number hides that completely.

If it goes wrong

If placement drops mid-ramp, go back a step and hold there. Do not push through. The signal you are getting is that you moved faster than trust accumulated, and the only remedy is time at lower volume.

And if you are ramping because you were forced off a shared domain after an incident, be aware you may be warming a new domain while the underlying provider account still carries the old reputation. Reputation attaches to more than the domain name.

Shared or Dedicated Sending Domain: How to Actually Choose

Kumar Deepanshu — Fri, 04 Sep 2026 18:00:06 +0000

Originally published at lumbox.co

Every email platform offers both. The shared domain works instantly and needs no DNS. The dedicated domain needs SPF, DKIM and DMARC records and a warm-up period. The marketing copy rarely tells you which one you should be on, because the honest answer depends on a number.

The number is your monthly volume

Reputation is built from consistent volume. A receiving mail server forms an opinion about a sending domain by watching it over time. If you send 200 messages a month from your own domain, there is not enough signal for anyone to form a positive opinion, and you get treated as an unknown sender indefinitely.

Rough guidance:

Under a few thousand a month: shared domain. You will get better placement riding an established reputation than you will building your own from nothing.
Consistent five figures a month: dedicated. There is enough volume to establish and hold a reputation, and you stop being exposed to other senders.
Anything you brand: dedicated, regardless of volume. If the from address needs to say your company name, that is a product requirement, not a deliverability one.

What you are actually buying with a shared domain

You are renting someone else's reputation, and rented reputation is pooled. The other tenants affect your placement. A platform that runs a shared domain well is one that polices who may send under it, because the alternative is that one abusive tenant degrades delivery for everyone.

Questions worth asking a provider before you rely on their shared domain:

Can a free account send under it, and how much?
Are addresses on it screened for brand impersonation?
Is there a per-account ramp, or can a new account send at full volume on day one?
Is reputation pooled per provider account, or segmented?

A provider that cannot answer these has not thought about the failure mode, and the failure mode lands on you as unexplained spam placement.

What you take on with a dedicated domain

Your reputation becomes yours. That is the whole point and also the whole risk. A bad month is your bad month, and nobody else's volume dilutes it.

You also take on the setup. SPF authorises the sending service. DKIM signs the message so it cannot be tampered with in transit. DMARC tells receivers what to do when the first two disagree, and it is the one people skip. A domain with SPF and DKIM but no DMARC record is a domain anyone can spoof with no consequence.

The subdomain most people get wrong

Send bulk mail from a subdomain, not your root domain. If mail.example.com gets a reputation problem, example.com is largely insulated, and your invoices and password resets keep arriving. Sending marketing and transactional traffic from the same domain means one bad campaign can stop your password resets.

Separate them further if the volumes are different in kind: transactional on one subdomain, marketing on another. Receivers form separate opinions, which is exactly what you want.

Switching later

Moving from shared to dedicated is not a flag flip, it is a warm-up. Plan several weeks. Do not move all traffic at once, and do not start with your least engaged recipients. The next post in this series covers the ramp.

Recording a Bounce Is Not the Same as Honouring It

Kumar Deepanshu — Wed, 02 Sep 2026 18:00:29 +0000

Originally published at lumbox.co

Almost every email integration gets the first half right. The provider posts a bounce or a complaint to a webhook, you parse it, you write a row. There is a nice chart in the dashboard showing bounces over time.

Then someone sends to that address again next week, and it bounces again, and you record a second row.

The table is not the defense

A suppression list only does anything if something reads it at send time. If your bounce data exists purely to render a graph, you have built observability, not protection. Every hard bounce you have ever recorded is an address you are still willing to mail.

The fix is not complicated, but it has to go in the right place:

async function sendEmail(input) {
  const blocked = await isSuppressed(input.orgId, input.to);
  if (blocked) {
    throw new SendBlocked("recipient is suppressed: " + blocked.reason);
  }
  return provider.send(input);
}

The important word is every. Find the function that every send path funnels through and put the check there. If you have a single-send route, a batch route, a reply route and an auto-responder, and you add the check to three of them, you have not added the check.

Batch sends need their own path

A batch of 100 recipients where 4 are suppressed should send 96 messages, not throw. That means the batch path needs a filter rather than a guard:

const { allowed, dropped } = await filterSuppressed(orgId, recipients);
if (allowed.length === 0) throw new AllRecipientsSuppressed();
await provider.sendBatch(allowed);
return { sent: allowed.length, suppressed: dropped };

Report the dropped ones back to the caller. Silently sending to fewer people than they asked for is how you lose their trust in the numbers.

What to suppress, and what not to

Suppress on permanent failures and on complaints. Do not suppress on transient ones.

Hard bounce (mailbox does not exist, domain does not exist): suppress permanently.
Complaint (recipient marked it as spam): suppress permanently, and treat it as more serious than a bounce. Complaint thresholds are twenty times tighter than bounce thresholds.
Soft bounce (mailbox full, greylisted, temporary failure): do not suppress. Retry. Suppressing these throws away deliverable addresses.
Blocked by reputation: this is about you, not the recipient. Suppressing the address hides your own problem and loses a real contact.

The race nobody plans for

Provider webhooks are fast. Sometimes they arrive before your own database has finished writing the row for the message you just sent. If your handler looks up the message by provider ID and drops the event when there is no match, you will silently lose exactly the bounces that happened quickest, which are disproportionately the hard ones.

Do not drop unmatched events. Fall back to attributing them by the sending address, or queue them for a retry. An unmatched bounce is still a bounce.

One check worth writing

The regression that matters is not "does suppression work", it is "does every path use it". A test that enumerates your send routes and asserts each one refuses a suppressed recipient will outlive any individual bug fix.

What a 13.8% Bounce Rate Does to an AWS SES Account

Kumar Deepanshu — Mon, 31 Aug 2026 18:00:34 +0000

Originally published at lumbox.co

AWS SES publishes two thresholds. Above a 5% bounce rate your account is placed under review. Above 10% sending can be paused entirely. Complaint rate has its own pair, 0.1% and 0.5%. These are measured as a rolling average across the whole account, not per domain, and that last detail is the one that catches people.

Account-wide means account-wide

If you have seven verified domains on one SES account, they share a single reputation. One domain sending to a stale list drags the other six down with it. There is no per-domain quarantine and no way to ringfence a bad sender after the fact. The blast radius of a reputation problem is every address you have ever verified on that account.

This is the single most important thing to understand before you let anyone else send under your infrastructure. If you run a shared sending domain for customers, or a free tier, or a demo, you have pooled every one of those senders' reputations into one number.

A high bounce rate is usually not a list hygiene problem

The instinct when the review email lands is to go clean your list. Sometimes that is right. Often it is not, and the distinction matters because cleaning a list you already own does nothing about traffic that has not been sent yet.

Bounce rate is a ratio. It goes up when bad sends increase, and it also goes up when good sends stop. The three causes worth checking, in order:

Someone is sending to scraped addresses. Purchased and scraped lists bounce at rates well north of 20%. If a portion of your traffic is coming from a free tier or a shared domain, check who is sending before you check what.
You are not honouring your own bounce feedback. If a hard-bounced address can be mailed again next week, every send after the first one is a guaranteed bounce that you generated yourself.
Your good traffic dropped. A seasonal lull in legitimate volume raises the ratio without a single new bad address.

What to do in the first hour

Stop the bleeding before you write the appeal. In order:

Find the sending addresses, not the subjects. Subject-line heuristics fall apart the moment the content is not in English. The from address is the reliable signal and it is the one an abuser has to reuse.
Enforce suppression at send time. Not in a dashboard, in the code path every send funnels through. See recording a bounce is not the same as honouring it.
Turn on per-domain attribution. SES Virtual Deliverability Manager and configuration set event destinations are things you have to enable before you need them. If they are off during the incident, AWS holds no per-domain breakdown for that period and you cannot tell from their side which domain caused it.
Pause the traffic you cannot explain rather than the traffic you can.

The appeal

AWS wants three things: what happened, what you changed, and why it will not recur. Specific beats apologetic. "We identified 307 accounts sending to scraped lists, suspended them, and now enforce bounce suppression in the send path with a per-account age-based ramp" is an appeal. "We take deliverability seriously and have cleaned our list" is not.

Getting the ratio back down

The rate is a rolling average, so it recovers in two ways: bad sends stop, and good sends accumulate. You cannot delete history. Send your most reliable traffic, the transactional mail going to addresses that have engaged recently, and let volume do the rest. Do not try to outrun it with more volume, because if any of that new volume bounces you have made it worse.

Expect days, not hours. Plan the appeal around that.

Per-User Inbox Provisioning for Multi-Tenant Agent SaaS

Kumar Deepanshu — Mon, 15 Jun 2026 18:00:05 +0000

Originally published at lumbox.co

If you're building an agent product — personal shopping agents, AI recruiters, autonomous SDRs — every end user will eventually need their own agent, and every agent needs its own inbox. The naive approach (one shared inbox, filter by user) collapses fast. Here's the pattern that scales.

The rule: one inbox per (tenant, agent) pair

For a user running 3 agents, you provision 3 Lumbox inboxes. Each has isolated state, its own OTP stream, its own webhook routing. Tenancy becomes a property of the inbox, not a filter on a shared stream.

async function provisionAgent(userId: string, agentConfig: AgentConfig) {
  const inbox = await lumbox.inboxes.create({
    displayName: `${userId}/${agentConfig.name}`,
    metadata: { userId, agentId: agentConfig.id },
  });

  await db.agents.create({
    userId,
    inboxId: inbox.id,
    address: inbox.address,
    config: agentConfig,
  });

  return inbox;
}

Webhook routing

One webhook endpoint on your side, Lumbox posts every received email with the inbox's metadata. You look up which tenant + agent by the userId in the metadata and dispatch accordingly. No filtering, no risk of cross-tenant leaks.

Custom domain per tenant

For pro-tier customers, let them bring their own domain. Lumbox supports multi-domain inbox provisioning under a single org — the inbox is created on @theirdomain.com, but your billing + usage aggregation stays on the single parent org.

Lifecycle

Soft delete when a user pauses an agent. Keep the inbox; stop webhook routing.
Hard delete when they churn. Lumbox purges the inbox and all history.
Transfer supported via org migration — inbox stays, billing moves.

Billing

Lumbox's metering reports per-inbox usage. Roll it up to tenant-level for your own invoicing, or expose it in a per-user dashboard. No per-tenant infrastructure to run — it's all one API call. lumbox.co.

Web Bot Auth: Signing Outbound Agent Webhooks with HTTP Message Signatures

Kumar Deepanshu — Fri, 12 Jun 2026 18:00:29 +0000

Originally published at lumbox.co

Your SaaS sends webhooks. The receiver's endpoint is public. Anyone who discovers the URL can POST to it pretending to be you. Shared HMAC secrets are the common fix, but they require out-of-band key exchange and they don't rotate well. RFC 9421 HTTP Message Signatures — the "Web Bot Auth" pattern — is the better answer.

What Web Bot Auth gives you

You publish an Ed25519 public key at /.well-known/http-message-signatures-directory.
You sign outbound requests with the matching private key using the Signature-Input and Signature headers.
The receiver fetches your JWKS (once, cache it) and verifies every incoming request.

No shared secret. No one-to-one key exchange. Rotate by publishing a new kid in the JWKS.

The signature in practice

Signature-Input: sig1=("@method" "@target-uri" "content-digest" "date");\
    keyid="FOhe9v_YLODSykvK-u7VZ5K1-pI85ZN64swJn1YiLcQ";\
    alg="ed25519";\
    created=1749744000
Signature: sig1=:MEUCIQDX...:
Content-Digest: sha-256=:X48E9qOok...:
Date: Tue, 12 Jun 2026 12:00:00 GMT

Signing side (Node)

import { sign } from "http-message-signatures";

const signed = await sign(request, {
  key: privateKey,
  keyId: "FOhe9v_YLODSykvK-u7VZ5K1-pI85ZN64swJn1YiLcQ",
  alg: "ed25519",
  components: ["@method", "@target-uri", "content-digest", "date"],
});
await fetch(signed.url, { method: "POST", headers: signed.headers, body });

Verifying side

The receiver fetches your JWKS from /.well-known/http-message-signatures-directory, caches it, and runs the signature verification. Any tampered body, replayed request (outside the created window), or wrong keyid fails verification.

Why agents especially need this

When an AI agent receives a webhook from a third party, it has no way to know if the payload is legit unless the sender is cryptographically identified. Web Bot Auth is the pattern Cloudflare, Anthropic, and others are converging on for agent-to-agent trust. lumbox.co signs every outbound webhook with Ed25519 so your agent can trust what arrives.

OAuth for MCP Servers: Authenticating Agents, Not Humans

Kumar Deepanshu — Tue, 09 Jun 2026 18:00:20 +0000

Originally published at lumbox.co

The Model Context Protocol spec recommends OAuth 2.1 + Dynamic Client Registration (RFC 7591) for server authentication. In practice, 90% of MCP servers ship with static API keys. That works for single-user local setups. It breaks the moment you want to expose an MCP server to many agents, many users, or a public marketplace.

Why OAuth beats API keys for MCP

Scoped access. An agent can request inboxes.read but not inboxes.delete.
Revocable without rotating. A compromised token is revoked; the long-lived secret never leaves the server.
Per-user attribution. Every tool call has a user identity. Audit becomes possible.
Dynamic client registration. An MCP client (Claude, Cursor) can self-register without a human configuring the server.

The minimum viable OAuth surface

/.well-known/oauth-authorization-server — RFC 8414 metadata.
/.well-known/oauth-protected-resource — RFC 9728 linking resource to auth server.
/oauth/register — RFC 7591 Dynamic Client Registration.
/oauth/authorize — standard OAuth 2.1 authorization code flow with PKCE.
/oauth/token — token exchange.

Token design for agents

Short-lived access tokens (15 minutes), long-lived refresh tokens (30 days, rotating on use), narrow scopes per tool class. Don't issue a token with * scope unless the client literally needs every tool.

The Lumbox approach

Lumbox's MCP server is moving from API-key auth to full OAuth 2.1 + DCR. When an agent installs @lumbox/mcp-server, the client auto-registers, pops an OAuth consent screen once, and gets scoped tokens for the tools it asked for. No hand-editing a config file with a key. lumbox.co.