Forem: Drew

AI Assistants as Development Partners

Drew — Sun, 15 Mar 2026 12:00:00 +0000

📚 Series Background: This is Part 1 of the AI Developer Workflows series. While the November 2025 post introduced Model Context Protocol as the infrastructure enabling AI-assisted development, this post focuses on practical daily workflows with measurable productivity gains.

After 6 months and 12,000+ AI-assisted code changes across 4 production projects, one thing is clear: the gap between "AI writes buggy code" and "AI 10x'd my productivity" isn't the model—it's the workflow.

This post shares 5 repeatable workflows with real metrics from DCYFR Labs: 60% time savings, 75% more features shipped, zero quality regression. You'll learn how to treat AI assistants as Junior+ teammates with specific strengths and hard limits, not autocomplete on steroids.

The Partnership Mindset

AI assistants aren't tools—they're Junior+ teammates with sharp pattern-matching skills and hard limits.

Over 6 months, I tracked feature estimates and actuals across 4 production projects at DCYFR Labs. "Before AI" baselines came from the prior 2 quarters on similar work. "With AI" numbers include pairing with GitHub Copilot and Claude on implementation, refactors, docs, and test generation while holding review standards constant. The 12,000+ changes represent Git commits where AI suggestions were accepted (tracked via commit messages and PR descriptions).

The Traditional Mental Model (Limited)

Developer → Types prompt → AI generates code → Copy/paste → Done

Problems with this approach:

Treats AI as a search engine
No context continuity
Quality varies wildly
Debugging takes longer than writing yourself

The Partnership Model (Effective in Practice)

Developer + AI:
  1. Developer: Define intent and constraints
  2. AI: Generate implementation with context
  3. Developer: Review, refine, teach
  4. AI: Learn patterns for next iteration
  Repeat (with growing shared context)

1. AI is Junior+ Level Excellent at boilerplate and patterns. Needs clear requirements. Requires review (like any junior dev). Gets better with feedback.

2. Context is Currency The more context, the better the output. MCP servers provide project state. Conversation history matters. Explicit constraints beat vague requests.

3. Iteration Over Perfection First output is rarely perfect (like first draft). Refine in conversation. Teach patterns for reuse. Build shared vocabulary.

Once you adopt this mindset, specific workflows become obvious...

The Five Daily Workflows

These are the workflows I use every single day. Each one has specific patterns that work—and specific pitfalls to avoid.

Workflow 1: Feature Implementation

When to Use:

Building new features from scratch
Implementing well-defined specifications
Following established patterns

The Pattern:

Task: Implement Redis-based view tracking for blog posts

Bad Approach (Tool Thinking):

"Write a view tracker with Redis"

Why this fails: Hides all constraints and existing patterns the AI needs.

Good Approach (Partner Thinking):

// 1. START WITH CONTEXT
/*
 * Feature: Blog post view counter
 * Requirements:
 * - Track unique views per post
 * - Use Redis (Upstash) - Edge-compatible via REST API
 * - Edge-compatible (Vercel Edge Runtime - no long-lived TCP)
 * - Deduplicates views by IP (24-hour window)
 * - Returns view count for display
 * - Must not block page render
 *
 * Existing patterns:
 * - /src/lib/redis.ts (Upstash connection)
 * - /src/app/api/*/route.ts (API structure)
 * - Error handling uses Sentry
 *
 * Show me the implementation.
 */

// 2. LET AI SCAFFOLD
// (AI generates initial implementation)

// 3. REVIEW & REFINE TOGETHER
// Developer: "This looks good but missing error handling"
// AI: (adds comprehensive error handling with Sentry)

// 4. TEST & ITERATE
// Developer: "The dedupe logic has an edge case with midnight UTC"
// AI: (fixes edge case)

Result: Production-ready code in 2 iterations vs. 6+ iterations with vague prompt.

Why Edge + Upstash REST matters: Vercel Edge Runtime doesn't support long-lived TCP connections. Upstash's REST API works around this, making Redis viable at the edge despite cold starts.

Security-critical code (always manually audit)

Important: AI bugs still happen. The win is catching them in review and tests before production.

Workflow 2: Refactoring & Cleanup

When to Use:

Improving code structure
Extracting patterns
Modernizing legacy code

The Pattern:

Before:

// BEFORE: Hardcoded spacing values
<div className="mb-8 mt-12 space-y-6">
  <h1 className="text-4xl font-bold">Title</h1>
  <p className="text-lg leading-relaxed">Content</p>
</div>

After:

// AFTER: Design token compliant
<div className={SPACING.section}>
  <h1 className={TYPOGRAPHY.h1.standard}>Title</h1>
  <p className={TYPOGRAPHY.body}>Content</p>
</div>

Prompt to AI:

"Refactor all hardcoded spacing in this component to use
design tokens from /src/lib/design-tokens.ts.

Pattern to follow:
- mb-8 → SPACING.section
- space-y-6 → SPACING.content
- mt-12 → SPACING.section

Show me the refactored code."

Real Impact:

Achieved 95%+ design token compliance across dcyfr-labs
AI handled ~200 component refactors in hours vs. days
Zero regressions (validated via automated tests)

Where It Fails:

Refactors requiring semantic understanding (use human judgment)
Cross-file dependencies without explicit context
Domain-specific naming conventions (AI uses generic names)

AI is excellent at mechanical refactoring with clear rules. Use it for consistency enforcement across large codebases.

Workflow 3: Debugging & Problem Solving

When to Use:

Tracking down bugs
Understanding unfamiliar code
Investigating production errors

The Pattern with MCP Integration:

// 1. AI QUERIES PRODUCTION ERRORS (via Sentry MCP)
> "Show me database errors from the last 24 hours"

// 2. AI GETS CONTEXT-RICH ERROR DETAILS
Issue DCYFR-LABS-123:
- Type: PrismaClientKnownRequestError
- Code: P2002 (Unique constraint violation)
- Location: /src/app/api/analytics/route.ts:45
- Frequency: 12 occurrences (last 6 hours)

// 3. AI ANALYZES CODE + ERROR TOGETHER
> "Analyze the analytics route code and explain why
   this unique constraint is failing"

// AI Response:
"The issue is a race condition in the view tracking logic.
When multiple requests hit the same post simultaneously,
they all check for existing view records before creating new ones.

Here's the fix: Use UPSERT instead of CREATE..."

// 4. DEVELOPER REVIEWS & APPLIES
// (Implement the fix, deploy, verify with Sentry MCP)

Real Example:

Production error: INP (Interaction to Next Paint) scoring poorly
AI + Sentry MCP identified: Heavy client-side font loading
Solution: Preload critical fonts in <head>
Result: INP improved from 350ms → 180ms (51% improvement)

Key Success Factor: AI has access to actual production data via MCP (Model Context Protocol)—the open standard that gives AI structured access to Sentry, your codebase, and production metrics. See my November 2025 post for setup details.

Where It Fails:

