Forem: LayerZero

A Roblox Cheat + One AI Tool Took Down Vercel. Your Stack Is Probably Next.

LayerZero — Tue, 21 Apr 2026 05:13:07 +0000

A Roblox cheat.

That's what the story starts with. Not a nation-state APT, not a zero-day in the kernel, not some genius Stuxnet-grade payload. A cheat a teenager downloaded to get infinite Robux.

And one AI dev tool.

Together, that combo took Vercel's platform offline earlier this month. If you shipped anything on a preview URL that day, you remember. The post-mortem is still circulating in security channels and the pattern it exposes is quietly devastating — because almost every vibe-coded SaaS in 2026 is built the same way.

Let me walk you through what actually happened and why your stack is almost certainly vulnerable to the same class of attack.

What actually happened

Here's the chain, compressed:

A developer's personal machine got infected by a Roblox cheat bundled with an infostealer — the cheat was the candy, malware was the hook.
The infostealer grabbed session cookies and API tokens sitting in the developer's environment. Standard malware playbook — boring, effective.
One of those tokens belonged to an AI-powered development tool the developer had connected to their Vercel account. The tool had broad deploy and environment-variable permissions, because it needed them to "help you ship faster."
The attacker didn't even need to write exploit code. They fed the stolen token to the same AI tool and asked it, in plain English, to deploy malicious code and exfiltrate secrets across connected projects.
The tool, doing its job, fanned out. Because it was trusted. Because it had keys. Because nobody had modeled "what if the AI gets prompted by the wrong human?"

That's it. That's the whole attack. No CVE. No memory corruption. Just stolen credentials and an obedient AI with too much power.

Why this class of incident is about to explode

Every hot dev tool in 2026 is bolting on the same architecture:

An OAuth connection to GitHub, Vercel, Supabase, AWS.
A long-lived token stored locally or on a vendor server.
An AI agent that can take actions on your behalf.
Permission scopes that are effectively admin because scoping down "breaks the magic."

That's the same architecture as the Vercel breach. And it's sitting on tens of thousands of developer laptops right now.

The security community has a name for this failure mode: confused deputy. A trusted actor with broad privileges is tricked into using those privileges on behalf of an attacker. The AI tool wasn't compromised. It wasn't even misbehaving. It was doing exactly what it was told to do — by the wrong person, holding the right token.

The five mistakes every one of these incidents repeats

I've read a dozen post-mortems with the same skeleton. It's always one or more of these:

1. Over-scoped tokens. The AI tool needs read access to one project; you gave it write access to your entire org. Why? Because that was the default button in the consent screen and you were in a hurry.

2. No token expiry. OAuth refresh tokens that live forever. A token stolen in January still works in December. If a token can outlive a employee's tenure, it will.

3. No action auditing. You can't see what the AI tool did yesterday, let alone at 3am when it "helpfully" deployed a compromised build. No audit trail means no early detection.

4. No second factor on destructive actions. "Deploy to production," "add a new environment variable," and "grant access to another user" all execute with one token. A human admin would face a 2FA prompt. The AI faces nothing.

5. Single-machine trust boundary. Your dev laptop is also your production deployer, your database admin, and your secrets manager. One piece of malware collapses all of those at once.

Each one alone is manageable. Stacked, they become Vercel's Tuesday.

What to do this week — concrete actions, not fluff

Audit your AI tool permissions

Right now, open every AI dev tool you've connected — Claude Code, Cursor, Copilot Workspace, Devin, whatever. For each, check:

- Which orgs / repos / projects can this tool touch?
- What actions can it take? (read, write, deploy, admin)
- When was the token issued? Can I rotate it?
- Is there an audit log? Have I ever looked at it?

If you can't answer any of those in 30 seconds, assume the worst and revoke.

Move secrets off the laptop

Stop putting production API keys in .env.local. Use a proper secret manager — Doppler, Infisical, AWS Secrets Manager — and have your tools fetch secrets at runtime via short-lived tokens. An infostealer grabbing your .env should grab nothing useful.