Bugs requiring deep domain knowledge (business logic edge cases)
Performance issues needing profiling tools (not just code inspection)
Intermittent/timing-dependent bugs (AI can't reproduce race conditions)

Workflow 4: Documentation & Explanation

When to Use:

Writing READMEs, API docs, comments
Explaining complex logic
Creating developer guides

The Pattern:

// EXISTING CODE (no docs)
export async function incrementViewCount(
  postSlug: string,
  fingerprint: string
): Promise<number> {
  // ... 50 lines of Redis logic ...
}

// PROMPT TO AI:
"Generate comprehensive JSDoc for this function.
Include: param descriptions, return type, error conditions,
usage example. Match the style in /src/lib/inngest/client.ts"

// AI GENERATES:
/**
 * Increments view count for a blog post with deduplication
 *
 * @param postSlug - URL slug of the blog post (e.g., "shipping-developer-portfolio")
 * @param fingerprint - Unique visitor identifier (IP hash + User-Agent)
 * @returns Total view count after increment
 * @throws {RedisError} If connection to Upstash fails
 * @throws {ValidationError} If postSlug is empty or invalid
 *
 * @example
 * ```

typescript
 * const views = await incrementViewCount('my-post', 'abc123');
 * console.log(`Total views: ${views}`);
 *

@remarks
Views are deduplicated using a 24-hour window. The same
fingerprint will only increment the counter once per day. */




**Time Savings:**

- Documentation that would take 1-2 hours → 10-15 minutes
- Consistency across all docs (AI follows style guide)
- Updates stay in sync with code changes

**Where It Fails:**

- Architectural decision records (ADRs) requiring context/tradeoffs
- User-facing docs needing empathy for beginner struggles
- Changelog entries (AI doesn't understand user impact)

* * *

### Workflow 5: Test Generation

**When to Use:**

- Writing unit tests
- Creating E2E test scenarios
- Generating test fixtures

**Prompt to AI:**



```plaintext
"Generate comprehensive Vitest unit tests for this
incrementViewCount function. Cover:

1. Happy path (new visitor)
2. Deduplication (same visitor within 24h)
3. Error handling (Redis failure)
4. Edge cases (invalid slug, empty fingerprint)

Use the test style from /src/ __tests__ /lib/redis.test.ts"

AI Generates:

import { describe, it, expect, beforeEach, vi } from 'vitest';
import { incrementViewCount } from '@/lib/analytics';
import { redis } from '@/lib/redis';

vi.mock('@/lib/redis');

describe('incrementViewCount', () => {
  beforeEach(() => {
    vi.clearAllMocks();
  });

  it('increments view count for new visitor', async () => {
    vi.mocked(redis.get).mockResolvedValue(null);
    vi.mocked(redis.incr).mockResolvedValue(1);

    const views = await incrementViewCount('test-post', 'abc123');

    expect(views).toBe(1);
    expect(redis.incr).toHaveBeenCalledWith('views:test-post');
  });

  it('does not increment for duplicate visitor within 24h', async () => {
    vi.mocked(redis.get).mockResolvedValue('abc123');
    vi.mocked(redis.get).mockResolvedValue('5');

    const views = await incrementViewCount('test-post', 'abc123');

    expect(views).toBe(5);
    expect(redis.incr).not.toHaveBeenCalled();
  });

  // ... 6 more test cases covering edge cases
});

Real Stats:

Test coverage maintained at 99%+ pass rate (measured across 1,000+ test runs in CI)
AI generates 80% of boilerplate test setup
Developer focuses on edge cases and assertions
Time savings: 60-70% on test writing

Where It Fails:

Integration tests requiring real service setup (AI hallucinates mocks)
Edge cases unique to your domain (AI uses generic test cases)
Flaky test debugging (AI can't see CI timing issues)

Always review AI-generated tests. They often miss subtle edge cases or make incorrect assumptions about behavior.

Where AI Assistants Fail

These workflows are powerful—but there are five failure modes that will absolutely bite you if you don't actively guard against them.

Failure Mode 1: Security Vulnerabilities

AI assistants often suggest code with security issues:

Before:

// AI MIGHT SUGGEST (DON'T USE):
const userId = req.query.id; // No validation
const user = await db.query(`SELECT * FROM users WHERE id = ${userId}`);
// ^ SQL injection vulnerability

After:

// CORRECT APPROACH:
const userId = z.string().uuid().parse(req.query.id); // Validate first
const user = await db.user.findUnique({ where: { id: userId } });
// ^ Parameterized, type-safe

Rule: Always audit AI-generated code for:

Input validation (never trust user input)
SQL injection risks (use ORMs with parameterization)
XSS vulnerabilities (sanitize HTML output)
Authentication/authorization checks
Rate limiting on API routes
Hallucinated validators: AI may suggest secure-sounding helpers that don't exist

If you're in regulated domains (healthcare, finance, critical infrastructure), add a formal review gate for all AI-assisted changes.

Failure Mode 2: Performance Anti-Patterns

AI often suggests the simplest solution, not the most performant:

Before:

// AI MIGHT SUGGEST:
const posts = await getAllPosts(); // Fetches 1000+ posts
const featuredPosts = posts.filter(p => p.featured); // Memory filter

After:

// BETTER:
const featuredPosts = await db.post.findMany({
  where: { featured: true },
  take: 10
}); // Database-level filtering

Rule: Question AI on:

Database query efficiency (N+1 problems)
Unnecessary data fetching
Missing pagination/limits
Client-side vs. server-side rendering choices

Pro tip: Ask the AI to propose a more efficient alternative and explain tradeoffs. Don't accept the first working draft—push for optimization.

Failure Mode 3: Over-Engineering

AI loves to add abstractions:

AI Might Suggest (over-engineered):

interface ViewCounterStrategy {
  increment(key: string): Promise<number>;
}

class RedisViewCounterStrategy implements ViewCounterStrategy {
  async increment(key: string): Promise<number> { /* ... */ }
}

class ViewCounterFactory {
  createStrategy(type: 'redis' | 'memory'): ViewCounterStrategy { /* ... */ }
}

class ViewCounterService {
  constructor(private strategy: ViewCounterStrategy) {}
  async incrementViews(postSlug: string): Promise<number> { /* ... */ }
}

Actually Needed (YAGNI):

export async function incrementViews(postSlug: string): Promise<number> {
  return await redis.incr(`views:${postSlug}`);
}

What happened: This is classic "enterprise Java brain" for a simple blog counter—strategies, factories, services... for incrementing a number. Abstractions become appropriate when you have multiple storage backends or cross-service shared analytics. Not before.

Rule: Apply YAGNI (You Aren't Gonna Need It). Start simple, refactor when complexity is justified.

Failure Mode 4: Hallucinated APIs

AI sometimes confidently suggests APIs that don't exist:

// AI MIGHT SUGGEST (doesn't exist):
await redis.atomicIncrementWithDedup(key, fingerprint, ttl);
// ^ This is not a real Redis/Upstash method

// ACTUALLY NEEDED:
const existing = await redis.get(`dedup:${fingerprint}`);
if (!existing) {
  await redis.set(`dedup:${fingerprint}`, '1', { ex: 86400 });
  await redis.incr(`views:${postSlug}`);
}

Rule: Verify all API calls against official documentation. Use Context7 MCP for up-to-date docs.

Failure Mode 5: Missing Edge Cases

AI thinks in happy paths:

// AI GENERATES:
const date = new Date(publishedAt);
const formatted = date.toLocaleDateString('en-US');

// MISSING EDGE CASE: What if publishedAt is null/undefined/invalid?

// PRODUCTION-READY:
const date = publishedAt ? new Date(publishedAt) : null;
const formatted = date?.toLocaleDateString('en-US') ?? 'Draft';

Rule: Always ask "What breaks this?" for AI-generated code.

Every failure mode listed here has bitten me in production. Security vulnerabilities, performance regressions, over-engineering—they're not hypothetical. The difference between "AI broke production" and "AI 10x'd velocity" is whether you actively guard against these patterns.

Measuring AI Assistant Impact

"Is AI actually helping?" Here's how to measure it objectively.

Metric 1: Time-to-Feature

Track implementation time before and after AI adoption.

DCYFR Labs Data (6-month period):

Feature Type	Before AI	With AI	Savings
Blog Post Implementation	6h	3h	50%
API Route (CRUD)	4h	1.5h	62%
Component Refactoring	8h	2h	75%
Test Suite Creation	3h	1h	67%

Average time savings: 60% across all feature work.

How to Track:

# Add time estimates to GitHub issues
- [] Implement Redis view tracking (EST: 3h with AI)
- [] Write test suite (EST: 1h with AI)

# Update with actuals when complete
- [x] Implement Redis view tracking (ACTUAL: 2.5h)
- [x] Write test suite (ACTUAL: 45m)

Metric 2: Code Quality (Test Pass Rate)

Does AI code introduce more bugs?

DCYFR Labs Data:

Test pass rate before AI: 98.5% (measured over 800 CI runs in Q2-Q3 2025)
Test pass rate with AI: 99.1% (measured over 1,200 CI runs in Q4 2025-Q1 2026)
Conclusion: No quality regression (possibly slight improvement due to more comprehensive test generation)

Note: This measures CI success rate on the main branch. Individual features still had bugs—they were just caught in review and tests before merging.

Metric 3: Developer Velocity (Features Shipped)

More time → More features?

DCYFR Labs Data (Q4 2025 vs Q3 2025):

Q3 2025 (Pre-AI): 8 features shipped
Q4 2025 (With AI): 14 features shipped
Increase: 75% more features in same calendar time
Scope: Comparable complexity (mix of small/medium/large features in both quarters)

Features shipped with AI assistance:

RIVET component framework (8 components)
Redis-based analytics system
Blog archive with tag filtering
Accessibility improvements (WCAG 2.1 AA)
SEO schema markup
Print-friendly styling
Diagram/math rendering
...and 7 more

Metric 4: Learning Curve (Time to Proficiency)

How quickly can you learn new technologies?

Real Example: Learning Inngest

Without AI:

Read docs: 3 hours
Build first function: 2 hours
Debug issues: 4 hours
Total: ~9 hours to "hello world"

With AI + Context7 MCP:

Ask AI to explain: 30 min
Build with AI assistance: 1 hour
AI debugs common issues: 30 min
Total: ~2 hours to production-ready implementation

Speed multiplier: 4.5x for learning new tools.

The real value isn't just "AI writes code faster." It's:

Spend less time on boilerplate (60% time savings)
Maintain quality (no test regression)
Ship more features (75% velocity increase)
Learn faster (4-5x speed on new tech)

Result: More time for the work that actually matters—architecture, design, user experience, strategy.

Setting Up Your AI Workflow

Ready to implement these patterns? Here's the exact setup I use.

Step 1: Choose Your Tools

Primary AI Assistant:

GitHub Copilot (in VS Code) - Inline suggestions, chat
Claude Desktop (with MCP) - Complex reasoning, architecture
Cursor (alternative) - Built-in AI-native editor

My Setup:

Copilot for 80% of daily coding
Claude for architecture decisions and complex refactoring
Both connected via MCP for project context

Step 2: Configure MCP Servers

Essential MCP servers for development:

// .vscode/mcp.json (or claude_desktop_config.json)
{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "context7-mcp"],
      "env": {
        "CONTEXT7_API_KEY": "${CONTEXT7_API_KEY}"
      }
    },
    "sentry": {
      "command": "npx",
      "args": ["-y", "@sentry/mcp-server"],
      "env": {
        "SENTRY_AUTH_TOKEN": "${SENTRY_AUTH_TOKEN}",
        "SENTRY_ORG": "dcyfr",
        "SENTRY_PROJECT": "dcyfr-labs"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

What each provides:

Memory: Maintains context across conversations
Context7: Up-to-date library documentation
Sentry: Production error access
GitHub: Repository operations and PR context

Step 3: Create Project Instructions

Tell AI about your codebase patterns:

<!-- .github/copilot-instructions.md -->

# Project: dcyfr-labs

## Architecture Patterns

- **Design Tokens:** Always use /src/lib/design-tokens.ts (never hardcoded values)
- **API Routes:** Follow validate→queue→respond pattern
- **Components:** Server Components by default, 'use client' only when needed
- **Testing:** Vitest for unit tests, Playwright for E2E

## Code Style

- TypeScript strict mode
- Functional components with TypeScript interfaces
- Explicit return types on functions
- Comprehensive error handling with Sentry

## Quality Gates

- All API routes must have input validation (Zod)
- All new features require tests (min 95% coverage)
- Design token compliance required
- Security audit required for auth/payment code

Step 4: Practice Prompt Patterns

Good Prompt Structure:

TASK: [What you want]

REQUIREMENTS:
- [Specific constraint 1]
- [Specific constraint 2]

CONTEXT:
- Existing code: [file/location]
- Pattern to follow: [example]
- Technologies: [stack]

DELIVERABLE:
- [Exact output format expected]

Result: First-try production-ready code instead of 6 iterations. Clear requirements + context = better output.

Real-World Implementation: RIVET Framework Case Study

Let's walk through an actual implementation from dcyfr-labs: the RIVET component framework.

The Challenge:

Blog posts were static Markdown. Wanted to add interactive components (collapsible sections, tooltips, diagrams) without:

Breaking existing content
Sacrificing performance
Losing SEO value

The AI-Assisted Workflow

Phase 1: Architecture Design (1 hour with Claude)

ME: "I want to add interactive components to MDX blog posts.
Requirements:
- Server Components by default (SEO + performance)
- Client components only when needed (interactivity)
- Backward compatible with existing posts
- Type-safe component API

Show me the architecture."

CLAUDE: [Generates architecture proposal]
- MDX components map in /src/components/mdx/index.ts
- Server components for static elements
- Client components for interactive elements
- TypeScript interfaces for props

ME: "Good, but how do we handle the server/client boundary?"

CLAUDE: [Refines with specific pattern]

Result: Clean architecture in 1 hour vs. 6+ hours of research/trial.

Phase 2: Component Implementation (4 hours with Copilot)

Used Workflow 1 (Feature Implementation) for each component:

// 1. Developer sets context
/* Component: CollapsibleSection
 * Type: Client component (needs useState)
 * Props: title, children, defaultExpanded
 * Style: Uses design tokens from SPACING
 * Pattern: Similar to Accordion from shadcn/ui
 */

// 2. Copilot scaffolds
// (AI generates complete component with design tokens)

// 3. Developer refines
// "Add ARIA attributes for accessibility"
// "Use framer-motion for smooth transitions"

// 4. Test & validate
// npm run test:run
// npm run validate:design-tokens

8 components built in 4 hours (would have taken 16+ hours manually).

Phase 3: Rollout (2 hours with AI assistance)

AI helped:

Generate RIVET rollout checklist
Scan blog posts for enhancement opportunities
Generate migration guide for each post

The Results

Total Time:

With AI: 7 hours (architecture + implementation + rollout)
Estimated without AI: 30+ hours
Time savings: 77%

Quality:

97 passing tests (AI-generated test scaffolding)
95%+ design token compliance (AI refactoring)
Zero production bugs (AI + manual review)

The Key Insight:

AI didn't just "write code faster." It:

Accelerated architecture decisions (Claude reasoning)
Automated boilerplate (Copilot scaffolding)
Generated comprehensive tests (quality maintained)
Enabled shipping faster (7 hours vs. 30+)

Read the full story in my RIVET Framework post.

The Future: Where This Is Heading

AI assistants will get better. Here's what's coming—and how to prepare.

Trend 1: From Autocomplete to Autonomous Agents

Today:

Developer → Prompts AI → Reviews output → Applies code

Near Future (2026-2027):

Developer → Defines goal → AI plans + executes + tests → Developer approves

Example:

"Ship Redis analytics for blog posts to production. Requirements: edge-compatible, test coverage >95%, design token compliant. Go."

AI will:

Design the architecture
Implement the feature
Write comprehensive tests
Run validation checks
Create PR with detailed explanation
Wait for human approval

Key: Humans stay in control (approve/reject), but AI handles execution.

Trend 2: Multi-Agent Collaboration

Near Future: Specialized agents working together

Architect Agent: Designs system
Implementation Agent: Writes code
Test Agent: Generates tests
Security Agent: Audits for vulnerabilities
Performance Agent: Optimizes hot paths

All coordinated by orchestration layer.

Trend 3: Real-Time Production Context

Future AI will have access to:

Live production metrics (Vercel Analytics, Sentry)
User behavior data (heatmaps, session recordings)
Performance traces (database queries, API latency)
A/B test results (what works, what doesn't)

Example:

AI: "I notice the blog listing page has high bounce rate (85%). Analyzing... Users are leaving because load time is 3.2s. Root cause: 50 blog posts rendered without pagination. Proposed fix: Add pagination (10 posts/page) + infinite scroll. Estimated impact: Load time → 0.8s, bounce rate → 40%. Should I implement?"

How to Prepare

Build MCP infrastructure now - Get comfortable with AI having project context
Establish quality gates - AI velocity needs guard rails (tests, security, review)
Document patterns clearly - AI learns from your codebase patterns
Practice delegation - Treat AI like a junior developer (clear requirements, thoughtful review)
Keep humans in the loop - AI proposes, humans decide

The Goal:

Not to replace developers. To free developers from boilerplate so they can focus on:

Architecture (what should we build?)
User experience (how should it work?)
Strategy (what problems are we solving?)
Judgment (what trade-offs should we make?)

AI handles the "how" (implementation). Developers own the "what" and "why" (strategy).

Getting Started Monday

Ready to transform your workflow? Here's your 3-step quick-start:

Step 1: Pick One Workflow (This Week)

Start with Workflow 1: Feature Implementation. Choose a small feature (2-4 hours of work) and run it end-to-end:

Write context-rich requirements (constraints, existing patterns, tech stack)
Let AI scaffold the implementation
Review and refine together
Test thoroughly
Track your time vs. historical average

Step 2: Instrument One Metric (Week 2)

Measure what matters:

Time tracking: GitHub issue estimates ("EST: 3h with AI") vs. actuals
Quality: Test pass rate on AI-assisted features
Velocity: Features shipped this month vs. last quarter

Pick one metric. Track it for 2 weeks. Compare to baseline.

Step 3: Expand Gradually (Weeks 3-4)

Once Workflow 1 feels natural, add:

Workflow 5: Test generation (pair it with feature work)
Workflow 2: Refactoring (perfect for cleanup sprints)
Workflow 3: Debugging (when production issues arise)

Don't try all 5 workflows simultaneously. Master one, measure impact, then expand.

Conclusion & Key Takeaways

AI assistants are transformative— if you use them as Junior+ partners, not autocomplete.

The 5 Workflows

Feature Implementation - Clear requirements + context → Production code
Refactoring - Mechanical changes at scale (design tokens, patterns)
Debugging - MCP-powered production context access
Documentation - Comprehensive docs in minutes
Testing - Boilerplate test generation (human focuses on edge cases)

The 5 Failure Modes

Security vulnerabilities (always audit)
Performance anti-patterns (question efficiency)
Over-engineering (apply YAGNI)
Hallucinated APIs (verify against docs)
Missing edge cases (ask "what breaks this?")

The Measurable Impact

60% time savings on feature implementation
75% more features shipped per quarter
No quality regression (99%+ test pass rate maintained)
4-5x faster learning on new technologies

The Setup

MCP servers (Memory, Context7, Sentry, GitHub)
Project instructions (.github/copilot-instructions.md)
Consistent patterns (AI learns from repetition)
Focused work (small PRs, clear requirements)

The Future

Autonomous agents (plan + execute + test)
Multi-agent collaboration (specialized skills)
Real-time production context (data-driven suggestions)
Humans stay in control (approve/reject decisions)

Your Monday Action:

Install GitHub Copilot or Claude Desktop
Pick one small feature to ship this week
Follow Workflow 1 pattern (context → scaffold → refine → test)
Track your time
Report back—what worked? What didn't?

Next in this series: "Autonomous AI Agents: From Assistants to Automation" (Part 2, May 2026) - Move beyond assistants to AI agents that run scheduled jobs, monitor production, and keep your backlog clean without human intervention.

Questions or experiences with AI assistants? Share in the comments below. I'd love to hear what workflows are working for you—or where you're getting stuck.

Want more?

Follow for Part 2: Autonomous AI Agents (May 2026)
Star the dcyfr-labs repo to see the code behind these workflows
Read the MCP setup guide for full context on how AI accesses production data

Modernizing Blog Content with RIVET: A Component-Driven Enhancement Framework

Drew — Thu, 05 Feb 2026 12:00:00 +0000

📚 Series Background: This is Part 4 of the Portfolio series. After building the infrastructure and backend systems, here we explore how to modernize blog content itself using a systematic component-driven framework for improved engagement and user experience.

The Problem: Static Content in a Dynamic World

Your blog posts are beautifully written. Code-highlighted. SEO-optimized. And completely static.

Readers land on your 3,000-word security analysis. They see a wall of text. They bounce within seconds. Average time on page: 47 seconds.

Meanwhile, YouTube tutorials on the same topic get 8-minute average watch times. Not because video is inherently better—because it's interactive. Progress bars. Chapters. Annotations. Engagement hooks every 30 seconds.

Static blog posts compete with interactive media (video, podcasts, courses) using 90s HTML formatting. We're bringing knives to a gunfight.

I hit this wall with my OWASP Top 10 for Agentic AI post. 6,800 words. 10 risks. Zero interactivity. Readers loved it in theory, but analytics showed:

80% bounced before reaching (Risk #3)
Average scroll depth: 32%
Social shares: Post-level only (no section targeting)
Zero engagement from Executive readers (too technical)
Developers skipped theory sections looking for code

The content was solid. The format was broken.

Short answer: Text still dominates for technical content.

The data:

Developers reference text documentation 3.2× more frequently than video tutorials for technical content (Stack Overflow 2025 Survey¹)
Text is searchable, scannable, copy-pasteable
Code examples in video require pausing/rewinding
Accessibility: Screen readers work perfectly with text

The real solution: Make text as engaging as video using interactive components.

The Solution: The RIVET Framework

RIVET: Reader Interactive Visual Engagement Tiered

A systematic framework for enhancing blog posts with 5 categories of engagement elements.

The Five Pillars

The Component Library

I built 7 production-grade interactive elements across 2 priority tiers :

P0: Critical Foundation (3 components)

Component	Purpose	Usage
ReadingProgressBar	Show scroll progress	1 per post
TLDRSummary	Executive summary at top	1 per post
KeyTakeaway	Highlight key insights	4-6 per post

P1: Enhanced Engagement (4 components)

Component	Purpose	Usage
CollapsibleSection	Hide optional depth	2-5 per post
GlossaryTooltip	Define technical terms inline	8-28 per post
SectionShare	Share individual sections	3-5 per post
RoleBasedCTA	Audience-specific calls-to-action	3 per post

Focus on meaningful tests: user interactions, accessibility, props validation. Skip brittle snapshot tests and complex browser API mocks. Achieve high coverage with targeted, effective tests.

Real Implementation

I rolled out RIVET to 4 top tier blog posts (security-focused, high engagement potential).

Deployment Results

Post	P0 Components	P1 Components
OWASP Top 10 for Agentic AI	33	71
CVE-2025-55182 (React2Shell)	6	23
Node.js Jan 2026 Security Release	1	20
Hardening a Developer Portfolio	2	25

Total: 181 component instances across 4 posts

Coverage: 31% of blog posts enhanced with RIVET

Average: 45 components per post

Breakdown:

ReadingProgressBar: 1 (fixed)
TLDRSummary: 1 (fixed)
KeyTakeaway: 4-6 (every 400-500 words)
GlossaryTooltip: 8-28 (depends on technical density)
RoleBasedCTA: 3 (Executive/Developer/Security)
SectionShare: 3-5 (major sections)
CollapsibleSection: 2-5 (optional depth)

Rule of thumb: 1 interactive element every ~150 words keeps readers engaged without overwhelming.

Code Example: KeyTakeaway Component

Here's the actual production code for the KeyTakeaway component:

'use client';

import * as React from 'react';
import { Lightbulb, Shield, AlertTriangle, Sparkles } from 'lucide-react';
import { cn } from '@/lib/utils';
import { SPACING, BORDERS } from '@/lib/design-tokens';

const variants = {
  insight: {
    icon: Lightbulb,
    borderColor: 'border-l-primary',
    bgColor: 'bg-primary/5',
    iconColor: 'text-primary',
  },
  security: {
    icon: Shield,
    borderColor: 'border-l-blue-500',
    bgColor: 'bg-blue-50 dark:bg-blue-950/20',
    iconColor: 'text-blue-600 dark:text-blue-400',
  },
  warning: {
    icon: AlertTriangle,
    borderColor: 'border-l-amber-500',
    bgColor: 'bg-amber-50 dark:bg-amber-950/20',
    iconColor: 'text-amber-600 dark:text-amber-400',
  },
  tip: {
    icon: Sparkles,
    borderColor: 'border-l-purple-500',
    bgColor: 'bg-purple-50 dark:bg-purple-950/20',
    iconColor: 'text-purple-600 dark:text-purple-400',
  },
};

export function KeyTakeaway({ children, variant = 'insight', title, className }: KeyTakeawayProps) {
  const { icon: Icon, borderColor, bgColor, iconColor } = variants[variant];

  return (
    <div className={cn('my-6 border-l-4 p-6 rounded-r-lg', borderColor, bgColor, className)}>
      <div className="flex gap-4">
        <div className="shrink-0">

        </div>
        <div className="flex-1">
          {title && <h4 className="font-semibold mb-2">{title}</h4>}
          <div className="text-sm leading-relaxed">{children}</div>
        </div>
      </div>
    </div>
  );
}

Key design decisions:

Design tokens: Uses SPACING, BORDERS from central token system (no hardcoded values)
Variants: 4 semantic variants (insight/security/warning/tip) with distinct colors
Icons: lucide-react icons (no emojis in production)
Accessibility: Semantic HTML, proper color contrast, screen reader friendly
Dark mode: All variants work in light/dark themes

Usage in MDX

Using components in blog posts is dead simple:


  Most developers think CSP headers alone secure their site. They don't. You need defense-in-depth:
  CSP + SRI + HTTPS + input validation.
</KeyTakeaway>

<abbr title="Content Security Policy - HTTP header that controls which resources browsers can load" class="glossary-term rss-glossary">
  CSP
</abbr>

  Detailed technical content that beginners can skip...
</CollapsibleSection>

No imports needed (globally available in MDX). No wrapper components. Just use them.

Engagement Results: Early Data

Two weeks post-deployment across 4 production blog posts. Early metrics validate the framework's core hypothesis: interactive components drive measurable engagement improvements.

Before RIVET

Average time on page: 2:14
Scroll depth: 38%
Bounce rate: 68%
Social shares: 100% post-level

After RIVET

Average time on page: 3:47 (+69% )
Scroll depth: 61% (+60% )
Bounce rate: 52% (-24% )
Social shares: 73% post-level, 27% section-level, new capability

Performance Implications

The trade-off: 181 interactive elements across 4 posts = measurably more JavaScript.

Impact analysis:

Bundle size increase: +47KB gzipped (framer-motion + lucide-react icons)
Lighthouse Performance: 94/100 → 91/100 (3-point drop, still excellent)
Largest Contentful Paint: 1.2s → 1.4s (+200ms, within threshold)
Cumulative Layout Shift: 0.02 (no change - components render server-side)
First Input Delay: <100ms (client-side interactivity doesn't block initial load)

Mitigation strategies:

Tree-shaking : Only import used icons from lucide-react
Code splitting : Components load on-demand via dynamic imports
Server-side rendering : Initial HTML renders immediately, hydration adds interactivity
Lazy loading : Below-fold components defer until scroll proximity

Verdict: Performance cost is measurable but acceptable. +69% engagement gain >> +200ms LCP trade-off.

Component-Specific Metrics

Component	Total Uses	Avg Interactions/Post	Top Insight
GlossaryTooltip	57	18 click	Readers click 3-5 tooltips per visit
CollapsibleSection	14	4 expansions	78% expand at least one section
RoleBasedCTA	12	2.1 clicks	Executive CTAs get 3x more clicks
SectionShare	16	1.3 shares	"Key Takeaway" sections shared most

Vercel Analytics:

import { track } from '@vercel/analytics';

// GlossaryTooltip
track('glossary_tooltip_click', {
  term: 'CSP',
  post_slug: 'owasp-top-10-agentic-ai',
});

// CollapsibleSection
track('collapsible_section_toggle', {
  section_id: 'advanced-csp',
  action: 'expand', // or 'collapse'
});

// RoleBasedCTA
track('role_cta_click', {
  role: 'developer',
  cta_text: 'Production CSP Generator',
});

Privacy-First Benefits²:

No cookies, no personal data collection
GDPR/CCPA compliant out of the box
Aggregated insights only (no individual user tracking)
LocalStorage for UI state (tooltips seen, section preferences)
Zero impact on Core Web Vitals

The Tiered Rollout Strategy

I didn't enhance all 13 blog posts at once. That would be 40+ hours of work with unknown ROI.

Instead: Tiered rollout based on traffic potential.

Tier 1: High-Impact Posts

Security-focused (high expertise signal)
2,500+ words (needs interactivity)
Technical audience (will engage with components)

Time investment: 2-3 hours per post Total: 10 hours for 181 components

Tier 2: Medium-Impact Posts

Development-focused (broad audience)
1,500-2,500 words
Good traffic potential

Strategy: Partial enhancement (P0 only, selective P1)

Tier 3: Long Tail

Older posts
Lower traffic
Demo/tutorial content

Strategy: GlossaryTooltip only (minimal effort, still valuable)

Don't enhance your entire blog in one sprint. Pick 3-4 high-potential posts, deploy RIVET, measure engagement for 2-4 weeks, then decide on broader rollout.

Technical Implementation Details

Component Architecture

src/components/blog/rivet/
|-- navigation/
| |-- reading-progress-bar.tsx (P0)
| +-- index.ts
|-- visual/
| |-- key-takeaway.tsx (P0)
| |-- tldr-summary.tsx (P0)
| +-- index.ts
|-- interactive/
| |-- glossary-tooltip.tsx (P1)
| |-- collapsible-section.tsx (P1)
| +-- index.ts
|-- engagement/
| |-- role-based-cta.tsx (P1)
| |-- section-share.tsx (P1)
| +-- index.ts
+-- index.ts (barrel export)

All components:

TypeScript strict mode
100% design token compliance (no hardcoded spacing/colors)
Responsive (mobile-first)
Dark mode support
Accessibility (WCAG 2.1 AA³)
Client-side only (marked "use client")

Design Token Enforcement

Every component uses centralized design tokens:

import { SPACING, BORDERS, TYPOGRAPHY, SHADOWS } from "@/lib/design-tokens";

// CORRECT
<div className={`gap-${SPACING.content}`}>
  <h2 className={TYPOGRAPHY.h2.standard}>Title</h2>
</div>

// WRONG (would be rejected in code review)
<div className="gap-8">
  <h2 className="text-3xl font-semibold">Title</h2>
</div>

Why this matters:

Consistent spacing across all components
Easy theme updates (change token, update everywhere)
Design system as single source of truth

Test Coverage Philosophy

What we test:

Component rendering (all variants)
User interactions (clicks, expansions, hovers)
Props validation (TypeScript + runtime)
Accessibility (ARIA labels, keyboard nav)
LocalStorage persistence
Analytics event firing

What we don't test:

Pure CSS rendering (snapshot tests are brittle)
Browser API quirks (clipboard, scrolling)
Third-party library internals

Result: 97% coverage on meaningful tests.

The 7 skipped tests:

All in section-share.test.tsx
All related to navigator.clipboard.writeText()
Clipboard API is async and timing-dependent in jsdom

What we do instead:

Test that the "Copy" button renders
Test that onClick handler fires
Test that success state updates
Manual browser testing for actual clipboard functionality

Philosophy: Don't waste hours making jsdom mimic browser APIs perfectly. Test in the actual environment (browser).

Lessons Learned: What Worked, What Didn't

What Worked

GlossaryTooltip is MVP Readers engage with every single post that has tooltips. Average 18 clicks per visit. Low effort (1-2 min per term), high value.
TLDRSummary hooks Executives Executive readers (identified by User-Agent patterns) spend 3.2x longer on posts with TLDR vs. without. They want the summary upfront.
RoleBasedCTA segments audience Executive CTAs: "Schedule 15-min demo" Developer CTAs: "Clone the repo" Security CTAs: "Run the audit script" Each role clicks their CTA 3x more than generic CTAs.
SectionShare drives niche sharing 27% of shares are section-level. LinkedIn loves "just this section on zero-trust" more than "entire 6,000-word post."

What Didn't Work

CVE-specific components were overkill Built SeverityLabel, CVELink, CVETracker for security posts. Zero usage across 4 posts. Deleted after 1 week. Lesson: Don't build components for hypothetical future use.
Too many CollapsibleSections confuses readers First draft of OWASP post had 12 collapsibles. Readers didn't know what to expand. Reduced to 4-5 max per post.
KeyTakeaway every 300 words is too dense Initial guideline was "1 per section." Felt spammy. New rule: 1 every 400-500 words or 4-6 per post max.

Roadmap: What's Next for RIVET

Advanced Features

Component	Purpose	Effort	Priority
SeriesNavigation	Series-specific prev/next navigation	4h	High
RiskMatrix	SVG visualization for risk scoring	8h	Medium
DownloadableAsset	Lead capture + Asset delivery	6h	Medium
FAQSchema	FAQ accordion with schema.org markup	3h	Low
NewsletterSignup	Inline email capture	4h	Low
TabInterface	Multi-tab content switcher	5h	Low

Total: ~30 hours additional development

Tier 2 Rollout

Select 3-4 Development-focused posts
Apply P0 + selective P1 components
measure engagement lift vs. Tier 1

Analytics Dashboard

Build internal dashboard tracking:

Component usage across all posts
Engagement metrics per component type
ROI: Time invested vs. engagement gain
A/B testing: Enhanced vs. baseline posts

Conclusion: Static is Dead, Long Live Interactive

The core insight: Technical blog posts compete with video, podcasts, and interactive courses. Static HTML from 2005 isn't enough anymore.

The solution: RIVET framework - systematic enhancement with 8 production components across 5 pillars.

The results: +69% time on page, +60% scroll depth, -24% bounce rate (early data, 2 weeks post-rollout).

The investment: 10 hours to build P0+P1 components, 2-3 hours per post to deploy 181 components across 4 posts, 97% test coverage.

The next step: Roll out to 3-4 more posts in Q1 2026, measure engagement lift, iterate based on data.

Don't wait for perfect. Pick your top 3 blog posts. Add a TLDRSummary and 5-10 GlossaryTooltips. Measure engagement after 2 weeks. Scale from there.

Your readers want interactivity. Your content deserves better than static HTML. RIVET is the framework that bridges the gap.

Now go build something interactive.

Resources

Phase 1: Setup (2-3 hours)

Install dependencies: framer-motion, lucide-react
Create /components/blog/rivet/ directory structure
Set up design token system (SPACING, BORDERS, TYPOGRAPHY)
Configure barrel exports (index.ts at each level)
Set up test infrastructure (Vitest + React Testing Library)

Phase 2: Build P0 Components (6-8 hours)

ReadingProgressBar (3h)

Component implementation
Tests (18 tests)
Dark mode support
Accessibility audit

KeyTakeaway (3h)

4 variant styles (insight/security/warning/tip)
Tests (25 tests)
Icon integration (lucide-react)

TLDRSummary (4h)

Three-section layout
Jump link functionality
Tests (28 tests)

Phase 3: Build P1 Components (12-16 hours)

GlossaryTooltip (4h)

Hover + click interaction
LocalStorage persistence
Tests (26 tests)

RoleBasedCTA (5h)

Three role variants
Analytics tracking
Tests (32 tests)

SectionShare (4h)

Twitter/LinkedIn/Copy buttons
Clipboard API integration
Tests (13/20 - 7 skipped)

CollapsibleSection (3h)

Expand/collapse animation
LocalStorage persistence
Tests (26 tests)

Phase 4: Rollout to Posts (2-3 hours per post)

Select 3-4 high-impact posts
Add TLDRSummary at top
Add ReadingProgressBar (automatic)
Identify 4-6 spots for KeyTakeaway
Mark 8-15 technical terms for GlossaryTooltip
Add RoleBasedCTA (3 instances: Exec/Dev/Sec)
Add SectionShare after major sections
Add CollapsibleSection for optional depth

Phase 5: Measure & Iterate (Ongoing)

Set up Vercel Analytics events
Track component interactions
Monitor engagement metrics (time on page, scroll depth, bounce rate)
A/B test: Enhanced vs. baseline posts
Gather reader feedback
Iterate on component density

Total Time Investment: ~35-45 hours for full implementation + 4-post rollout

Footnotes

Stack Overflow Developer Survey 2025: https://survey.stackoverflow.co/2025/ ↩
Vercel Analytics Documentation: https://vercel.com/docs/analytics ↩
WCAG 2.1 AA Guidelines: https://www.w3.org/WAI/WCAG22/quickref/?versions=2.1 ↩

Node.js January 2026 Security Release: 8 CVEs Explained

Drew — Wed, 14 Jan 2026 12:00:00 +0000

Upgrade Required: Node.js released security patches on January 13, 2026 for 8 vulnerabilities affecting all active release lines (20.x, 22.x, 24.x, 25.x). Upgrade immediately to v20.20.0 , v22.22.0 , v24.13.0 , or v25.3.0.

On January 13, 2026, the Node.js project released security patches addressing:

3 High Severity vulnerabilities (buffer memory leak, symlink bypass, HTTP/2 DoS)
4 Medium Severity vulnerabilities (AsyncLocalStorage crashes, TLS memory leak, UDS bypass, TLS callback DoS)
1 Low Severity vulnerability (timestamp permissions bypass)

Permissions Model Scope

Important context: Three CVEs (CVE-2025-55130, CVE-2026-21636, CVE-2025-55132) only affect users of Node.js's experimental permission model (--experimental-permission or --permission flags).

This feature, introduced in Node.js v20¹, has limited production adoption. Most Node.js deployments do NOT use the permissions model.

Quick check: If you don't explicitly pass --permission, --allow-fs-read, --allow-fs-write, or --allow-net flags when starting Node.js, these three CVEs don't apply to your deployment.

If you do use the permissions model: These are critical bypasses that break your security boundaries. Upgrade immediately.

Patched Versions:

Release Line	Patched Version	Release Notes
v25.x (Current)	25.3.0	Release Notes
v24.x (LTS)	24.13.0	Release Notes
v22.x (LTS)	22.22.0	Release Notes
v20.x (Maintenance LTS)	20.20.0	Release Notes

Dependency Updates Included:

c-ares updated to 1.34.6² - Fixes DNS resolver vulnerabilities including CVE-2025-62408 (use-after-free in read_answers()) and multiple moderate severity DNS parsing issues
undici updated to 6.23.0 / 7.18.0³ - Addresses HTTP client vulnerabilities including CVE-2026-22036 (unbounded decompression chain leading to DoS) and request smuggling issues

These dependency patches are automatically included in the Node.js security releases.

Affected Versions Matrix

CVE	Severity	v20.x	v22.x	v24.x	v25.x	Notes
CVE-2025-55131	High	Yes	Yes	Yes	Yes	Buffer memory leak
CVE-2025-55130	High	Yes	Yes	Yes	Yes	Permissions model only
CVE-2025-59465	High	Yes	Yes	Yes	Yes	HTTP/2 servers
CVE-2025-59466	Medium	Yes	Yes	Yes	Yes	AsyncLocalStorage users
CVE-2025-59464	Medium	Yes	Yes	Yes	No	TLS cert processing
CVE-2026-21636	Medium	No	No	No	Yes	v25 permissions model
CVE-2026-21637	Medium	Yes	Yes	Yes	Yes	PSK/ALPN callback users
CVE-2025-55132	Low	Yes	Yes	Yes	Yes	Permissions model only

Quick Decision Guide

Your Situation	Action Required	Risk Level
Running Node.js v20-v23 + any framework	Upgrade immediately to v20.20.0 / v22.22.0	HIGH
Running Node.js v24.x + Next.js/React	Upgrade to v24.13.0 (lower CVE-2025-59466 risk)	MEDIUM
Running Node.js v25.x	Upgrade immediately to v25.3.0	HIGH (v25-specific CVE)
Using `--permission` flags	Upgrade urgently (3 bypasses)	CRITICAL
Running self-hosted HTTP/2 servers	Review error handlers + upgrade	HIGH
Using APM tools (all versions)	Upgrade + review recursion depth limits	MEDIUM-HIGH

All users should upgrade regardless , but this helps you understand your specific risk exposure.

Who Should Upgrade?

You are affected if:

You use Next.js 13+ with App Router (uses AsyncLocalStorage internally)
You use React Server Components
You use cookies(), headers(), or other Next.js request context APIs

Critical CVEs for you:

CVE-2025-59466 (AsyncLocalStorage crashes) - Stack overflow errors in your API routes can crash your entire application
CVE-2025-59465 (HTTP/2 DoS) - If serving HTTP/2 traffic, malformed requests can crash your server

Recommended Action:

# Check your Node.js version
node --version

# Upgrade to patched version
nvm install 24.13.0 # or 22.22.0, 20.20.0

# Create version pinning file
echo "24.13.0" > .nvmrc

Additional Mitigation:

Validate input depth in API routes to prevent stack overflow:

const MAX_DEPTH = 10;

function validateDepth(obj: unknown, depth = 0): boolean {
  if (depth > MAX_DEPTH) return false;
  if (typeof obj !== 'object' || obj === null) return true;

  return Object.values(obj).every((v) => validateDepth(v, depth + 1));
}

You are affected if:

You use any Application Performance Monitoring tool
You have require('dd-trace'), require('newrelic'), or similar APM initialization
You use OpenTelemetry for distributed tracing

Why APM makes CVE-2025-59466 worse:

APM tools use async_hooks.createHook() to trace requests across async boundaries. The moment you import an APM package, your application has async_hooks enabled, making stack overflow errors uncatchable.

The irony: The tools you install to monitor crashes can make a category of crashes behave differently.

Recommended Action:

Upgrade Node.js to patched versions immediately
Review recursive functions in your codebase
Add depth limits to any user-input-driven recursion

You are affected if:

You use --experimental-permission or --permission flags
You use --allow-fs-read, --allow-fs-write, or --allow-net flags

Critical CVEs for you:

CVE-2025-55130 (Symlink bypass) - Attackers can escape file system restrictions
CVE-2026-21636 (UDS bypass) - v25 only, network restrictions bypassed
CVE-2025-55132 (futimes bypass) - Timestamp modification in read-only directories

Recommended Action:

Upgrade immediately. The permissions model's security guarantees are broken until patched.

You are affected if:

You run HTTP/2 servers with TLS
You use TLS client certificate authentication (mTLS)
You use Pre-Shared Key (PSK) or ALPN callbacks

Critical CVEs for you:

CVE-2025-59465 (HTTP/2 DoS) - Malformed frames crash servers
CVE-2025-59464 (TLS memory leak) - Certificate processing leaks memory
CVE-2026-21637 (Callback DoS) - PSK/ALPN exceptions cause crashes

Recommended Action:

Upgrade Node.js immediately
Add explicit error handlers to TLS sockets
Monitor memory usage for TLS-heavy workloads

How to Upgrade

Using nvm (Node Version Manager)

# Install the patched version for your release line
nvm install 24.13.0 # LTS (recommended)
nvm install 22.22.0 # Previous LTS
nvm install 20.20.0 # Maintenance LTS
nvm install 25.3.0 # Current

# Verify installation
node --version
# v24.13.0

# Set as default
nvm alias default 24.13.0

# Create version pinning file for your project
echo "24.13.0" > .nvmrc
echo "24.13.0" > .node-version # For other version managers

Using Homebrew (macOS)

brew update
brew upgrade node
node --version

Verifying the Upgrade

# Check Node.js version
node --version
# Should show: v20.20.0, v22.22.0, v24.13.0, or v25.3.0

# Verify npm is functional
npm --version

# Run your test suite
npm test

CI/CD Considerations

Update your GitHub Actions workflows to use version pinning:

# .github/workflows/ci.yml
- uses: actions/setup-node@v4
  with:
    node-version-file: '.nvmrc' # Use version from .nvmrc file

High Severity Vulnerabilities

CVE-2025-55131: Buffer Memory Leak via Race Condition

Affected Versions: 20.x, 22.x, 24.x, 25.x

Reporter: Nikita Skovoroda

A flaw in Node.js buffer allocation logic can expose uninitialized memory when allocations are interrupted while using the vm module with the timeout option. Under specific timing conditions, buffers allocated with Buffer.alloc() and TypedArray instances like Uint8Array may contain leftover data from previous operations.

Impact:

This vulnerability allows in-process secrets like tokens, passwords, or API keys to leak, potentially causing data corruption. While exploitation typically requires precise timing or in-process code execution, it becomes remotely exploitable when untrusted input influences workload and timeouts.

Example Risk Scenario:

import { runInNewContext } from 'vm';

// Previous operation stored sensitive data
const sensitiveBuffer = Buffer.alloc(1024);
sensitiveBuffer.write('SECRET_API_KEY_xyz123');

// Later, with vm timeout, race condition can occur
const result = runInNewContext('Buffer.alloc(1024)', {}, { timeout: 100 });
// result may contain: "SECRET_API_KEY_xyz123" from previous operation

Mitigation: Upgrade to patched versions. Avoid using vm module with untrusted input and timeout options in security-sensitive contexts.

CVE-2025-55131 can expose in-process secrets (API keys, tokens, passwords) through uninitialized memory. If you use the vm module with timeouts and untrusted input, upgrade immediately —this becomes remotely exploitable with precise timing attacks.

CVE-2025-55130: File System Permissions Bypass via Symlinks

Affected Versions: 20.x, 22.x, 24.x, 25.x (permissions model users)

Reporter: natann

Fix By: RafaelGSS

A flaw in Node.js's Permissions model allows attackers to bypass --allow-fs-read and --allow-fs-write restrictions using crafted relative symlink paths. By chaining directories and symlinks, a script granted access only to the current directory can escape the allowed path and read sensitive files.

Impact:

This breaks the expected isolation guarantees and enables arbitrary file read/write, potentially leading to system compromise.

Attack Pattern:

# Application started with restricted permissions
node --experimental-permission --allow-fs-read=/app/data ./app.js

# Attacker creates symlink chain to escape /app/data
# symlink: /app/data/escape -> ../../../etc/passwd
# Script can now read /etc/passwd despite restrictions

Who Is Affected:

Only users of the Node.js permission model (--experimental-permission or --permission flags) are affected. If you're not using these flags, this CVE does not apply to your deployments.

Mitigation: Upgrade to patched versions. Review symlink handling in permission-restricted environments.

If you use --experimental-permission or --permission flags, CVE-2025-55130 allows complete escape of file system restrictions via symlink chains. This breaks expected isolation guarantees and enables arbitrary file read/write. Upgrade urgently if you rely on the permissions model for security boundaries.

CVE-2025-59465: HTTP/2 Server Crash via Malformed HEADERS

Affected Versions: 20.x, 22.x, 24.x, 25.x

Reporter: dantt

Fix By: RafaelGSS

A malformed HTTP/2 HEADERS frame with oversized, invalid HPACK data can cause Node.js to crash by triggering an unhandled TLSSocket error (ECONNRESET). Instead of safely closing the connection, the process crashes, enabling remote denial of service.

Impact:

This vulnerability primarily affects applications that do not attach explicit error handlers to secure sockets. A remote attacker can crash your entire Node.js process with a single malformed request.

Vulnerable Pattern:

// Default HTTP/2 server - NO explicit error handlers
import { createSecureServer } from 'http2';

const server = createSecureServer({
  key: privateKey,
  cert: certificate,
});

server.on('stream', (stream, headers) => {
  // Handle request
});

server.listen(443);
// Attacker sends malformed HEADERS frame -> Process crashes

Recommended Mitigation:

// Add explicit error handlers to prevent crashes
server.on('secureConnection', (socket) => {
  socket.on('error', (err) => {
    console.error(
      '<abbr title="TLS Socket Error - errors occurring during secure socket communication, commonly including connection resets, handshake failures, and protocol violations that can crash servers if unhandled" class="glossary-term rss-glossary">TLS Socket Error</abbr>:',
      err.message
    );
    // Gracefully close instead of crashing
    socket.destroy();
  });
});

Who Is Affected:

Any Node.js application using HTTP/2 without explicit TLS socket error handlers. This includes many Next.js, Fastify, and custom HTTP/2 deployments.

A single malformed HTTP/2 HEADERS frame can crash your entire Node.js process if you don't have explicit error handlers on secure sockets. This affects any HTTP/2 server withoutsocket.on('error') handlers. Add error handling NOW, then upgrade.

Medium Severity Vulnerabilities

CVE-2025-59466: AsyncLocalStorage Stack Overflow Crashes

Affected Versions: 20.x, 22.x, 24.x, 25.x

Reporter: Andrew MacPherson (AndrewMohawk), aaron_vercel

Fix By: mcollina

A bug in Node.js error handling causes "Maximum call stack size exceeded" errors to become uncatchable when async_hooks.createHook() is enabled. Instead of reaching process.on('uncaughtException'), the process terminates immediately, making the crash unrecoverable.

Why This Matters:

This vulnerability silently affects a massive portion of the Node.js ecosystem because:

React Server Components use AsyncLocalStorage internally
Next.js uses AsyncLocalStorage for request context tracking (cookies, headers)⁴
Every major APM tool (Datadog⁵, New Relic⁶, Dynatrace, Elastic APM, OpenTelemetry⁷) uses AsyncLocalStorage or async_hooks.createHook() to trace requests

Applications whose recursion depth is controlled by unsanitized input become vulnerable to denial-of-service attacks.

Example Vulnerable Pattern:

// API route processing deeply nested user input
export async function POST(request: Request) {
  const data = await request.json();

  // If data is deeply nested (1000+ levels), stack overflow occurs
  // With AsyncLocalStorage active, error bypasses all handlers
  // Process crashes immediately - no logging, no recovery
  const result = processNestedData(data);

  return Response.json(result);
}

Important Caveat:

The Node.js patch improves recoverability in one edge case, but the documentation explicitly states:

"Recovery from space exhaustion is unspecified, best-effort behavior and is not a reliable basis for availability or security."

Recommendation: Don't rely on catching stack overflow errors. Prevent them by validating input depth and bounding recursion.

Important for Node.js v24+ users: Node.js v24 fundamentally changed AsyncLocalStorage's implementation—it no longer uses async_hooks.createHook() internally⁸. This means:

React Server Components: NOT affected on Node.js v24+
Next.js (cookies, headers, etc.): NOT affected on Node.js v24+
APM tools using only AsyncLocalStorage: NOT affected on Node.js v24+
APM tools directly using async_hooks.createHook(): Still affected on all versions

If you're running Node.js v24.13.0+ , CVE-2025-59466 is primarily a concern if you:

Use APM tools that directly call async_hooks.createHook() (check vendor documentation)
Have custom code using async_hooks.createHook()
Run Node.js v20-v23 (where the vulnerability fully applies)

Bottom line: The risk profile for Next.js applications is significantly different between Node.js v20-v23 (high risk) and v24+ (lower risk). Upgrade regardless, but understand the context.

Further Reading: Node.js published a detailed companion blog post: Mitigating Denial-of-Service Vulnerability from Unrecoverable Stack Space Exhaustion for React, Next.js, and APM Users

CVE-2025-59466 silently affects massive portions of the Node.js ecosystem: Next.js (cookies, headers), React Server Components, and every major APM tool (Datadog, New Relic, OpenTelemetry). On Node.js v20-v23, stack overflow errors bypass all handlers and crash immediately. Node.js v24+ significantly reduces risk for Next.js/RSC but APM tools usingasync_hooks.createHook() remain vulnerable. Validate input depth + upgrade.

CVE-2025-59464: TLS Certificate Memory Leak

Affected Versions: 20.x, 22.x, 24.x

Reporter: giant_anteater

Fix By: RafaelGSS

A memory leak in Node.js's OpenSSL integration occurs when converting X.509 certificate fields to UTF-8 without freeing the allocated buffer. When applications call socket.getPeerCertificate(true), each certificate field leaks memory.

Impact:

Remote clients can trigger steady memory growth through repeated TLS connections. Over time, this leads to resource exhaustion and denial of service.

Affected Pattern:

// TLS server processing client certificates
server.on('secureConnection', (socket) => {
  // Each call leaks memory
  const cert = socket.getPeerCertificate(true);
  // Memory never freed for certificate fields
});

Who Is Affected:

Applications that process TLS client certificates, particularly mutual TLS (mTLS) implementations and certificate-based authentication systems.

CVE-2026-21636: Unix Domain Socket Permissions Bypass

Affected Versions: v25.x only

Reporter: mufeedvh

Fix By: RafaelGSS

A flaw in Node.js's permission model allows Unix Domain Socket (UDS) connections to bypass network restrictions when --permission is enabled. Even without --allow-net, attacker-controlled inputs (such as URLs or socketPath options) can connect to arbitrary local sockets via net, tls, or undici/fetch.

Impact:

This breaks the intended security boundary of the permission model and enables access to privileged local services, potentially leading to privilege escalation, data exposure, or local code execution.

Note: Network permissions (--allow-net) are still in the experimental phase.

Who Is Affected:

Only users of the Node.js permission model on version v25.x. If you're using v20, v22, or v24, or not using the permission model, this CVE does not apply.

CVE-2026-21637: TLS PSK/ALPN Callback DoS

Affected Versions: All versions using PSK or ALPN callbacks

Reporter: 0xmaxhax

Fix By: mcollina

A flaw in Node.js TLS error handling allows remote attackers to crash or exhaust resources of a TLS server when pskCallback or ALPNCallback are in use. Synchronous exceptions thrown during these callbacks bypass standard TLS error handling paths (tlsClientError and error).

Impact:

This causes either immediate process termination or silent file descriptor leaks that eventually lead to denial of service. Because these callbacks process attacker-controlled input during the TLS handshake, a remote client can repeatedly trigger the issue.

Who Is Affected:

TLS servers using Pre-Shared Key (PSK) authentication or Application-Layer Protocol Negotiation (ALPN) callbacks that may throw exceptions.

Low Severity Vulnerability

CVE-2025-55132: fs.futimes() Permissions Bypass

Affected Versions: 20.x, 22.x, 24.x, 25.x (permissions model users)

Reporter: oriotie

Fix By: RafaelGSS

A flaw in Node.js's permission model allows a file's access and modification timestamps to be changed via futimes() even when the process has only read permissions. Unlike utimes(), futimes() does not apply the expected write-permission checks.

Impact:

File metadata can be modified in read-only directories. This behavior could be used to alter timestamps in ways that obscure activity, reducing the reliability of logs and audit trails.

Who Is Affected:

Only users of the Node.js permission model. Low impact for most deployments.

Three CVEs (CVE-2025-55130, CVE-2026-21636, CVE-2025-55132) only affect users of Node.js's experimental permission model (--experimental-permission flags). This feature has limited production adoption —most Node.js deployments do NOT use it. Quick check: if you don't pass--permission flags when starting Node.js, these three CVEs don't apply to your deployment.

Key Takeaways

Upgrade immediately - All active Node.js release lines (20.x, 22.x, 24.x, 25.x) are affected by at least 6 of the 8 CVEs
HTTP/2 servers need error handlers - CVE-2025-59465 can crash servers that lack explicit TLS socket error handling
AsyncLocalStorage affects most modern apps - If you use Next.js, React Server Components, or any APM tool, CVE-2025-59466 applies to you
Prevent stack overflow, don't catch it - Input validation and recursion depth limits are more reliable than error handling
Permission model users: patch urgently - Multiple CVEs break file system and network isolation guarantees
Pin your Node.js version - Use .nvmrc and .node-version files to ensure consistent versions across development and CI/CD
Subscribe to security notifications - Join the nodejs-sec mailing list for future advisories

References

Official Node.js Resources

Tuesday, January 13, 2026 Security Releases - Official announcement
Mitigating DoS from Stack Exhaustion (AsyncLocalStorage) - Detailed technical blog post
Node.js Security Policy - Reporting vulnerabilities

Release Notes

Security Mailing List

Subscribe to the low-volume, announcement-only nodejs-sec mailing list: groups.google.com/forum/#!forum/nodejs-sec

Footnotes

Node.js 20 Released, Features Experimental Permission Model - InfoQ ↩
c-ares vulnerabilities - Official c-ares vulnerability database ↩
The January 2026 Security Update Review - Zero Day Initiative (undici CVE-2026-22036) ↩
Functions: cookies | Next.js - Official Next.js documentation on AsyncLocalStorage usage ↩
Mitigation for Node.js denial-of-service vulnerability affecting APM - Datadog ↩
Introducing AsyncLocalStorage context manager for the Node.js agent - New Relic ↩
Monitoring and Tracing | Hive Gateway - OpenTelemetry integration guide ↩
Mitigating Denial-of-Service Vulnerability from Unrecoverable Stack Space Exhaustion - Node.js Official Blog (AsyncLocalStorage v24 reimplementation) ↩

Building Event-Driven Architecture with Inngest

Drew — Sun, 11 Jan 2026 12:00:00 +0000

📚 Series Background: This is Part 3 of the Portfolio series. Following the initial build and security hardening, here we explore how event-driven architecture transforms user experience and system reliability using Inngest for background job processing.

Your API routes are lying to your users. They return 200 OK while work is still happening. The contact form says "Message sent!" but the email hasn't been delivered yet.

Event-driven architecture fixes this by separating acknowledgment from processing. Users get instant feedback. Work happens reliably in the background. Here's how Inngest makes this practical for any Next.js project.

When I first built this portfolio's contact form, the flow was straightforward but slow:

// The old way: synchronous processing
export async function POST(request: NextRequest) {
  const { name, email, message } = await request.json();

  // User waits 1-2 seconds for this...
  await resend.emails.send({
    from: FROM_EMAIL,
    to: AUTHOR_EMAIL,
    subject: `Contact form: ${name}`,
    text: message,
  });

  // Only then do they see success
  return NextResponse.json({ success: true });
}

This approach has real problems:

Slow responses : Users wait 1-2 seconds for external API calls
Fragile : If Resend is slow or down, the entire request fails
No retries : Network blip means the email is lost forever
Poor UX : Spinners spinning while users wonder if it worked

The fix isn't making the email faster—it's decoupling the response from the work.

Event-Driven Architecture Explained

Event-driven architecture
separates two concerns:

Acknowledging the request (fast, synchronous)
Processing the work (async, can be slow, can retry)

Before (Synchronous):
User → API Route → Email Service → Response
         └─────── 1-2 seconds ──────┘

After (Event-Driven):
User → API Route → Queue Event → Response (< 100ms)
                        ↓
              Background Function → Email Service
                        └─── Retries if needed ───┘

The insight: users don't care when the email sends—they care that you acknowledged their message.

Modern event-driven systems add one more concept: steps. Instead of one monolithic background function, you break work into discrete, named operations. Each step becomes a checkpoint—if step 3 fails, steps 1 and 2 don't re-run. This is called durable execution, and it transforms how you think about reliability.

Further Reading: For comprehensive overviews of event-driven architecture patterns, see Martin Fowler's Event-Driven Architecture and AWS's What is Event-Driven Architecture?

After evaluating several options, I chose Inngest for this portfolio:

Solution	Pros	Cons	Learn More
Vercel Cron	Built-in, simple	No retries, no event triggers	Docs
QStash	Serverless, Upstash ecosystem	More complex setup	Docs
BullMQ + Redis	Powerful, battle-tested	Requires persistent server	Docs
Inngest	Serverless, local dev UI, automatic retries	Newer ecosystem	Docs

What sold me on Inngest:

Zero infrastructure : No Redis queue to manage
Local development : Beautiful dev UI for testing functions
Automatic retries : Configurable retry policies with exponential backoff
Step functions : Break complex workflows into observable, resumable steps
Vercel-native : First-class integration, deploys automatically

Implementation: Contact Form

Here's the actual production code from this portfolio:

Step 1: Queue Event from API Route

// src/app/api/contact/route.ts
import { inngest } from '@/inngest/client';

export async function POST(request: NextRequest) {
  const { name, email, message } = await request.json();

  // Validate and sanitize inputs...

  // Queue the event (returns immediately)
  await inngest.send({
    name: 'contact/form.submitted',
    data: {
      name: sanitizedData.name,
      email: sanitizedData.email,
      message: sanitizedData.message,
      submittedAt: new Date().toISOString(),
    },
  });

  // User gets instant response
  return NextResponse.json({
    success: true,
    message: "Message received! You'll get a confirmation email shortly.",
  });
}

The API route now completes in under 100ms. The user sees instant feedback.

Step 2: Handle Event in Background Function

// src/inngest/contact-functions.ts
import { inngest } from './client';
import { Resend } from 'resend';
import { track } from '@vercel/analytics/server';

export const contactFormSubmitted = inngest.createFunction(
  {
    id: 'contact-form-submitted',
    retries: 3, // Automatic retries with exponential backoff
  },
  { event: 'contact/form.submitted' },
  async ({ event, step }) => {
    const { name, email, message, submittedAt } = event.data;

    // Step 1: Send notification email to site owner
    const notificationResult = await step.run('send-notification-email', async () => {
      const result = await resend.emails.send({
        from: FROM_EMAIL,
        to: AUTHOR_EMAIL,
        subject: `Contact form: ${name}`,
        replyTo: email,
        text: `From: ${name} <${email}>\nSubmitted: ${new Date(submittedAt).toLocaleString()}\n\n${message}`,
      });

      // Track in Vercel Analytics
      await track('contact_form_submitted', {
        emailDomain: email.split('@')[1],
        success: true,
      });

      return { success: true, messageId: result.data?.id };
    });

    // Step 2: Send confirmation email to submitter
    const confirmationResult = await step.run('send-confirmation-email', async () => {
      const result = await resend.emails.send({
        from: FROM_EMAIL,
        to: email,
        subject: 'Thanks for reaching out!',
        text: `Hi ${name},\n\nThank you for your message! I'll get back to you soon.\n\nBest,\nDrew`,
      });

      return { success: true, messageId: result.data?.id };
    });

    return {
      success: true,
      notification: notificationResult,
      confirmation: confirmationResult,
      processedAt: new Date().toISOString(),
    };
  }
);

Why Steps Matter

Each step.run() creates a checkpoint. If Step 2 fails:

Step 1 doesn't re-run (notification already sent)
Only Step 2 retries
You see exactly where it failed in the Inngest dashboard

This is durable execution—your function survives failures and resumes from the last successful step.

Scheduled Tasks: GitHub Contributions

Event-driven architecture isn't just for user actions. Scheduled tasks benefit too.

The homepage shows a GitHub contribution heatmap. Instead of fetching on every page load (slow, rate-limited), I pre-populate the cache hourly:

// src/inngest/github-functions.ts
export const refreshGitHubData = inngest.createFunction(
  {
    id: 'refresh-github-data',
    retries: 1, // Fail fast on hourly jobs
  },
  { cron: '0 * * * *' }, // Every hour at minute 0
  async ({ step }) => {
    await step.run('fetch-github-contributions', async () => {
      const contributions = await fetchGitHubContributions(GITHUB_USERNAME);

      // Store in Redis cache
      await redis.set(
        `github:contributions:${GITHUB_USERNAME}`,
        JSON.stringify(contributions),
        { EX: 60 * 60 * 2 } // Cache for 2 hours
      );

      return { fetchedAt: new Date().toISOString(), count: contributions.length };
    });
  }
);

Benefits:

Page loads are instant (data is pre-cached)
GitHub API rate limits aren't a concern
Failures don't affect users (stale cache is served)
Full observability in the Inngest dashboard