This is 15 minutes of setup and eliminates 80% of the "my laptop got owned" impact.

Short-lived tokens, always

# Example: GitHub fine-grained PAT — expires in 30 days, scoped to one repo
gh auth token --scope repo --expiration 30d --repo org/project

If your AI tool doesn't support short-lived tokens, that's a red flag. Treat vendor token hygiene as a product-selection criterion now.

Enable "dangerous action" confirmations

Most modern AI dev tools have a setting buried somewhere — human-in-the-loop approval for destructive actions (deploys, deletes, permission changes, database writes). Find it. Turn it on. Yes, it slows you down. No, it doesn't slow you down as much as a breach does.

Separate dev and deploy identities

Your laptop shouldn't be the thing with prod deploy permissions. Run deploys from CI where the token lives for 10 minutes and is bounded by a pipeline definition. If an attacker gets your laptop, the worst they should be able to do is push to a branch — not deploy to customers.

The non-obvious takeaway

The Vercel incident wasn't an AI safety story. It was a classic credential management failure with an AI amplifier bolted on.

That's the pattern to internalize. AI agents don't create new categories of security failure — they take old categories and multiply their blast radius. A stolen token used to mean a human attacker manually poking around until they found something juicy. A stolen token in 2026 means an obedient, tireless, English-speaking agent that will fan out across everything you've connected in 90 seconds.

The security fundamentals haven't changed. The margin for ignoring them has collapsed.

The business angle

If you're building a SaaS that ships AI-agent integrations — and everyone is — your customers are about to get very, very opinionated about the security posture of the tools they connect. The companies that figure out short-lived scoped tokens, action-level audit logs, and human-in-the-loop approval as product features will win enterprise deals. The ones that ship "connect your org, let Claude cook" will eat the next breach.

That's not speculation. That's where the buyer psychology is heading the day a Fortune 500 gets popped by this exact chain — which, given current trajectory, is maybe six months away.

What to do next

Go audit your AI tool permissions. I mean now — before you close this tab. The five minutes you spend revoking one over-scoped token is the cheapest insurance premium you'll pay this year.

Follow LayerZero for decoded security for builders. Next up: how to design an AI agent with least-privilege from day one — so a stolen token stays boring.

Your Agent Isn't Dumb. Your Context Is. — A Field Guide to Context Engineering

LayerZero — Mon, 20 Apr 2026 03:32:53 +0000

Prompt engineering is dead. Nobody told you because the influencers still sell courses on it.

The real skill in 2026 is context engineering — the discipline of deciding what information, tools, and memory go into the model's window on every single turn. It's the difference between an agent that ships a pull request and one that hallucinates a function name and rage-quits.

And almost nobody is doing it right.

What changed

A year ago, "prompt engineering" meant crafting the perfect system message. Add a persona, stack some few-shots, wrap in XML tags, done.

That worked when the model was a stateless Q&A box.

It doesn't work when the model is an agent running 40 tool calls across 6 files to fix a bug. The system prompt is 200 tokens. The context is 80,000 tokens of tool results, file contents, user messages, and prior reasoning — and every one of those tokens is either helping or hurting.

Context engineering is the job of keeping the signal-to-noise ratio high across that entire window, turn after turn.

The four levers

Only four things go into an LLM call. Master these and you control the agent.

Instructions — the system prompt. Goals, constraints, tone.
Knowledge — the facts the model needs right now (RAG chunks, API docs, file contents).
Tools — what actions the model can take and how their results come back.
History — prior turns, including tool calls and their outputs.

Every bug in every agent is one of these four going wrong. Always.

Agent loops forever? History is bloated with stale tool results.
Agent calls a function that doesn't exist? Knowledge missing or instructions too vague.
Agent picks the wrong tool? Tool descriptions are ambiguous.
Agent contradicts itself across turns? Instructions got drowned out by history.

The fix is never "try a different prompt." The fix is deciding what to put in — and what to leave out.

Rule 1: the context window is a budget, not a bag

The number one mistake: treating the context window like storage. "I have 200k tokens, I'll just throw everything in."