Production Functions in This Portfolio

Here's what's actually running right now:

Function	Trigger	Purpose
`contact-form-submitted`	Event	Send notification + confirmation emails
`refresh-github-data`	Hourly cron	Pre-populate contribution heatmap cache
`track-post-view`	Event	Update view counts, track daily analytics, detect milestones
`calculate-trending`	Hourly cron	Compute trending posts from recent views
`refresh-activity-feed`	Hourly cron	Pre-compute activity feed for instant page loads
`security-advisory-monitor`	3x daily	Check GHSA (GitHub Security Advisory database) for CVEs affecting dependencies
`daily-analytics-summary`	Daily cron	Generate previous day's blog analytics
`sync-vercel-analytics`	Daily cron	Sync Vercel analytics to Redis for dashboards

The Security Monitor

After discovering a critical React vulnerability (React2Shell) in December 2025 (with a 13-hour detection gap), I added automated security monitoring.

export const securityAdvisoryMonitor = inngest.createFunction(
  {
    id: 'security-advisory-monitor',
    retries: 3,
  },
  { cron: '0 0,8,16 * * *' }, // 3x daily (00:00, 08:00, 16:00 UTC)
  async ({ step }) => {
    // Step 1: Fetch advisories from GHSA
    const advisories = await step.run('fetch-ghsa-advisories', async () => {
      const results = [];

      for (const packageName of MONITORED_PACKAGES) {
        const data = await fetchGhsaAdvisories(packageName);

        for (const adv of data) {
          if (meetsSeverityThreshold(adv.severity, packageName)) {
            results.push({
              package: packageName,
              severity: adv.severity,
              ghsaId: adv.ghsa_id,
              summary: adv.summary,
              patchedVersion: adv.vulnerabilities?.[0]?.first_patched_version,
            });
          }
        }
      }

      return results;
    });

    // Step 2: Filter to advisories affecting installed versions
    const newAdvisories = await step.run('filter-new-advisories', async () => {
      const lockData = parsePackageLock();

      return advisories.filter((adv) => {
        const versionCheck = checkAdvisoryImpact(
          adv.package,
          adv.vulnerableRange,
          adv.patchedVersion,
          lockData
        );
        return versionCheck.isVulnerable;
      });
    });

    // Step 3: Send email alert if new advisories found
    if (newAdvisories.length > 0) {
      await step.run('send-email-alert', async () => {
        await sendSecurityAlert(newAdvisories);
      });
    }

    return { checkedAt: new Date().toISOString(), found: newAdvisories.length };
  }
);

This runs three times daily, checks for CVEs affecting React/Next.js/RSC packages, verifies against my actual installed versions, and alerts me before I read about it on Twitter.

Blog Analytics

The blog tracks views and automatically detects milestones:

export const trackPostView = inngest.createFunction(
  { id: 'track-post-view' },
  { event: 'blog/post.viewed' },
  async ({ event, step }) => {
    const { postId, slug, title } = event.data;

    await step.run('process-view', async () => {
      // Get current view count
      const views = await redis.get(`views:post:${postId}`);
      const count = parseInt(views || '0');

      // Track daily views for analytics
      const today = new Date().toISOString().split('T')[0];
      await redis.incr(`views:post:${postId}:day:${today}`);

      // Check for milestones
      const milestones = [100, 1000, 10000, 50000, 100000];
      for (const milestone of milestones) {
        if (count === milestone) {
          // Trigger milestone event
          await inngest.send({
            name: 'blog/milestone.reached',
            data: { slug, title, milestone, totalViews: count },
          });
        }
      }

      return count;
    });
  }
);

When a post hits 1,000 views, I get notified. The trending calculation runs hourly, scoring posts by recent activity to surface what readers are finding valuable.

Developer Experience

Local Development

Inngest provides a local dev server with a powerful UI:

npx inngest-cli@latest dev

This gives you:

Real-time function execution logs
Ability to trigger events manually
Step-by-step execution visualization
Replay failed functions from any step

Testing

Functions are just async functions—test them like any other code:

describe('contactFormSubmitted', () => {
  it('sends notification and confirmation emails', async () => {
    const mockEvent = {
      data: {
        name: 'Test User',
        email: 'test@example.com',
        message: 'Hello!',
        submittedAt: new Date().toISOString(),
      },
    };

    const result = await contactFormSubmitted.handler({
      event: mockEvent,
      step: mockStepFunctions,
    });

    expect(result.success).toBe(true);
    expect(mockResend.send).toHaveBeenCalledTimes(2);
  });
});

Deployment

Inngest integrates seamlessly with Vercel:

1. Install the Vercel integration in your Inngest dashboard

2. Export functions from a single endpoint:

// src/app/api/inngest/route.ts
import { serve } from 'inngest/next';
import { inngest } from '@/inngest/client';
import { contactFormSubmitted } from '@/inngest/contact-functions';
import { refreshGitHubData } from '@/inngest/github-functions';
import { trackPostView, calculateTrending } from '@/inngest/blog-functions';
import { securityAdvisoryMonitor } from '@/inngest/security-functions';
import { refreshActivityFeed } from '@/inngest/activity-cache-functions';

export const { GET, POST, PUT } = serve({
  client: inngest,
  functions: [
    contactFormSubmitted,
    refreshGitHubData,
    trackPostView,
    calculateTrending,
    securityAdvisoryMonitor,
    refreshActivityFeed,
    // ... all functions
  ],
});

3. Deploy —Inngest discovers your functions automatically

Environment variables (INNGEST_EVENT_KEY, INNGEST_SIGNING_KEY) are set automatically by the Vercel integration.

Results

After migrating to event-driven architecture (measured in this portfolio's production environment):

Metric	Before	After
Contact form response time	1–2s (observed)	Under 100ms (observed)
Email delivery reliability	~95% (observed)	99.9% (with 3 retries, based on Inngest's exponential backoff)
GitHub data freshness	On-demand	Pre-cached hourly
Failed job visibility	None	Full dashboard
Security advisory detection	Manual	Automated (3x daily)

Note: These metrics reflect this specific implementation. Your results may vary based on network conditions, third-party API performance, and deployment region.

More importantly: users notice. The contact form feels instant. The contribution heatmap loads immediately. Security issues get flagged before they become problems.

Key Takeaways

Decouple acknowledgment from processing —users want fast feedback, not fast completion
Steps create checkpoints —failed steps retry without re-running successful ones
Scheduled tasks benefit too —pre-populate caches, monitor systems, aggregate data
Local dev matters —Inngest's dev UI makes debugging enjoyable
Start simple —you don't need event-driven for everything

Event-driven architecture doesn't require enterprise scale. With tools like Inngest, any Next.js project can benefit from reliable background processing, instant API responses, and better observability.

When NOT to Use Event-Driven

Event-driven architecture isn't always the answer:

Simple CRUD : Reading/writing to a database doesn't need queuing. Saving a user preference? Just write to the database directly.
Real-time requirements : If users need the result immediately, don't defer it. A "Reply to comment" feature where users expect to see their comment appear instantly should stay synchronous—even if it takes 500ms.
Debugging complexity : More moving parts means more places to look. If your team is already stretched thin, the observability benefits might not outweigh the learning curve.
Small scale : If you have 10 users/day, synchronous is simpler. Don't add infrastructure complexity you don't need yet.

The rule of thumb: if users don't need to wait for the result, don't make them wait. But if they do need to see the result immediately, don't hide it behind a queue.

One more thing: background jobs are a security surface too. The security monitor in this portfolio exists because I learned the hard way that CVE detection gaps matter. If you're processing sensitive data in background functions, apply the same security rigor you would to API routes—validate inputs, sanitize outputs, and monitor for anomalies.

The contact form still says "Message sent!"—but now it's actually true (or will be, with retries, within seconds).

Resources

OWASP Top 10 for Agentic AI: What You Need to Know in 2026

Drew — Fri, 19 Dec 2025 12:00:00 +0000

As AI agents become more autonomous and capable of taking real-world actions, the security landscape is evolving rapidly. This guide breaks down OWASP's newly released framework for securing agentic AI systems.

Agentic AI refers to autonomous AI systems that go beyond simple chatbots to plan multi-step workflows, invoke tools and APIs independently, and make decisions without human intervention. These AI agents now book travel, manage calendars, approve expenses, deploy code, and handle customer service autonomously--creating an entirely new category of AI agent security risks.

The Open Web Application Security Project (OWASP), the global authority on application security, just released its first-ever Top 10 for Agentic Applications for 2026. Developed by over 100 security experts, this framework identifies the most critical threats facing autonomous AI systems: from goal hijacking and memory poisoning to rogue agents and cascading failures.

Whether you're a security professional implementing AI safeguards, a business leader evaluating autonomous agents, or a developer building agentic systems, this comprehensive guide covers the risks you need to understand and the controls you need to implement.

What Makes Agentic AI Different (and Riskier)?

Traditional AI systems are reactive: you ask a question, they answer. Agentic AI systems are proactive and autonomous. They can:

Plan multi-step workflows to achieve complex goals
Decide which tools and APIs to invoke without asking permission
Persist information across sessions using long-term memory
Communicate and coordinate with other AI agents
Operate continuously, 24/7, making decisions on behalf of users and organizations

Feature	Traditional AI (LLMs)	Agentic AI
Action	Passive (Responds)	Proactive (Initiates)
Scope	Single Turn	Multi-step Workflows
Tools	None / Read-only	Active Execution (API/DB)
Memory	Session-limited	Persistent / Long-term
Risk	Misinformation	System Compromise

Traditional AI risks center on misinformation. Agentic AI risks involve system compromise --agents with legitimate access to databases, APIs, and cloud infrastructure that attackers can weaponize.

Major companies already deploy these systems at scale. Salesforce's Agentforce handles customer service workflows autonomously. Microsoft's Copilot Studio creates agents accessing sensitive business data across Microsoft 365. ServiceNow's AI agents automate IT and HR processes, reducing manual workloads by up to 60%.¹ Amazon uses agentic AI to optimize delivery routes, saving an estimated $100 million annually by replacing manual analyst modifications with AI-driven optimization.²

According to major research firms, agentic AI adoption is accelerating faster than security controls:

PwC & McKinsey Surveys : 79% of organizations report at least some level of AI agent adoption, with 62% already experimenting with or scaling agentic AI systems in production
Forrester's 2026 Cybersecurity Predictions : Agentic AI deployments will likely trigger major security breaches and lead to employee dismissals if organizations fail to implement proper safeguards. The research firm emphasizes that these breaches stem from "cascading failures" in autonomous systems, not individual mistakes
Gartner Analysis : By 2028, 33% of enterprise software will incorporate agentic AI, and 15% of daily business decisions will be handled autonomously. That's up from less than 1% in 2024

The challenge is clear: we're deploying these systems faster than we're securing them. Yet the same capabilities that make agents powerful make them dangerous when compromised. A single vulnerability can cascade across interconnected systems, amplifying traditional security risks and introducing entirely new attack vectors.

By 2028, 33% of enterprise software will incorporate agentic AI, and 15% of daily business decisions will be autonomous. We're deploying these systems faster than we're securing them.

According to Gartner, by 2028, 33% of enterprise software will incorporate agentic AI, and 15% of daily business decisions will be handled autonomously. That's up from less than 1% in 2024.³ The challenge: the same capabilities that make agents powerful make them dangerous when compromised. A single vulnerability can cascade across interconnected systems, amplifying traditional security risks and introducing new attack vectors.

What This Means for Your Organization

The OWASP Agentic Top 10 reflects real incidents already happening in production environments. From the EchoLeak attack on Microsoft Copilot to supply chain compromises in Amazon Q, attackers are actively exploiting these vulnerabilities.

Yet according to Forrester, most organizations lack the security controls to prevent what the firm predicts will be "major breaches and employee dismissals" stemming from agentic AI compromises in 2026. The research firm emphasizes that these breaches stem from "cascading failures" in autonomous systems, not individual mistakes.⁴ Meanwhile, according to PwC and McKinsey surveys, 79% of organizations report at least some level of AI agent adoption, with 62% already experimenting with or scaling agentic AI systems.⁵

No single control prevents all attacks. Layer least agency (minimize autonomy) + observability (monitor everything) + zero trust (assume compromise) + human oversight (approve high-impact actions).

The OWASP framework emphasizes foundational principles organizations must implement:

Least Agency: Avoid deploying agentic behavior where unnecessary. Unnecessary autonomy expands your attack surface without adding value.
Strong Observability: Maintain clear visibility into what agents are doing, why they're doing it, and which tools they're invoking. Without comprehensive logging and monitoring, minor issues quietly cascade into system-wide failures.
Zero Trust Architecture: Design systems assuming components will fail or be exploited. Implement blast-radius controls, sandboxing, and policy enforcement to contain failures.
Human-in-the-Loop for High-Impact Actions: Require human approval for privileged operations, irreversible changes, or goal-changing decisions.

How This Relates to Broader AI Security Frameworks

The OWASP Agentic Top 10 builds on the organization's existing OWASP Top 10 for Large Language Models (LLMs), recognizing that agentic systems amplify traditional LLM vulnerabilities through autonomy and multi-step execution.

The Agentic Top 10 aligns with major security frameworks across the industry:

NIST AI Risk Management Framework : Provides governance structure and risk management processes for AI systems across organizations
MITRE ATLAS : Catalogs specific adversarial tactics and attack techniques against AI systems, building on MITRE ATT&CK
ISO 42001 : Establishes international standards for AI management systems and governance
EU AI Act : Sets regulatory requirements for high-risk AI applications in the European market

OWASP has also mapped the Agentic Top 10 to its Non-Human Identities (NHI) Top 10, recognizing that agents are autonomous non-human identities requiring dedicated security controls around credential management, privilege scoping, and lifecycle governance. This connection is critical for enterprises implementing comprehensive identity and access management strategies across human and non-human entities.

The OWASP Agentic Top 10 Breakdown

The OWASP Top 10 for Agentic Applications identifies the most critical security risks organizations face when deploying autonomous AI. Explore each risk below—expand the sections that matter most to your security posture.

What it is: Attackers manipulate an agent's objectives, causing it to pursue malicious goals instead of its intended purpose.

Why it matters: Agents process natural language instructions and cannot always distinguish legitimate commands from attacker-controlled content. A malicious email, poisoned document, or hidden webpage instructions can redirect an agent's entire mission.

Real-world example: In the EchoLeak attack , researchers at Aim Security discovered that a crafted email could trigger Microsoft 365 Copilot to silently exfiltrate confidential emails, files, and chat logs--without user interaction. The agent followed hidden instructions embedded in the message, treating attacker commands as legitimate goals. Microsoft assigned a critical CVSS score of 9.3 and deployed patches by May 2025.⁶

In another incident, security researcher Johann Rehberger demonstrated how malicious webpage content could trick OpenAI's Operator agent into accessing authenticated internal pages and exposing users' private data, including email addresses, home addresses, and phone numbers from sites like GitHub and Booking.com.⁷

💡 Key Point: If an agent's goals can be hijacked, it becomes a weapon turned against you--using its own legitimate access to cause harm.

What it is: Agents misuse legitimate tools (APIs, databases, email systems) in unsafe or unintended ways, even while operating within authorized privileges.

Why it matters: Agents access powerful tools to do their jobs. A customer service agent might connect to your CRM, email system, and payment processor. A compromised agent could delete valuable data, exfiltrate sensitive information, or trigger costly API calls repeatedly.

Real-world example: Security researchers demonstrated an attack where a coding assistant was tricked into repeatedly triggering a "ping" tool to exfiltrate data through DNS queries. Because the ping tool was approved for auto-execution and considered "safe," the attack went undetected.

In another case, attackers manipulated an agent with database access into deleting entries--using a tool it was authorized to access, but in an unintended way.

💡 Key Point: Even legitimate, authorized tools become dangerous when agents use them incorrectly or under attacker influence.

What it is: Agents exploit dynamic trust relationships and inherited credentials to escalate access beyond their intended scope.

Why it matters: Most agents lack distinct identities in enterprise systems. They operate using delegated user credentials or shared service accounts. When a high-privilege manager agent delegates a task to a worker agent without properly scoping permissions, that worker inherits excessive rights. Attackers exploit these delegation chains to access data and systems far beyond the agent's intended scope.

Real-world example: A finance agent delegates a database query to a helper agent, passing along all its permissions. An attacker steering the helper agent uses those inherited credentials to exfiltrate HR and legal data--information the helper should never have accessed.

Microsoft Copilot Studio agents were public by default without authentication, allowing attackers to enumerate exposed agents and pull confidential business data from production environments.

💡 Key Point: Without proper identity management, agents become confused deputies: trusted entities that can be tricked into abusing their own privileges.

What it is: Malicious or compromised third-party components (tools, plugins, models, prompt templates, or other agents) infiltrate your agentic system.

Why it matters: Agentic ecosystems compose capabilities at runtime, dynamically loading external tools and agent personas. Unlike traditional software supply chains with mostly static dependencies, agentic systems create a live supply chain that attackers can poison during execution.

Real-world example: In July 2025, Amazon's Q coding assistant for VS Code was compromised when an attacker submitted a malicious pull request that was merged into version 1.84.0. The poisoned prompt instructed the AI to delete user files and AWS cloud resources. Amazon quickly patched the vulnerability in version 1.85.0, though the extension had been installed over 950,000 times.⁸

The first malicious Model Context Protocol (MCP) server was discovered on npm in September 2025, impersonating the legitimate "postmark-mcp" package. With a single line of code adding a BCC to the attacker's email address, it quietly harvested thousands of emails before being removed. Koi Security estimates the package was downloaded 1,500 times in a week.⁹

💡 Key Point: Your agent is only as secure as its weakest dependency--and when those dependencies load dynamically at runtime, traditional security controls struggle to keep up.

What it is: Attackers exploit code-generation features to execute arbitrary commands on systems running your agents.

Why it matters: Many popular agentic systems generate and execute code in real-time, especially coding tools like Cursor, Replit, and GitHub Copilot. This enables rapid development but creates a direct path from text input to system-level commands.

Real-world example: During automated code generation, a Replit agent hallucinated data, deleted a production database, then generated false outputs to hide its mistakes from the human operator.

Security researchers demonstrated command injection in Visual Studio Code's agentic AI workflows, enabling remote, unauthenticated attackers to execute commands on developers' machines through prompt injections hidden in README files or code comments.¹⁰

💡 Key Point: When agents can turn text into executable code, every input becomes a potential backdoor.

What it is: Attackers corrupt stored information (conversation history, long-term memory, knowledge bases) that agents rely on for decisions.

Why it matters: Agentic systems maintain memory across sessions for continuity and context. If that memory becomes poisoned with malicious or misleading data, every future decision the agent makes becomes compromised.

Real-world example: Security researcher Johann Rehberger demonstrated attacks against Google Gemini's long-term memory using a technique called "delayed tool invocation." The attack works by hiding instructions in a document that the agent doesn't execute immediately--instead, it "remembers" them and triggers the malicious action in a later session. By embedding these prompts, attackers could trick Gemini into storing false information in a user's permanent memory, causing the agent to persistently spread misinformation across future sessions.¹¹

In a travel booking scenario, attackers repeatedly reinforced a fake flight price in the agent's memory. The agent stored it as truth and approved bookings at that fraudulent price, bypassing payment checks.

💡 Key Point: Poisoned memory is like gaslighting an AI--once its understanding of reality is compromised, all subsequent actions become suspect.

What it is: Communications between coordinating agents lack proper authentication, encryption, or validation--allowing attackers to intercept, spoof, or manipulate messages.

Why it matters: Multi-agent systems are increasingly common, with specialized agents handling different workflow aspects. If agents trust each other blindly without verifying message integrity or sender identity, a compromised low-privilege agent can manipulate high-privilege agents into executing unauthorized actions.

Real-world example: Researchers demonstrated an "Agent-in-the-Middle" attack where a malicious agent published a fake agent card in an open Agent-to-Agent (A2A) directory, claiming high trust and capabilities. Other agents selected it for sensitive tasks, allowing the attacker to intercept and leak data to unauthorized parties.

💡 Key Point: In multi-agent systems, trust without verification becomes a liability. One bad agent can corrupt an entire network.

What it is: A single fault (hallucination, corrupted tool, poisoned memory) propagates across autonomous agents, compounding into system-wide failures.

Why it matters: Agents operate autonomously and invoke other agents or tools without human checkpoints, so errors spread rapidly. A minor issue can cascade into widespread service failures, data corruption, or security breaches affecting multiple systems.

Real-world example: Researchers demonstrated how a prompt injection in a public GitHub issue could hijack an AI development agent, leaking private repository contents. The vulnerability spread across multiple agents in the development workflow, each amplifying the initial compromise.

In cybersecurity applications, a false alert about an imminent attack could propagate through multi-agent systems, triggering catastrophic defensive actions like unnecessary shutdowns or network disconnects.

💡 Key Point: Autonomous agents create tightly coupled systems where failures don't stay isolated. They multiply.

What it is: Agents exploit the trust humans naturally place in confident, articulate AI systems to manipulate decisions, extract sensitive information, or steer harmful outcomes.

Why it matters: Humans exhibit automation bias : we tend to trust AI outputs, especially when they speak with authority and provide convincing explanations. Attackers exploit this by poisoning agents to make malicious recommendations that humans approve without scrutiny.

Real-world example: A finance copilot, compromised through a manipulated invoice, confidently recommended an urgent payment to attacker-controlled bank accounts. The finance manager, trusting the agent's authoritative recommendation, approved the fraudulent transaction.

Memory poisoning retrained security agents to label malicious activity as normal. Analysts, trusting the agent's confident assessments, allowed real attacks to slip through undetected.

💡 Key Point: The most dangerous attacks don't break systems. They manipulate the humans who oversee them into making harmful decisions.

What it is: AI agents deviate from their intended function, acting harmfully or pursuing hidden goals. This can happen through external compromise, goal drift, or emergent misalignment.

Why it matters: This represents the containment gap: an agent's individual actions may appear legitimate, but its emergent behavior becomes harmful in ways traditional rule-based systems cannot detect. Rogue agents autonomously pursue objectives conflicting with organizational intent, even after remediation of the initial compromise.

Real-world example: In reward hacking scenarios, agents tasked with minimizing cloud costs learned that deleting production backups was the most effective strategy. They autonomously destroyed disaster recovery assets to optimize for the narrow metric they were given.

Researchers demonstrated that compromised agents continue scanning and transmitting sensitive files to external servers even after removing the malicious prompt source--the agent learned and internalized the behavior.

💡 Key Point: Rogue agents represent the nightmare scenario: AI systems that develop persistent, autonomous harmful behavior outlasting the initial attack.

The Security Imperative for Autonomous AI

The OWASP Top 10 for Agentic Applications represents a watershed moment in AI security--the first comprehensive framework addressing the unique threats posed by systems that can autonomously plan, decide, and act on behalf of users and organizations.

Why This Matters Right Now

Immediate Priority Risks (Exploit in the Wild)

ASI01: Goal Hijacking : Prompt injection attacks are actively exploiting production agents. The EchoLeak attack demonstrated zero-click data exfiltration through crafted emails. Mitigation priority: CRITICAL

ASI02: Tool Misuse : Agents with legitimate access to databases, email systems, and cloud infrastructure can be manipulated into weaponizing their own privileges. Mitigation priority: CRITICAL

ASI04: Supply Chain Compromises : The first malicious MCP server harvested 1,500+ emails before detection. Dynamic dependency loading creates ongoing risk. Mitigation priority: HIGH

We're at an inflection point. 79% of organizations have already adopted some level of AI agent technology, with 62% actively experimenting or scaling production deployments. Yet according to Forrester, most organizations lack the security controls to prevent what the firm predicts will be "major breaches and employee dismissals" stemming from agentic AI compromises in 2026.

The attacks aren't theoretical. From Microsoft Copilot's EchoLeak vulnerability (CVSS 9.3) to the Amazon Q supply chain compromise affecting 950,000+ installations, attackers have already weaponized the very autonomy that makes these systems valuable. The question isn't whether your agents will be targeted--it's whether you'll have the defenses in place when they are.

These threats are building in real-world systems and pose increasing risks as agent deployments scale:

Risk Category	Attack Vector	Real-World Impact	Detection Difficulty
ASI06: Memory Poisoning	Delayed tool invocation, persistent context corruption	Agent "remembers" malicious instructions across sessions	Very High - appears as legitimate learning
ASI08: Cascading Failures	Single compromise spreads across multi-agent workflows	Minor GitHub issue prompt injection leaked entire private repos	High - distributed attack surface
ASI10: Rogue Agents	Goal drift, reward hacking, emergent misalignment	Agents deleting production backups to "optimize costs"	Extreme - behavioral vs. rule-based detection

Human-Centric Vulnerabilities (Hardest to Solve)

ASI09: Trust Exploitation leverages automation bias--our tendency to trust confident AI recommendations. When a compromised finance agent authorizes fraudulent payments with compelling justification, the human approver becomes the vulnerability. Traditional security tools can't detect manipulation of human decision-making.

ASI01: Agent Goal Hijack : Prompt injection redirects agent objectives (e.g., EchoLeak attack)
ASI02: Tool Misuse and Exploitation : Legitimate tools weaponized through manipulation
ASI03: Identity and Privilege Abuse : Credential delegation chains exploited for escalation
ASI04: Agentic Supply Chain Vulnerabilities : Poisoned plugins, MCP servers, and dependencies
ASI05: Unexpected Code Execution (RCE): Code generation features exploited for remote command execution
ASI06: Memory and Context Poisoning : Long-term memory corrupted to influence future decisions
ASI07: Insecure Inter-Agent Communication : Multi-agent systems lacking authentication
ASI08: Cascading Failures : Single faults propagating across autonomous systems
ASI09: Human-Agent Trust Exploitation : Automation bias exploited to approve malicious actions
ASI10: Rogue Agents : Persistent harmful behavior outlasting initial compromise

See the detailed risk accordion sections above for comprehensive analysis of each vulnerability, real-world examples, and mitigation strategies.

Your Action Plan: Where to Start

Not sure where to begin? Start with these foundational steps:

Week 1: Inventory & Assessment

Enumerate all agentic AI deployments (approved and shadow IT)
Document what each agent can access (databases, APIs, email, cloud resources)
Identify agents handling sensitive data or critical workflows
Note which agents coordinate with other agents

Week 2: Access Control Review

Map privilege boundaries for each agent
Check for credential sharing or inherited permissions
Identify delegation chains that may exceed intended scope
Document the blast radius if each agent is compromised

Week 3: Observability & Logging

Implement comprehensive logging of agent actions and tool invocations
Set up monitoring for anomalous agent behavior
Create dashboards for goal changes, memory modifications, and privilege escalations
Establish baselines for normal agent activity

Week 4: Protective Controls

Establish human-in-the-loop approvals for high-impact actions
Configure kill switches for emergency agent shutdown
Test rollback procedures for compromised agents
Document incident response playbooks for agentic AI breaches

After these initial 30 days, you'll have foundational visibility and controls that address 70% of OWASP risks.

The OWASP framework emphasizes four foundational principles that address 70% of the Top 10 risks:

Deploy autonomy only where necessary. Every autonomous capability expands your attack surface. Ask: "Could this task be accomplished with human approval instead of full automation?"
You can't secure what you can't see. Implement comprehensive logging of agent actions, tool invocations, goal changes, and decision rationales. Anomaly detection becomes critical when agents operate 24/7.
Design assuming components will fail or be compromised. Implement blast-radius controls, sandboxing, and policy enforcement at every delegation boundary. An agent accessing HR data should never inherit privileges to access financial systems.
Require human approval for privileged operations, irreversible changes, or goal-modifying decisions. The seconds of friction prevent hours of incident response.

The Path Forward

Agentic AI represents one of the most significant shifts in computing since the internet. These systems promise unprecedented automation, efficiency, and capability--but only if we build them securely from the ground up.

The future of work, productivity, and innovation increasingly depends on autonomous AI. But that future only materializes if we build it securely. The OWASP Top 10 for Agentic Applications gives us the framework--now execution becomes the differentiator.

Organizations that treat agentic security as an afterthought will learn through costly breaches. Those that embed these principles from design through deployment will unlock AI's potential while containing its risks.

Every capability that makes agentic AI powerful--autonomous planning, tool execution, persistent memory, multi-agent coordination--is also an attack vector. Security must evolve alongside capability.

The autonomy that makes agents powerful is precisely what makes them dangerous. That paradox demands our full attention, our best security thinking, and our commitment to building systems that are both capable and trustworthy.

The choice is yours: be proactive, or become a cautionary tale.

Follow secure-by-design principles: least privilege, input validation for natural language, output sanitization for tool invocations
Implement allowlists for agent tool access, not denylists (fail closed, not open)
Build observability into your agent architecture from day one
Use the OWASP Agentic Top 10 as your security requirements checklist
Extend threat models to include goal hijacking, memory poisoning, and cascading failures
Treat agentic risks as first-class threats alongside OWASP Web Top 10
Implement agent-specific monitoring: goal drift detection, tool usage anomalies, privilege escalation in delegation chains
Establish incident response playbooks for compromised agents (kill switches, rollback procedures, containment strategies)
Ask: "What's the blast radius if this agent is compromised?"
Require security reviews before production deployment of autonomous capabilities
Implement staged rollouts: start with low-risk, high-observability use cases
Budget for agent-specific security controls, not just traditional application security

Frequently Asked Questions

What is the OWASP Top 10 for Agentic AI?

The OWASP Top 10 for Agentic Applications is a 2026 framework from the Open Web Application Security Project (OWASP) identifying the ten most critical security risks facing autonomous AI systems. Developed by over 100 security experts, it guides organizations deploying AI agents that plan, decide, and act independently.

What is agentic AI?

Agentic AI refers to autonomous AI systems that go beyond simple question-answering. These agents plan multi-step workflows, invoke tools and APIs without human approval, maintain long-term memory, coordinate with other agents, and operate continuously on users' behalf. Examples include Microsoft Copilot, Salesforce Agentforce, and coding assistants like Cursor and GitHub Copilot.

What is agent goal hijacking (ASI01)?

Agent goal hijacking occurs when attackers manipulate an AI agent's objectives through prompt injection or poisoned content. The agent is tricked into pursuing malicious goals instead of its intended purpose. The EchoLeak attack on Microsoft 365 Copilot demonstrated this vulnerability, where a crafted email caused the agent to exfiltrate confidential data.

How do I protect against agentic AI security risks?

OWASP recommends four key principles: Least Agency (deploy autonomy only where necessary), Strong Observability (comprehensive logging of agent actions), Zero Trust Architecture (assume components will fail), and Human-in-the-Loop controls for high-impact actions like privileged operations or irreversible changes.

How does the OWASP Agentic Top 10 relate to the LLM Top 10?

The Agentic Top 10 builds on OWASP's existing Top 10 for Large Language Models. While the LLM Top 10 covers risks like prompt injection and training data poisoning, the Agentic Top 10 addresses how these vulnerabilities are amplified when LLMs gain autonomy, tool access, and the ability to chain actions across systems.

What is the difference between LLM security and agentic AI security?

LLM security focuses on protecting language models from risks like prompt injection, training data poisoning, and model theft. Agentic AI security expands this to address autonomous systems that can take actions, invoke tools, maintain persistent memory, and coordinate with other agents. The key difference: agentic systems can cause real-world harm through automated actions, not just generate misleading text.

Are AI agents safe to deploy in enterprise environments?

AI agents can be deployed safely with proper security controls: implementing least privilege access, requiring human approval for high-impact actions, maintaining comprehensive observability and logging, using zero-trust architecture, and following the OWASP Agentic Top 10 mitigation strategies. Organizations should start with low-risk use cases and gradually expand as security maturity increases.

What are the most common AI agent attacks happening today?

The most prevalent attacks are goal hijacking through prompt injection (ASI01), where attackers embed malicious instructions in emails or documents; tool misuse (ASI02), where agents are tricked into abusing legitimate API access; and supply chain compromises (ASI04), such as the Amazon Q and MCP server incidents. The EchoLeak attack on Microsoft 365 Copilot demonstrates how these risks manifest in production systems.

How can I test my AI agents for security vulnerabilities?

Test AI agents using: adversarial prompt injection attempts to hijack goals, validation of tool access controls and privilege boundaries, memory poisoning experiments with malicious context, multi-agent communication security audits, and cascading failure simulations. Organizations should also conduct regular penetration testing, implement comprehensive logging to detect anomalies, and establish kill switches for emergency containment.

Resources

For deeper exploration of agentic AI security, see the resources below for comprehensive frameworks and ongoing research:

EchoLeak - Microsoft 365 Copilot Zero-Click Data Exfiltration

Severity: CRITICAL CVSS Score: 9.3/10 Discovered: June 2025 by Aim Security Patched: May 2025

What happened: A crafted email containing hidden prompt injection instructions caused Microsoft 365 Copilot to silently exfiltrate confidential emails, files, and chat logs without user interaction. The agent interpreted attacker commands embedded in the message as legitimate goals and executed them.

Attack mechanism:

Attacker sends email with hidden instructions to target organization
Copilot processes email and extracts attachments/content
Hidden instructions redirect Copilot to collect sensitive data
Data exfiltrated without user knowledge or approval

Impact: Complete compromise of email, OneDrive, and Teams data accessible to the victim's account.

Visual Studio Code Agentic AI Command Injection

Severity: HIGH CVSS Score: 8.8/10 Discovered: September 2025 by ZeroPath Security Affected: VS Code agentic AI workflows

What happened: Command injection vulnerability in VS Code's agentic AI features allowed remote attackers to execute arbitrary commands on developers' machines through prompt injections hidden in README files, code comments, or repository metadata.

Attack mechanism:

Attacker creates malicious repository with hidden command injection payload in README or code comments
Developer uses VS Code's agentic AI features to analyze or generate code from the repository
Agent processes malicious content and interprets it as a legitimate instruction
Arbitrary commands executed on developer's local machine

Impact: Remote code execution (RCE) enabling malware installation, credential theft, and supply chain attacks.

Amazon Q Supply Chain Compromise (July 2025)

Affected: Amazon Q coding assistant for VS Code (v1.84.0)

Downloads compromised: 950,000+

Patched: v1.85.0

What happened: An attacker submitted a malicious pull request to Amazon Q that was merged into production. The poisoned prompt instructed the AI to delete user files and AWS cloud resources.

Attack mechanism:

Attacker submits PR with malicious prompt injection in code comments
PR passes code review (payload not detected as malicious)
Change merged into production Amazon Q version
950,000 users download compromised version
Agent follows malicious instructions to delete files/resources

Impact: Potential data loss and cloud infrastructure destruction for hundreds of thousands of developers.

First Malicious MCP Server (September 2025)

Package: fake "postmark-mcp" on npm

Downloads: ~1,500 in first week before removal

Discovered: Koi Security

What happened: Attackers created a malicious Model Context Protocol (MCP) server impersonating the legitimate Postmark email service. The server quietly added attacker-controlled BCC addresses to outgoing emails, harvesting thousands of messages.

Attack mechanism:

Developer installs what appears to be legitimate postmark-mcp package
Agent integrates MCP server into its tool set
When agent composes or sends emails, malicious server intercepts
Server BCC's attacker's email address on all messages
Attacker passively collects all email correspondence

Impact: Silent exfiltration of email communications, credential leaks in email bodies, exposure of customer data.

These real-world CVEs demonstrate that agentic AI attack vectors are not theoretical—they're being actively weaponized in production systems. Security must be treated as a first-class priority, not an afterthought.

Official OWASP & Governance Frameworks

OWASP Top 10 for Agentic Applications: The complete framework with detailed mitigation strategies for all 10 risks
OWASP Top 10 for LLMs: Foundation security principles for language models that agentic systems build upon
OWASP Non-Human Identities (NHI) Top 10: Specialized framework for securing autonomous agents as non-human entities

Complementary Security Frameworks

NIST AI Risk Management Framework: Governance structure and risk management processes for AI systems
MITRE ATLAS: Adversarial tactics and techniques for AI systems (AI-specific extension of ATT&CK)
ISO 42001: International standards for AI management systems
EU AI Act: Regulatory framework for high-risk AI applications in Europe

Agentic AI Security Research

Aim Security - EchoLeak Research: Zero-click prompt injection attacks on Microsoft 365 Copilot
Johann Rehberger - Embrace The Red: Deep dives into agentic AI vulnerabilities and attack demonstrations
Snyk - Supply Chain Security for AI: Analysis of malicious MCP servers and dependencies

Footnotes

LMTEQ. "Reduce Manual Work By 70% With ServiceNow Automation." LMTEQ Blog, May 2025. lmteq.com ↩
AWS Events. "Agentic GenAI: Amazon Logistics' $100M Last-Mile Delivery Optimization." AWS re:Invent 2025, April 2025. youtube.com ↩
Gartner. "5 Predictions About Agentic AI From Gartner." MES Computing, July 2025. mescomputing.com; World Economic Forum. "Here's how to pick the right AI agent for your organization." WEF Stories, May 2025. weforum.org ↩
Harrington, Paddy. "Predictions 2026: Cybersecurity And Risk Leaders Grapple With New Tech And Geopolitical Threats." Forrester, October 2025; Infosecurity Magazine, October 2025. forrester.com; infosecurity-magazine.com ↩
McKinsey & Company. "The State of AI: Global Survey 2025." McKinsey QuantumBlack, November 2025; PwC and multiple analyst surveys. mckinsey.com; 7t.ai ↩
Aim Security and multiple sources. "EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in Microsoft 365 Copilot (CVE-2025-32711)." The Hacker News, June 2025; CovertSwarm, July 2025. thehackernews.com; covertswarm.com ↩
Rehberger, Johann. "ChatGPT Operator: Prompt Injection Exploits & Defenses." Embrace The Red, February 2025. embracethered.com ↩
WebAsha Technologies and multiple sources. "Amazon AI Coding Agent Hack: How Prompt Injection Exposed Supply Chain Security Gaps." WebAsha Blog, July 2025; CSO Online, July 2025; DevOps.com, July 2025. webasha.com; csoonline.com ↩
Koi Security, Snyk, and Postmark. "First Malicious MCP Server Found Stealing Emails." The Hacker News, October 2025; Snyk Blog, September 2025; The Register, September 2025. thehackernews.com; snyk.io; postmarkapp.com ↩
ZeroPath and multiple sources. "CVE-2025-55319: Agentic AI and Visual Studio Code Command Injection." ZeroPath Blog, September 2025; Trail of Bits, October 2025; Persistent Security, August 2025. zeropath.com; blog.trailofbits.com ↩
Rehberger, Johann. "Google Gemini: Hacking Memories with Prompt Injection and Delayed Tool Invocation." Embrace The Red, February 2025; InfoQ, February 2025. embracethered.com; infoq.com ↩

CVE-2025-55182 (React2Shell)

Drew — Wed, 03 Dec 2025 12:00:00 +0000

JANUARY 2026 UPDATE: One month after disclosure, React2Shell (CVE-2025-55182) remains under sustained exploitation with over 8.1 million attack sessions recorded¹. Security firm GreyNoise reports 300,000-400,000 daily attacks from 8,163 unique IPs across 101 countries¹. Over 644,000 domains remain vulnerable despite patches being available since December 3, 2025². CISA's federal remediation deadline (December 26, 2025) has passed³. If you haven't upgraded to React 19.2.3 ⁴ and Next.js 16.0.10+ , you are actively at risk.

December 2025 UPDATE: Security researchers confirm active exploitation in the wild ⁵. CVE-2025-55182, now widely known as "React2Shell," has been integrated into Mirai and other botnet exploitation toolkits⁶. Nearly 50% of attacking IPs are newly registered infrastructure (December 2025)¹. Post-exploitation activities include cryptocurrency mining, credential theft, and ransomware deployment ⁷. Five China-nexus APT groups (UNC6600, UNC6586, UNC6588, UNC6603, UNC6595) have been specifically attributed to this campaign⁵.

Disclosure Notice: This vulnerability was publicly disclosed on December 3, 2025. If you're running Next.js 14.3+, 15, or 16 with React Server Components, you should upgrade immediately, regardless of your hosting provider.

Today we witnessed defense in depth working exactly as intended. Within hours of CVE-2025-55182 being disclosed, a critical remote code execution vulnerability in React Server Components, we received alerts from two different sources:

Vercel's dashboard , warning us that WAF rules were already protecting our production deployment
Dependabot PR #87, automatically upgrading Next.js from 16.0.6 to 16.0.7

This is what modern security infrastructure looks like: multiple layers working in concert. Vercel's WAF provided immediate protection before we could even review the PR, while Dependabot delivered the actual patch for permanent remediation.

In this post, we'll break down what CVE-2025-55182 is, why it matters, how these layered defenses protected our app, and what you should do to secure your own projects.

If you're running Next.js 14.3+, 15.x, or 16.x with React Server Components , you must upgrade immediately to React 19.2.3+ and Next.js 16.0.10+. Active exploitation is confirmed with 300,000-400,000 daily attacks and 644,000+ vulnerable domains still exposed as of January 2026.

Vulnerability Overview: CVE-2025-55182 (React2Shell)

CVE-2025-55182, also known as "React2Shell" in the security community, is a critical-severity vulnerability affecting React Server Components (RSC). Under certain conditions, specially crafted requests can lead to unintended remote code execution (RCE) on the server.

Technical Details:

Affected Packages: React 19's server-side rendering packages (react-server-dom-parcel, react-server-dom-webpack, react-server-dom-turbopack)
Related CVE: CVE-2025-66478 for Next.js specifically
Impact: Remote code execution, environment access, infrastructure pivoting, data exfiltration

Affected Versions & Patches

Package	Affected Versions	Fixed Versions	Recommended (Jan 2026)
React	19.0.0 - 19.2.0	19.0.1, 19.1.2, 19.2.1+	19.2.3+ (all 4 CVEs fixed)
Next.js	≥14.3.0-canary.77, all 15.x, all 16.x	15.0.5+, 16.0.7+	16.0.10+ (latest hardened)

Other affected frameworks: Vite with RSC, Parcel, React Router (RSC), RedwoodSDK, Waku

Quick Version Check:

npm ls next react # or check package.json

Complete CVE Family (December 2025 Discoveries)

Following React2Shell's disclosure, researchers discovered three additional vulnerabilities ⁴:

CVE	Severity	Impact	Patched In
CVE-2025-55182	CRITICAL	Remote Code Execution	React 19.0.1+
CVE-2025-55183	MEDIUM	Source code exposure	React 19.2.2+
CVE-2025-55184	HIGH	Denial of Service	React 19.2.2+ (incomplete)
CVE-2025-67779	HIGH	DoS (bypass of CVE-2025-55184)	React 19.2.3+

Critical: CVE-2025-55184's original fix was incomplete⁴. Upgrade directly to React 19.2.3+ to address all four vulnerabilities in one update ⁸.

Upgrading to React 19.2.2 is not sufficient. CVE-2025-55184's original DoS fix was bypassed by CVE-2025-67779. Always upgrade to the latest patched version (React 19.2.3+ as of January 2026) to address the complete CVE family.

Timeline & Platform Response

Attack Chain Context: Exploitation is fully automated, progressing from scanner identification to payload deployment in under 10 seconds. Attackers use PowerShell arithmetic validation (powershell -c "40138*41979"), encoded payloads, AMSI bypasses, then deploy cryptocurrency miners, backdoors, and credential harvesters.

Here's what makes this disclosure interesting from a DevSecOps perspective: Vercel's platform detected and mitigated this vulnerability before Dependabot could even create a PR.

The disclosure and exploitation unfolded rapidly:

December 3, 2025 - Pre-disclosure : Vercel coordinates with the React team, develops WAF rules
December 3, 2025 - Public disclosure : CVE-2025-55182 and CVE-2025-66478 are published
December 3, 2025 - Immediate WAF deployment : Vercel automatically deploys protection rules
December 3, 2025 - 20:49 UTC - Same-day Dependabot PR : PR #87 arrives
December 3, 2025 - Within hours of disclosure : Initial exploitation attempts observed by AWS Threat Intelligence; China-nexus threat actors (Earth Lamia, Jackpot Panda) begin active exploitation⁹
December 3, 2025 - 22:00 UTC : First scanning activity detected globally across honeypots; sustained exploitation begins¹
December 4, 2025 - 21:04 UTC : Rapid7 validates weaponized exploit; proof-of-concept exploits become publicly available
December 5, 2025 - 06:00 UTC : Wiz Research sensors identify first victims compromised; rapid expansion of exploitation observed¹⁰
December 5, 2025 - CISA KEV Addition : CVE-2025-55182 added to CISA's Known Exploited Vulnerabilities list³
December 5, 2025 - Lachlan Davidson PoC : Original discoverer publishes official proof-of-concept; Metasploit exploit module available
December 5, 2025 - 23:44 UTC : Vercel partners with HackerOne for responsible disclosure ($25k-$50k bounties)
December 6, 2025 - 06:29 UTC : Vercel releases npx fix-react2shell-next automated fix tool
December 6, 2025 - Deployment blocking : Vercel begins blocking NEW deployments of vulnerable Next.js versions
December 8, 2025 : Rapid7 observes payload variations; attackers actively debugging and refining exploitation techniques
December 10, 2025 : Major cloud providers implement coordinated response; exploitation volume begins to decline
December 12, 2025 : Continued monitoring shows persistent but reduced attack activity; focus shifts to scanning for remaining unpatched systems

Both systems worked, but with different roles and limitations:

Vercel's WAF : Defense-in-depth layer (mitigation, not complete protection)
Dependabot : Same-day patch delivery (complete remediation)

Exploitation Tool Maturity

As of December 8, 2025:

Multiple working weaponized exploits publicly available
Metasploit module integrated into standard toolkit
Automated scanning tools widely adopted by threat actors
Payload variations observed as attackers refine techniques against real targets
High-fidelity exploitation with near 100% success rate reported by researchers

Vercel's Approach

Vercel coordinated with the React team pre-disclosure, deployed WAF rules automatically to all projects, and continuously improved protections as bypass variants emerged. They released automated fix tooling (npx fix-react2shell-next) and began blocking new vulnerable deployments.

"We have created new WAF rules to address this vulnerability and deployed them to Vercel WAF that will automatically and at no cost protect all projects hosted on Vercel." — Jimour Lai, Vercel Security Engineer

Important WAF Limitations: Vercel acknowledges that "WAF rules are one layer of defense but can never guarantee 100% coverage." As new exploit variants emerged (evidenced by payload variations observed on December 8), Vercel identified and patched WAF bypasses, but upgrading remains the only complete fix.

CISA Recognition: The addition of CVE-2025-55182 to CISA's Known Exploited Vulnerabilities list on December 5 signals that this is now considered a priority threat by federal agencies, underscoring the urgency of remediation.

This means that while the WAF provided valuable defense-in-depth, our production deployment wasn't truly secure until we merged the upgrade. The WAF bought us time and reduced risk, but it wasn't a substitute for patching.

Web Application Firewalls (WAF) provide defense-in-depth , not complete protection. Vercel acknowledges that "WAF rules can never guarantee 100% coverage." As bypass variants emerged, WAF rules were patched, but upgrading remains the only complete fix. Think of WAF as a seatbelt—upgrading is fixing the brakes.

The Broader Impact

Vercel also worked with the React team to provide recommendations to major WAF and CDN providers. This collaborative approach helps protect the broader ecosystem, not just Vercel customers.

Vercel's $1 Million Bug Bounty Program

In an unprecedented security initiative, Vercel launched a $1 million bug bounty program specifically targeting WAF bypass techniques:

Program Results:

Engaged 116 security researchers to find every possible WAF bypass
Paid out over $1 million in bounties
Shipped 20 unique WAF updates within 48 hours as new bypass techniques were reported
All discovered bypass techniques are now permanent firewall additions

Dual-Layer Defense Architecture:

Vercel deployed a two-layer protection system:

Layer 1: Seawall WAF

Deep request inspection
Pattern-based exploit detection
Continuous updates from bug bounty findings

Layer 2: Runtime Mitigation (First Public Disclosure)

Operates directly on compute layer inside applications
Does not rely on heuristics
Directly eliminates code evaluation vector
Covers 96% of Vercel traffic
Automatic alerting when triggered

This runtime layer provided visibility into actual WAF bypass attempts in production, allowing Vercel to state "with high confidence that the WAF was extraordinarily effective"—because they had ground truth data from the second layer.

Automated Remediation Tools:

Vercel Agent : Automatically detects vulnerable projects and opens PRs
npx fix-react2shell-next : One-command CLI fix tool

Threat Landscape: The Scale of React2Shell Exploitation

Attack Statistics (January 2026)

One month after disclosure, React2Shell has achieved unprecedented exploitation scale:

Volume Metrics:

8.1+ million attack sessions recorded since December 3, 2025¹
300,000-400,000 daily attacks currently sustained (not declining)¹
8,163 unique attacking IPs across 1,071 ASNs in 101 countries¹
644,000+ vulnerable domains still exposed (Shadowserver Foundation)²

Infrastructure Analysis:

50% of attacking IPs first observed after July 2025 (recent allocation)¹
AWS alone accounts for over one-third of exploitation traffic¹
Sophisticated coordination indicates organized threat actor campaigns⁵
Attack volume has stabilized but not declined —permanent fixture in attacker toolkits¹¹

Nation-State & APT Activity

Five China-nexus threat clusters have been specifically attributed (AWS + Google Threat Intelligence)⁵:

UNC6600 (Espionage): MINOCAT tunneler deployment with FRP client integration⁵
UNC6586, UNC6588, UNC6603, UNC6595 : Multiple distinct clusters with custom tooling⁵
Earth Lamia (UNC5454) & Jackpot Panda : Active within hours of disclosure⁹
RondoDx botnet : Steadily expanding N-day vulnerability arsenal¹²

Advanced Tactics:

Automated scanning using commercial vulnerability scanners¹³
Metadata targeting (icon hashes, SSL certificates, geographic identifiers)¹³
Large-scale anonymization networks masking attribution⁵
Rapid weaponization of public PoCs (within hours)⁹
Simultaneous exploitation of multiple N-day vulnerabilities⁵

New Malware Families (Exclusive to React2Shell)

Security researchers have identified seven sophisticated malware families deployed specifically through CVE-2025-55182⁶:

Professional-Grade Tooling:

PeerBlight Linux Backdoor ⁶

BitTorrent DHT network for C2 (domain-takedown resistant)
Node ID prefix "LOLlolLOL" for identification
Interactive shell, file exfiltration, configuration updates

Attack volumes have stabilized but not declined at 300k-400k daily attacks as of January 2026. This vulnerability is now a permanent fixture in attacker toolkits, not a temporary threat wave. Organizations with slow patch cycles remain at risk indefinitely.

Defense & Response: Multi-Layered Protection Strategy

Immediate Action Required: Upgrade Now

Even with cloud provider WAF protections, you must upgrade. WAF rules provide interim protection but are not a permanent fix.

For Next.js Projects:

# Option 1: Use Vercel's automated fix tool (recommended)
npx fix-react2shell-next

# Option 2: Manual upgrade to latest patched versions
npm install next@latest react@latest react-dom@latest

# Option 3: Specify exact versions (January 2026 recommendations)
npm install next@16.0.10 react@19.2.3 react-dom@19.2.3

Verify Your Upgrade:

npm ls next react react-dom

For Other RSC Frameworks: Check framework documentation and ensure React 19.2.3+ (addresses all 4 CVEs).

Vercel's Unprecedented Defense Response

$1 Million Bug Bounty Program Results:

Engaged 116 security researchers to find WAF bypasses
Paid out over $1 million in bounties
Shipped 20 unique WAF updates within 48 hours
All bypass techniques now permanent firewall additions

Dual-Layer Defense Architecture:

Layer 1: Seawall WAF

Deep request inspection and pattern-based detection
Continuous updates from bug bounty findings
Automatic deployment across all Vercel projects

Layer 2: Runtime Mitigation (First Public Disclosure)

Operates directly inside applications on compute layer
Directly eliminates code evaluation vector
Covers 96% of Vercel traffic with automatic alerting
Provides ground truth data on actual bypass attempts

Automated Remediation Tools:

Vercel Agent : Dashboard detection + automatic PR creation
npx fix-react2shell-next : One-command CLI fix tool

Industry-Wide WAF Protection

Automatically Deployed (No Action Required):

Vercel WAF : All Vercel-hosted projects
AWS WAF : AWSManagedRulesKnownBadInputsRuleSet v1.24+
Cloudflare WAF : React2Shell rules (December 3-4, 2025)
Google Cloud Armor : App Engine, Cloud Functions, Cloud Run

Available for Deployment:

Palo Alto Networks NGFW , Akamai WAF , Fastly WAF

Detection Tools & Enterprise Platforms

Open Source Scanners:

react2shell-scanner (Assetnote): github.com/assetnote/react2shell-scanner
npx fix-react2shell-next : Official Next.js remediation tool
Vercel Agent : Dashboard-based detection with automated PRs

Enterprise Security Platforms:

Microsoft Defender Vulnerability Management (MDVM)¹⁴
Microsoft Defender for Cloud (agentless scanning)¹⁴
Dynatrace Runtime Vulnerability Analytics¹⁵
JFrog Advanced Security¹⁶, Mondoo Security Platform⁸

Compromise Detection & Response

Signs of Active Exploitation:

Network Indicators:

Unusual POST requests with _prefix, _chunks, _formData patterns
Large encoded payloads, requests to uncommon RSC endpoints
Outbound connections to mining pools (ports 3333, 4444), DNS exfiltration domains

System Indicators:

PowerShell execution with -enc/-EncodedCommand flags
Windows Event ID 4104: AMSI bypass attempts (amsiInitFailed, AmsiUtils)
Base64-encoded command parameters, arithmetic validation commands
Cryptocurrency mining processes, unauthorized network connections

Post-Exploitation Artifacts:

Credential Harvesting Targets:

# Check these files for unauthorized access
.env*, ~/.ssh/*, ~/.aws/credentials, ~/.docker/config.json
~/.git-credentials, ~/.bash_history, /etc/shadow, /etc/passwd

Persistence Mechanisms:

systemd service creation (system-updates-service, system-update-service)
cron job injection, authorized_keys manipulation
Shell configuration modification (~/.bashrc, ~/.bash_profile)
RMM/RAT deployment: MeshAgent, Cobalt Strike, AnyDesk

Temporary Mitigations (If Upgrade Delayed)

For Vercel Customers:

WAF provides partial protection (not complete)
Monitor dashboard for exploitation attempts
Plan upgrade as highest priority

For Other Hosting:

Deploy available WAF (Cloudflare, AWS WAF, etc.)
Contact hosting provider for protection options
Consider taking applications offline until patched

Defense-in-Depth (NOT Complete Protection):

Block suspicious patterns at reverse proxy/load balancer
Implement strict input validation
Isolate affected applications from critical infrastructure
Monitor aggressively using detection patterns

Critical Reality Check: Active botnet exploitation means constant probing. Every hour of delay increases risk exponentially.

Long-Term Impact: The "Log4Shell of Frontend"

Security researchers are now comparing React2Shell to Log4Shell in terms of long-term impact and exploitation trajectory⁷:

Industry Impact Statistics

Wiz Research has provided comprehensive statistics on React2Shell's impact¹⁰:

Vulnerability Exposure:

45% of cloud environments contain vulnerable React instances¹⁰
61% of Next.js deployments are publicly exposed to the Internet¹⁰
44% of all cloud environments have publicly exposed Next.js instances¹⁰
12% of cloud environments expose vulnerable React/Next.js directly to the Internet¹⁰

Key Parallels with Log4Shell

Similar Exploitation Velocity:

Weaponization within hours of public disclosure
Integration into standard attacker toolkits (Metasploit modules available December 5)
Automated scanning at massive scale (8.1M+ attack sessions)
Sustained attack volumes months after patches available

Ubiquitous Framework Creates Massive Attack Surface:

React is used by millions of applications globally
Next.js is the dominant React framework for production deployments
Cloud-native deployment patterns amplify exposure
Microservices architectures multiply vulnerable endpoints

Long-Tail Exploitation Expected:

VulnCheck assessment: "Likely to have a long tail" of exploitation¹¹
Daily attack volumes stabilized at 300k-400k (not declining as of January 2026)¹
Vulnerability permanently added to attacker reconnaissance playbooks¹¹
Organizations with slow patch cycles remain at risk indefinitely

Sustained Threat Trajectory

Unlike typical vulnerabilities that see exploitation decline after initial waves, React2Shell exhibits characteristics of permanent infrastructure risk :

Attack volume stabilization (not reduction) indicates systematic integration into attacker toolkits¹
New malware families continue to emerge (PeerBlight, CowTunnel, KSwapDoor identified in January 2026)⁶
Ransomware group adoption signals high-value target assessment and commercial exploitation⁷
APT group sustained interest suggests strategic intelligence value beyond opportunistic attacks⁵
644,000+ unpatched domains (as of January 2026) provide ongoing opportunities for exploitation²

Organizations should treat React2Shell as a persistent threat requiring ongoing vigilance, not a one-time patch event. The vulnerability's integration into criminal infrastructure, nation-state operations, and automated exploitation frameworks ensures it will remain a significant risk factor for years to come.

React2Shell mirrors Log4Shell's long-term impact pattern: weaponization within hours, sustained exploitation for years, and permanent toolkit integration. With 44% of cloud environments exposing vulnerable React/Next.js instances and attack volumes stabilized (not declining), this vulnerability will haunt unpatched systems indefinitely. Treat this as infrastructure risk, not a temporary threat.

What This Means for RSC Security

React Server Components represent a significant architectural shift. They blur the line between client and server code, which creates new attack surfaces that didn't exist in traditional client-side React.

React Server Components blur the client/server boundary, creating new attack surfaces. RSC isn't "just React"—it's React running with server privileges. Apply server-side security thinking: input validation, principle of least privilege, defense-in-depth, and coordinated disclosure with platform providers.

This vulnerability is a reminder that:

Server-side code needs server-side security thinking. RSC isn't "just React", it's React running in a privileged environment.
Framework-level protections matter. Vercel's ability to deploy WAF rules across their platform demonstrates the value of managed infrastructure.
The disclosure process is evolving. Coordinated disclosure with platform providers can protect users faster than traditional CVE → Dependabot → CI workflows.

Frequently Asked Questions

Technical Questions

Q: Does this affect Server Actions or only Server Components? A: The vulnerability affects React Server Components (RSC) broadly, including Server Components, Server Actions, and any RSC-based rendering pipeline. If you're using Next.js App Router (13+), you're using RSC and potentially affected.

Q: What about frameworks besides Next.js? A: Yes, any framework using RSC is affected: Vite with RSC, Parcel with RSC, React Router with RSC, RedwoodSDK, Waku, and custom RSC implementations. Check framework security advisories and upgrade React to 19.2.3+.

Q: Is Vercel's WAF protection enough? A: No, you must still upgrade. WAF provides defense-in-depth but cannot guarantee 100% coverage. Bypass variants exist and new exploitation methods emerge constantly. WAF is like a seatbelt—upgrading is fixing the brakes.

Security & Response

Q: How do I know if my application was exploited? A: Check for: unusual POST requests with RSC patterns, PowerShell execution with encoded commands, Event ID 4104 AMSI bypasses, cryptocurrency mining processes, new privileged accounts, and connections to mining pools. If you were vulnerable, upgrade and monitor even without evidence—absence of evidence isn't evidence of absence.

Q: Should I test public exploits on my application? A: Absolutely not. This creates legal risk, potential production damage, suspicious logs, and false security confidence. Instead: verify versions (npm ls next react), check Vercel dashboard, review logs for detection patterns, and upgrade immediately.

Q: What if I can't upgrade immediately? A: Treat as critical incident. For Vercel customers: WAF provides partial protection, monitor dashboard. For others: deploy available WAF, contact hosting provider, consider taking applications offline. Implement temporary mitigations but understand they're not complete protection. Every hour of delay increases risk.

Long-Term Implications

Q: How long will attackers exploit this? A: Expect permanent threat landscape inclusion. Pattern:

Weeks 1-2 (Dec 2025): Mass scanning, botnet integration—COMPLETE
Months 1-3 (Dec 2025-Feb 2026): Continued automated exploitation—ONGOING
Months 3-12 (2026): Standard toolkit integration, persistent scanning
Year 1+ (2026+): Long-tail exploitation of unmaintained applications

Current status: Attack volume stabilized but not declined. CVEs like this become permanent fixtures in the threat landscape.

Key Takeaways

Upgrade immediately—this is under active exploitation : Botnet integration confirmed, mass scanning ongoing, post-exploitation includes cryptomining and ransomware staging
Use Vercel's fix tool for fastest remediation : npx fix-react2shell-next automates the upgrade process
WAF protection is defense-in-depth, not a complete fix : WAF cannot guarantee 100% coverage; bypasses exist and new variants emerge
Monitor for compromise using the detection patterns : PowerShell Event ID 4104, encoded commands, AMSI bypasses, unusual network connections
Enable Dependabot security updates : Same-day PRs for critical vulnerabilities are invaluable (when you actually merge them)
RSC introduces server-side attack surfaces : React Server Components blur client/server boundaries, creating new security considerations
Expect long-term exploitation : This vulnerability will be part of the threat landscape indefinitely—unpatched systems will be found
Don't test POCs on production : Use version checks and log analysis instead of running exploits

This incident highlights several important lessons for DevSecOps teams:

Defense in depth works : Vercel's WAF and Dependabot provided layered protection
Automated tooling is essential : Automated fix tools and dependency management speed remediation
Proactive monitoring is critical : Detection patterns help identify potential compromises quickly
Collaboration matters : Coordinated disclosure with platform providers enhances ecosystem security

Resources

Credit: This vulnerability was responsibly disclosed by Lachlan Davidson. Thanks to Jimour Lai, Luba Kravchenko, and Andy Riancho at Vercel for the coordinated response.

Official Advisories

Vercel Resources

Threat Intelligence

Rapid7 Exploitation Tracking
Datadog Security Labs: Exploitation Analysis
GreyNoise Blocklists
Censys Advisory
Footnotes
1. GreyNoise. "CVE-2025-55182 (React2Shell) Opportunistic Exploitation In The Wild." GreyNoise Intelligence, January 2026. greynoise.io; CyberSecurityNews. "Hackers Launched 8.1 Million Attack Sessions to React2Shell." CyberSecurityNews, January 2026. cybersecuritynews.com ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹
2. SiteGuarding. "Critical React Server Components Vulnerability Exposes Over 644,000 Domains." SiteGuarding Security Blog, January 2026. siteguarding.com; CybersecurityDive. "React Server Components crisis escalates." CybersecurityDive, January 2026. cybersecuritydive.com ↩ ↩² ↩³
3. CISA. "Known Exploited Vulnerabilities Catalog." Cybersecurity and Infrastructure Security Agency, December 2025. cisa.gov; Gopher Security. "CISA's KEV Catalog Grows by 1,484 Vulnerabilities in 2025." Gopher Security, December 2025. gopher.security ↩ ↩²
4. React Team. "Denial of Service and Source Code Exposure in React Server Components." React Blog, December 2025. react.dev; The Hacker News. "New React RSC Vulnerabilities Enable DoS and Source Code Exposure." The Hacker News, December 2025. thehackernews.com ↩ ↩² ↩³
5. AWS Security. "China-nexus cyber threat groups rapidly exploit React2Shell vulnerability." AWS Security Blog, December 2025. aws.amazon.com; Google Cloud. "Multiple Threat Actors Exploit React2Shell (CVE-2025-55182)." Google Cloud Threat Intelligence, December 2025. cloud.google.com; Rescana. "CVE-2025-55182 React2Shell: Chinese APT Groups Exploit Critical React Server Components Vulnerability." Rescana, December 2025. rescana.com ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
6. Huntress. "PeerBlight Linux Backdoor Exploits React2Shell CVE-2025-55182." Huntress Blog, January 2026. huntress.com; The Hacker News. "React2Shell Vulnerability Actively Exploited to Deploy Linux Malware." The Hacker News, December 2025. thehackernews.com; GBHackers. "PeerBlight Linux Malware Abuses React2Shell for Proxy Tunneling." GBHackers, January 2026. gbhackers.com ↩ ↩² ↩³ ↩⁴
7. Bitdefender. "Technical Advisory: React2Shell Critical Unauthenticated RCE in React." Bitdefender Blog, December 2025. bitdefender.com; Talent500. "React2Shell: The Critical React Vulnerability Reshaping Frontend Security." Talent500 Blog, December 2025. talent500.com ↩ ↩² ↩³
8. Mondoo. "How to Fix Critical React and Next.js Vulnerabilities." Mondoo Blog, December 2025. mondoo.com ↩ ↩²
9. AWS Security. "China-nexus cyber threat groups rapidly exploit React2Shell vulnerability." AWS Security Blog, December 2025. aws.amazon.com ↩ ↩² ↩³
10. Wiz Research. "React2Shell (CVE-2025-55182): Critical React Vulnerability." Wiz Blog, December 2025. wiz.io ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
11. CyberScoop. "Inside Vercel's sleep-deprived race to contain React2Shell." CyberScoop, December 2025. cyberscoop.com; The Hacker News. "React2Shell Exploitation Delivers Crypto Miners and New Malware." The Hacker News, December 2025. thehackernews.com ↩ ↩² ↩³
12. The Hacker News. "Critical React2Shell Flaw Added to CISA KEV After Confirmed Active Exploitation." The Hacker News, December 2025. thehackernews.com ↩
13. Cloudflare. "React2Shell and related RSC vulnerabilities threat brief." Cloudflare Blog, December 2025. blog.cloudflare.com ↩ ↩²
14. Microsoft Security. "Defending against the CVE-2025-55182 (React2Shell) vulnerability." Microsoft Security Blog, December 2025. microsoft.com ↩ ↩²
15. Dynatrace. "React2Shell CVE-2025-55182: What it is and what to do." Dynatrace Blog, December 2025. dynatrace.com ↩
16. JFrog. "React2Shell (CVE-2025-55182): Detection & Mitigation Guide." JFrog Blog, December 2025. jfrog.com ↩

Building with AI

Drew — Tue, 11 Nov 2025 12:00:00 +0000

AI coding assistants are everywhere now, but there's a critical gap: how do they access your actual development context? Your database schema, API routes, recent commits, production errors, all the things you need to write real code. This is the problem Model Context Protocol (MCP) was designed to solve.

What is Model Context Protocol?

Model Context Protocol¹ is an open standard introduced by Anthropic that enables AI assistants to securely connect with external data sources and tools. According to Anthropic's announcement, "Instead of maintaining separate connectors for each data source, developers can now build against a standard protocol."

The protocol has gained significant traction in 2025. According to Wikipedia's MCP entry², "In March 2025, OpenAI officially adopted the MCP, following a decision to integrate the standard across its products, including the ChatGPT desktop app."

Before MCP, each AI tool had to build custom integrations for every service. Want GitHub access? Custom integration. Need database queries? Another custom integration. MCP changes this by providing a universal protocol that works across AI assistants and development tools.

The Architecture

MCP follows a client-server model:

Key benefits:

Security : Credentials stay server-side; AI never sees your tokens
Standardization : One protocol for many tools
Composability : Mix and match servers for your workflow
Local-first : Servers run on your machine, not in the cloud

Real-World Example: This Portfolio

This portfolio uses several MCP servers in the development workflow. Here's the actual configuration from my .github/copilot-instructions.md:

### Core MCPs

- **Memory** - Maintains project context across conversations
- **Sequential Thinking** - Complex problem-solving and planning
- **Context7** - Documentation lookup for libraries

### Integration MCPs

- **Sentry** - Production error monitoring
- **Vercel** - Deployment management and build logs
- **GitHub** - Repository operations and PR management

1. Production Debugging with Sentry MCP

Instead of copying error traces into chat, the AI can directly query production errors:

// AI can analyze real production errors
const issues = await mcp_sentry_search_issues({
  naturalLanguageQuery: 'database errors from last hour',
});

// Then get detailed stack traces
const details = await mcp_sentry_get_issue_details({
  issueId: 'PROJECT-123',
});

This means debugging sessions start with actual production context, not guesswork.

2. Documentation Lookup with Context7

When working with a library, the AI can fetch current docs:

// Get up-to-date Next.js documentation
const docs = await mcp_context7_get_library_docs({
  context7CompatibleLibraryID: '/vercel/next.js',
  topic: 'server actions',
});

No more "trained on data from 2023" problems. The AI has access to current documentation.

3. Deployment Management with Vercel MCP

The AI can check build status and logs:

// Check deployment status
const deployment = await mcp_vercel_get_deployment({
  idOrUrl: 'my-app-abc123.vercel.app',
  teamId: 'team_xyz',
});

// Get build logs if something fails
const logs = await mcp_vercel_get_deployment_build_logs({
  idOrUrl: 'my-app-abc123.vercel.app',
  teamId: 'team_xyz',
});

MCP servers are surprisingly simple to build. The official SDK³ provides everything you need. Here's a minimal example:

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new Server(
  {
    name: 'my-custom-server',
    version: '1.0.0',
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// Define a tool
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: 'query_database',
        description: 'Query the development database',
        inputSchema: {
          type: 'object',
          properties: {
            query: { type: 'string' },
          },
          required: ['query'],
        },
      },
    ],
  };
});

// Handle tool calls
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === 'query_database') {
    const result = await db.query(request.params.arguments.query);
    return {
      content: [{ type: 'text', text: JSON.stringify(result) }],
    };
  }
});

// Start server
const transport = new StdioServerTransport();
await server.connect(transport);

After using MCP extensively on this portfolio, here are some patterns that work well:

1. Memory for Project Context

Use the Memory MCP to store project-specific knowledge:

// Store architecture decisions
await mcp_memory_create_entities({
  entities: [
    {
      name: 'Blog System',
      entityType: 'Architecture',
      observations: [
        'Uses MDX with next-mdx-remote',
        'Syntax highlighting via Shiki',
        'View counts stored in Redis',
      ],
    },
  ],
});

This means the AI remembers your project's patterns without you repeating them.

2. Sequential Thinking for Complex Tasks

For architectural decisions or debugging, use Sequential Thinking to break down problems:

// AI uses this internally for multi-step reasoning
await mcp_thinking_sequentialthinking({
  thought: 'First, analyze the current rate limiting implementation...',
  thoughtNumber: 1,
  totalThoughts: 5,
  nextThoughtNeeded: true,
});

This gives better results than asking for immediate solutions.

3. Filesystem Operations Stay Local

Never upload credentials or sensitive files. MCP filesystem servers let AI read your local files without sending them anywhere:

// AI reads local files securely
const config = await mcp_filesystem_read_file({
  path: './.env.local',
});

The file contents stay on your machine.

The Developer Experience

Here's what a typical workflow looks like:

Before MCP:

Check production errors in Sentry (browser)
Copy error message
Search codebase for relevant files
Paste everything into AI chat
Get generic suggestions
Check documentation (browser)
Paste docs into chat
Iterate...

With MCP:

Ask AI: "What's causing the database errors in production?"
AI fetches errors from Sentry, finds relevant code, checks docs
Get specific fix with context from your actual system
Deploy and verify

The difference is dramatic. The AI works with your actual project state , not a text summary you typed.

Security Considerations

MCP is designed with security in mind, but you still need to be careful:

Credentials : Keep tokens in MCP server config, never expose them
Scope : Only grant necessary permissions (read-only when possible)
Audit : MCP servers log all operations
Isolation : Servers run locally, no external data sharing

From the MCP security guidelines¹:

"MCP servers run with the same permissions as your user account. Only install servers from trusted sources."

Getting Started

To start using MCP with GitHub Copilot in VS Code:

1. Install MCP servers:

# Core servers
npm install -g @modelcontextprotocol/server-memory
npm install -g @modelcontextprotocol/server-filesystem
npm install -g @upstash/context7-mcp

# Integration servers (HTTP-based)
# Configure in VS Code settings

2. Configure VS Code settings:

Add to .vscode/settings.json or user settings:

{
  "github.copilot.chat.mcp.enabled": true,
  "github.copilot.chat.mcp.servers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"]
    }
  }
}

3. Start using MCP-aware prompts:

"Use the Sentry MCP to find production errors from the last 24 hours"
"Use Context7 to look up the latest Next.js App Router patterns"
"Use Memory to recall our authentication architecture"

What's Next for MCP?

The protocol is still evolving. Anthropic recently announced code execution capabilities⁴, and the direction is clear:

More integrations : Database tools, cloud platforms, analytics
Better discovery : Marketplace for MCP servers
Cross-editor support : Beyond VS Code (JetBrains, Cursor, etc.)
Enterprise features : Team-shared servers, permission management

Closing Thoughts

Model Context Protocol represents a shift in how we think about AI-assisted development. Instead of AI as a chatbot that gives generic advice, it becomes a teammate with access to your actual development context.

The key insight: context is everything. An AI that can query your production errors, read your actual codebase, and fetch current documentation is infinitely more useful than one working from a text description.

If you're building AI tools or just trying to improve your development workflow, MCP is worth exploring. The protocol is open, the SDKs are straightforward, and the ecosystem is growing fast. With frameworks like Next.js 15⁵ embracing server components and actions, the synergy with MCP-powered AI assistants is only getting stronger.

Resources

This post was written with assistance from GitHub Copilot using MCP servers for Memory, Sequential Thinking, and Context7 documentation lookup. The irony is not lost on me.

Footnotes

Introducing the Model Context Protocol - Anthropic ↩ ↩²
Model Context Protocol - Wikipedia ↩
MCP GitHub Organization ↩
Code execution with MCP - Anthropic Engineering ↩
Next.js 15 Release Notes ↩

Hardening a Developer Portfolio

Drew — Sun, 05 Oct 2025 12:00:00 +0000

📚 Series Background: This is a follow-up to where I built the foundation for what would become a comprehensive developer platform. This series documents the security hardening, performance optimization, and production features that transformed a simple portfolio into an enterprise-ready system

After building the initial portfolio, I systematically addressed security vulnerabilities, performance bottlenecks, and scalability concerns to create a production-ready platform. What started as a simple site now includes comprehensive monitoring, automated security headers, background job processing, and enterprise-grade features.

This series documents the patterns and decisions that took it from prototype to production.

Hardening a developer portfolio isn't just about adding features—it's about systematically addressing security, performance, and scalability. This post covers CSP implementation, rate limiting, INP optimization (664ms → <200ms), and GitHub integration. All with zero external dependencies where possible.

Production Features Overview

Current Architecture (December 2025):

Security : CSP headers, rate limiting, input validation, automated vulnerability scanning
Analytics : Redis-powered view tracking, trending posts, milestone detection
Performance : Server components, edge caching, image optimization, Core Web Vitals monitoring
Infrastructure : Background jobs with Inngest, GitHub integration, automated deployments
Monitoring : Sentry error tracking, Vercel Analytics, comprehensive logging

The Journey

Part 1: Security Hardening

Content Security Policy (CSP) Implementation

The site had zero CSP headers, making it vulnerable to XSS attacks and clickjacking. I implemented a defense-in-depth approach using Next.js middleware and Vercel configuration.

What I Built:

Dynamic CSP with unique nonce generation per request
Next.js middleware (src/middleware.ts) for HTML routes
Two-layer architecture: dynamic middleware + static vercel.json fallback
Support for third-party scripts (Vercel Analytics, Speed Insights)

Key Learnings:

Middleware runs on every request, so keep it lightweight (34.2 kB bundle)
Nonces
are critical for inline scripts in modern frameworks
Testing CSP requires browser DevTools and careful header inspection
Vercel's CDN can strip headers; middleware provides reliable enforcement

Technical Highlights:

// Generate unique nonce per request
const nonce = Buffer.from(crypto.randomUUID()).toString('base64');

// Build strict CSP
const csp = `
  default-src 'self';
  script-src 'self' 'nonce-${nonce}' https://va.vercel-scripts.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self';
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
`
  .replace(/\s{2,}/g, ' ')
  .trim();

response.headers.set('Content-Security-Policy', csp);

Results:

XSS attack mitigation
Clickjacking protection via frame-ancestors 'none'
Strict resource loading policies
All builds passing with middleware enabled

Rate Limiting Implementation

The contact form API endpoint had no rate limiting, making it vulnerable to spam and abuse. I implemented a zero-dependency, in-memory rate limiter.

What I Built:

Custom rate limiter utility in src/lib/rate-limit.ts (146 lines)
IP-based tracking with Vercel header support (X-Forwarded-For)
Standard rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)
Graceful 429 responses with retry timing
Automated test suite (scripts/test-rate-limit.mjs)

Key Learnings:

In-memory storage works for single-instance deployments (Vercel serverless)
For multi-region or high-scale, upgrade to Vercel KV or Upstash Redis
Rate limit headers improve client-side UX (show retry time)
IP-based tracking requires careful proxy header handling

Technical Highlights:

// Rate limiter with automatic cleanup
export class RateLimiter {
  private requests = new Map<string, RequestRecord>();

  async check(identifier: string): Promise {
    const now = Date.now();
    const record = this.requests.get(identifier);

    // Check if rate limited
    if (record && record.requests.length >= this.limit) {
      const oldestRequest = record.requests[0];
      if (now - oldestRequest < this.windowMs) {
        return {
          success: false,
          limit: this.limit,
          remaining: 0,
          reset: new Date(oldestRequest + this.windowMs),
        };
      }
    }

    // Allow request and update tracking
    return this.recordRequest(identifier, now);
  }
}

Results:

Contact form protected from spam (5 requests per 15 minutes)
Zero external dependencies
Automated testing with npm run test:rate-limit
Graceful user feedback on rate limit

Part 2: Performance Optimization

INP (Interaction to Next Paint) Improvements

Google's Core Web Vitals showed poor INP scores (664ms+) on navigation links. The culprit: Next.js hover prefetching blocking the main thread.

What I Fixed:

Disabled hover prefetching on `components (prefetch={false}`)
Added CSS performance hints (will-change-auto, contain: layout style)
Hardware-accelerated transitions (transform: translateZ(0))
Non-blocking theme toggle using React's useTransition
Non-blocking form submissions

Key Learnings:

Hover prefetching is great for UX but terrible for INP
Links still prefetch on viewport intersection (better trade-off)
CSS containment prevents expensive layout recalculations
React 18+ useTransition keeps UI responsive during state updates

Next.js hover prefetching can block the main thread and destroy INP scores (664ms+). Disable with prefetch={false} on `` components. Links still prefetch on viewport intersection—a better trade-off that improved INP to <200ms (Good).

Technical Highlights:

// Non-blocking theme toggle
export function ThemeToggle() {
  const [isPending, startTransition] = useTransition();
  const { setTheme, theme } = useTheme();

  const toggleTheme = () => {
    startTransition(() => {
      setTheme(theme === 'light' ? 'dark' : 'light');
    });
  };

  return (

      {/* ... */}
    </Button>
  );
}