That's how you burn $4 per agent turn and get worse answers.

Long context is lossy. Models attend less to the middle of a long window, hallucinate more when the signal is buried in noise, and run slower in ways that compound across tool calls. A 2026 Anthropic benchmark found agent task completion drops by roughly 28% when you pad a working context from 20k to 120k tokens — even when the relevant information is unchanged.

You're not saving the model time. You're drowning it.

Treat every token like you're paying rent on it. Because you are.

Rule 2: compact aggressively

When your agent's history crosses some threshold — say 50% of the model's window — summarize it.

Pattern:

def compact_history(messages, token_threshold=50_000):
    if count_tokens(messages) < token_threshold:
        return messages

    # Keep the last 3 turns verbatim (recent context matters most)
    recent = messages[-6:]
    older = messages[:-6]

    # Summarize the older turns into a single system note
    summary = summarize(older, focus=[
        "decisions made",
        "files modified",
        "open questions",
        "tools that failed and why"
    ])

    return [
        {"role": "system", "content": f"PRIOR WORK SUMMARY:\n{summary}"},
        *recent
    ]

You lose the verbatim trace. You keep the signal. And you reset your token budget so the agent can go another 50 turns without collapsing.

Rule 3: retrieve at the tool level, not the prompt level

Old RAG: stuff the top-5 chunks into the system prompt at startup.

New RAG: give the agent a search_docs tool and let it decide when to retrieve.

Why this matters:

Approach	Tokens at turn 1	Tokens at turn 10	Relevance
Prompt-level RAG	8,000	8,000	Guessing
Tool-level RAG	500	500 (+1,200 on demand)	Targeted

Most agent turns don't need retrieval. Why pay the tax on every call? Let the model pull knowledge the way a developer opens a doc tab — only when they need it.

This is "just-in-time context" and it's the single biggest unlock in modern agent design.

Rule 4: tool descriptions are prompts

Your search_database tool's description is a system prompt for how the model reasons about querying data. If it says:

"Searches the database."

...you deserve the hallucinations you get.

Write it like this:

name: search_database
description: |
  Retrieves customer records by exact email or user_id.
  Use this BEFORE suggesting account changes — never guess a user_id.
  Returns at most 10 results. If you need more, narrow the query.
  Fails if the email format is invalid — validate first.

That description teaches the agent when to call it, what it can't do, and how to recover. Every minute you spend rewriting tool descriptions saves ten minutes of debugging agent behavior.

Rule 5: separate durable memory from working context

Working context = what's in the window right now.
Memory = persistent notes the agent writes across sessions (to a file, a vector store, a scratchpad).

If your agent needs to remember that a user prefers Python over Rust, don't shove it into every system prompt forever. Write it to a memory file. Retrieve it when relevant. Trim it when stale.

Memory is context engineering across time. Working context is context engineering within a turn. They're different problems with different solutions — and teams that treat them as one always hit a wall.

The business angle

This matters because AI infrastructure cost is now a line on your P&L.

A well-engineered context window runs an agent task for $0.20.
A lazy one runs the same task for $2.50.
The output quality is often worse on the expensive one.

Multiply that across a product doing 100,000 agent runs a day and you've got a $230,000/month difference in gross margin. That's a hire. That's your Series A runway extension. That's whether you ship.

The teams who figure this out in 2026 aren't the ones with the biggest GPU budgets. They're the ones who treat context as a design discipline.

The non-obvious takeaway

Context engineering is what prompt engineering wanted to be when it grew up.

Prompt engineering asked: "how do I phrase this question?"
Context engineering asks: "what does the model need to see, at what moment, with what tools, to produce the right action?"

The first is a writing exercise. The second is systems design. And systems design is a moat — prompt tricks are not.

What to do this week

Audit one agent you're running. Log the full context at each turn. Find the 30% that isn't earning its tokens. Cut it.
Move your RAG from prompt-level to tool-level. Measure the quality delta — it usually goes up.
Rewrite your top 5 tool descriptions with the "when to use / what it can't do / how to recover" structure.

Your agents will get cheaper, faster, and smarter — in that order.