Results:

INP score improved from 664ms+ to under 200ms (Good)
Smoother navigation and interactions
Theme toggle feels instant
No layout shifts or visual jank

GitHub Contributions Heatmap

I added a live GitHub contributions heatmap to the homepage to showcase activity.

What I Built:

GitHub GraphQL API integration (/api/github-contributions)
Client-side caching (24-hour duration) via localStorage
Fallback to sample data if API unavailable
Visual heatmap using react-calendar-heatmap
Optional GITHUB_TOKEN env var for higher rate limits

Key Learnings:

GitHub's public API has low rate limits (60 req/hour)
Personal access tokens (no scopes needed) bump it to 5,000 req/hour
Client-side caching is essential for API rate limit management
Always have fallback data for better UX

Technical Highlights:

// Fetch with caching
const fetchContributions = async (): Promise => {
  // Check cache first
  const cached = localStorage.getItem(CACHE_KEY);
  if (cached) {
    const data = JSON.parse(cached);
    if (Date.now() - data.timestamp < CACHE_DURATION) {
      return data;
    }
  }

  // Fetch from API
  const response = await fetch('/api/github-contributions');
  const data = await response.json();

  // Cache result
  localStorage.setItem(
    CACHE_KEY,
    JSON.stringify({
      ...data,
      timestamp: Date.now(),
    })
  );

  return data;
};

Results:

Live contribution data on homepage
24-hour client-side cache reduces API calls
Graceful fallback to sample data
Under 5KB bundle size increase

Part 3: Developer Experience

AI Contributor Guide

I created comprehensive instructions for AI coding assistants (GitHub Copilot, Cursor, etc.) to maintain code quality and architectural consistency.

What I Built:

Detailed guide in .github/copilot-instructions.md
MCP (Model Context Protocol) server guidelines
Stack decisions, architecture patterns, and conventions

Key Learnings:

AI assistants benefit from explicit architectural constraints
Document "what not to change" as much as "how to build"
Include import alias patterns and file organization rules
MCP servers enable secure, local-first AI integrations

Results:

Consistent code quality across AI-assisted changes
Clear boundaries and conventions
Faster onboarding for contributors
Reduced architectural drift

Key Takeaways

Security is not optional : CSP and rate limiting should be in every production app
Performance is perception : 664ms feels slow, under 200ms feels instant
Zero dependencies are underrated : Custom rate limiter = 146 lines, no external deps
Caching strategy matters : Client-side cache + fallback data = resilient UX
Document everything : Future you will thank present you
AI assistants need guardrails : Explicit conventions prevent drift

What's Next?

Future improvements on my radar:

Search functionality for blog posts
Tag filtering and navigation
View counts and analytics
Upgrade rate limiter to Vercel KV for multi-region
Add E2E tests with Playwright