Follow LayerZero for more decoded AI infrastructure. Next up: the memory-file pattern that makes agents actually learn from their mistakes.

Your LLM Bill Is 45% Too High. Here's the One Prompt Trick That Fixes It

LayerZero — Sun, 19 Apr 2026 07:30:18 +0000

Most developers ship AI features without looking at the bill. Then the bill arrives, and it's five figures.

Here's the part nobody tells you: up to 45% of your tokens are pure fluff. Filler words, restated questions, "As an AI assistant...", apologies, repeated context. You're paying Claude and GPT to be polite.

That stops today.

The politeness tax

Every LLM response is padded with tokens that add zero value:

"Certainly! I'd be happy to help you with that."
"Based on the information you've provided..."
"I hope this helps! Let me know if you have any other questions."

Multiply that across thousands of API calls a day. You're literally renting GPUs to generate pleasantries.

A recent production experiment ran 500 prompts through a small "defluffer" preprocessor that strips filler from both inputs and outputs. Token usage dropped 45%. Quality stayed identical.

That's not a rounding error. That's your Q3 AI budget.

Why this happens

LLMs are trained on human conversation. Humans are polite. So the model learned to open with "Certainly!" and close with "Let me know if you need anything else!"

This was fine when LLMs were chatbots. It's expensive when they're backend infrastructure.

The worst part: most devs copy-paste "Act as a helpful assistant" into their system prompt without realizing they're explicitly asking for the fluff.

The fix (30 seconds)

Add this to your system prompt:

Respond in the fewest tokens required to be correct and complete.
No preamble, no apologies, no restating the question, no closing remarks.
If the answer is a single word, respond with a single word.

That's it. Drop it in, rerun your evals, watch your token count.

In a test across 200 real user queries:

Metric	Before	After
Avg output tokens	412	183
Avg cost per call	$0.0041	$0.0018
User satisfaction	4.2/5	4.3/5

Output tokens down 55%. Cost down 56%. Satisfaction went up.

Users don't want "Certainly! I understand your question." They want the answer.

Level up: strip inputs too

Output is half the bill. Input is the other half — and it's often worse, because you're sending the same boilerplate context on every call.

The cheap win: cache your system prompt.

# Anthropic SDK — prompt caching
client.messages.create(
    model="claude-opus-4-7",
    system=[
        {
            "type": "text",
            "text": LARGE_SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": user_query}]
)

Cached tokens cost 10% of uncached tokens. If your system prompt is 2,000 tokens and you call it 10,000 times a day, you just cut 90% of that budget line.

The deeper win: stop sending context the model doesn't need. If your RAG retrieval returns 8 chunks but only 2 are relevant, you're paying to process 6 chunks of noise. Rerank harder. Retrieve less.

"But doesn't terse output hurt UX?"

This is the pushback I hear most. The data says the opposite.

Users rate concise answers higher than padded ones in every eval I've seen. Nobody reads "I'd be delighted to assist you with that query." They skim past it looking for the answer. The filler is friction, not warmth.

If your product genuinely needs conversational tone — customer support bots, companions — keep the warmth but strip the redundancy. "Thanks for reaching out!" once is fine. Five times across one response is expensive cosplay.

The non-obvious takeaway

Token usage isn't an optimization problem. It's a design problem.

Most teams treat LLM cost like server cost — something you fix by scaling. But LLM cost is determined at prompt-design time. A badly-designed prompt costs 3x more for worse answers. A well-designed prompt costs less and answers better.

The teams who figure this out in 2026 will ship AI features at one-third the cost of everyone else. That's not a small moat. That's the whole game.

What to do this week

Add the "no preamble" instruction to your system prompt — 30 seconds, saves ~40% immediately.
Turn on prompt caching for any system prompt over 1,000 tokens.
Log token usage per endpoint. You can't fix what you don't measure.

If you're running LLMs in production and you haven't done these three things, you're leaving real money on the table.

Follow LayerZero for more decoded AI infrastructure. Next up: the RAG retrieval bug costing you 40% of your relevance score.