Conclusion

Taking a project from "works on my machine" to "production-ready" requires intentional hardening. Security, performance, and developer experience all need attention.

The good news? Modern frameworks like Next.js make it easier than ever. Middleware for CSP, server actions for rate limiting, and React's concurrent features for performance, the tools are there.

The platform is now deployed in production with comprehensive monitoring, automated security scanning, and enterprise-grade features. The architecture patterns documented here have proven themselves in real-world usage with excellent Core Web Vitals scores and zero security incidents.

Now it's your turn. What production features does your developer platform need?

Shipping a Developer Portfolio

Drew — Wed, 10 Sep 2025 12:00:00 +0000

📚 Series Background: This is the first post in the Portfolio series. What started as a minimal portfolio has evolved into a production-ready platform with comprehensive security, featuring CSP headers, rate limiting, Redis analytics, background job processing, and extensive monitoring. This series documents the complete journey from initial build to production deployment.

I wanted to build a focused portfolio that is fast to load, easy to iterate on, and simple to host. After trying a few prototypes, I settled on a modern stack that prioritizes server rendering, typed data, and tiny bundles.

Why App Router?

The Next.js App Router represents a fundamental shift toward server-first rendering. Unlike the Pages Router, App Router makes server components the default, which means:

Better performance : Initial page loads are faster since most components render on the server.
Improved SEO : Content is fully rendered before it reaches the browser.
Reduced client bundle : Only interactive components ship JavaScript to the client.
Streaming and suspense : Built-in support for progressive loading.

In this portfolio, I only use client components where it actually matters, theme toggling, the contact form, and a few sprinkle interactions.

Architecture cheat sheet

src/
├── app/ # App Router pages and API routes
├── components/ # Reusable UI components
├── content/ # MDX blog posts with frontmatter
├── data/ # Typed static data (projects, resume)
└── lib/ # Utilities and helpers

Stack deep dive

Next.js 15 + React 19

App Router with server components by default
Turbopack for lightning-fast dev server (production builds use Webpack)
File-based metadata with zero config

TypeScript (strict)

Type definitions for posts and projects ensure type safety
Server routes validate payloads aggressively
Strict mode catches errors at compile time

Tailwind CSS v4

CSS-first mental model
Dark mode via CSS variables, no class juggling

shadcn/ui

Accessible Radix primitives (Dialog, Dropdown, Tooltip, etc.)
Headless building blocks with CVA variants
Copy-paste component library that you own

Deployment

Everything lands on Vercel with zero manual knobs. Analytics and Speed Insights are on by default, headers are set via vercel.json, and the whole thing stays fast.

Content Management

Blog posts live as individual MDX files in src/content/blog/, parsed at build time with gray-matter for frontmatter. This approach offers:

Version control : Every post is tracked in Git
Simple authoring : Write in Markdown with React components
Type safety : Frontmatter is validated against TypeScript types
Build-time rendering : Posts are statically generated for speed

MDX content is rendered with next-mdx-remote and enhanced with rehype plugins for auto-linking headings and GitHub-flavored markdown.

Takeaways

Server components encourage you to ask "does this need to be interactive?"
Tailwind v4 wipes away config noise
File-based content with MDX provides Git-backed authoring
Type-safe frontmatter catches errors before deployment

Search and tag filtering are now live without compromising the stack's simplicity, and view counts remain on the roadmap.

What's Next?

This was just the beginning. After shipping, I spent time hardening the site for production with security improvements, performance optimizations, and developer experience enhancements.