DEV Community: Karam Khoury

The AI Attack Wave Is Coming for Your App. Here's How to Harden It Now

Karam Khoury — Mon, 07 Sep 2026 10:45:14 +0000

What the industry warning actually means for the code you shipped last sprint

Last year I watched a "quiet" internal API get hammered at 3 a.m. It wasn't a person. It was a script that read our public docs, inferred an undocumented endpoint, and walked our validation logic faster than any human tester ever had.

That was a crude bot. The tools attackers now hold are not crude. In late August 2026, OpenAI, Microsoft, Google, Anthropic, and over 100 other organizations issued a joint warning: a surge of sophisticated, AI-powered attacks against critical infrastructure is coming, and the window to prepare is narrow.

If you build software, this is not a policy story happening somewhere above you. It's a code review problem on your desk. Let me show you what changes and what to do about it.

The Core Concept: The Attacker Just Got Cheaper, Faster, and Tireless

AI doesn't invent new categories of vulnerability. It industrializes the old ones. The SQL injection, the missing authorization check, the leaked key in a log — attackers always knew how to exploit these. What's new is that discovery and exploitation now scale like a cloud workload.

Think of it as the economics flipping. The cost of probing your entire attack surface just dropped to near zero.

        OLD MODEL                         NEW MODEL (AI-Assisted)
   ┌──────────────────┐              ┌──────────────────────────┐
   │  Human attacker  │              │   AI agent, 24/7          │
   │  picks 1 target  │              │   fans out across 10,000  │
   │  reads docs      │   ───────▶   │   endpoints, learns your  │
   │  tries by hand   │              │   error messages, adapts  │
   │  gives up at 5pm │              │   never sleeps            │
   └──────────────────┘              └──────────────────────────┘
     Slow, expensive,                  Fast, cheap, relentless,
     easily rate-limited               reads every response you leak

Your defense strategy was implicitly sized for the old model. It assumed friction — that an attacker would only look so hard for so long. That assumption is now gone. Every weak default and every verbose error message you shipped is now discoverable at machine speed.

Deep Dive: What Actually Changes for Your Application

1. Your error messages are now free reconnaissance

An AI agent doesn't need your source code. It reads what your app tells it. A stack trace, a "column 'user_role' does not exist" database error, a 500 that leaks a framework version — each one is a training signal that lets the attacker refine the next request. Security auditors have a name for this: CWE-209, Information Exposure Through an Error Message. It has been on the books for years; AI just made it lucrative to exploit at scale.

The fix is old advice that just became urgent: never let internal detail cross the boundary to the client.

// Program.cs — one place, applied globally
if (environment.IsProduction())
{
    application.UseExceptionHandler("/error");
    application.UseHsts();
}

// The handler returns a correlation ID, never the exception detail.
application.Map("/error", (HttpContext context) =>
{
    string correlationId = Activity.Current?.Id ?? context.TraceIdentifier;

    // Full detail goes to your logs, not the wire.
    ILogger logger = context.RequestServices.GetRequiredService<ILogger<Program>>();
    IExceptionHandlerFeature? feature = context.Features.Get<IExceptionHandlerFeature>();
    if (feature is not null)
    {
        logger.LogError(feature.Error, "Unhandled exception {CorrelationId}", correlationId);
    }

    return Results.Problem(
        title: "\"An unexpected error occurred.\","
        statusCode: StatusCodes.Status500InternalServerError,
        extensions: new Dictionary<string, object?> { ["correlationId"] = correlationId });
});

The client gets an opaque ID. You get the full trace in your logs. The attacker's agent gets nothing to learn from.

2. Authorization gaps get found in minutes, not months

Broken object-level authorization — the classic "I changed the ID in the URL and saw someone else's data" — is the single most reliable bug for an automated agent to find. It simply enumerates IDs and watches which ones return 200. This is OWASP API1:2023, Broken Object Level Authorization (BOLA) — consistently the number one API risk, and the easiest one for a tireless agent to weaponize.

Stop trusting the ID in the request. Every data access must be scoped to the caller's identity at the query, not filtered afterward in memory.

// WRONG: fetch by ID, then hope you remember to check ownership.
public async Task<Invoice?> GetInvoiceAsync(Guid invoiceId)
{
    return await this.dbContext.Invoices.FindAsync(invoiceId);
}

// RIGHT: the tenant/owner is part of the query. An unauthorized ID returns null.
public async Task<Invoice?> GetInvoiceAsync(Guid invoiceId, Guid callerTenantId)
{
    return await this.dbContext.Invoices
        .Where(invoice => invoice.Id == invoiceId && invoice.TenantId == callerTenantId)
        .SingleOrDefaultAsync();
}

If ownership is a filter you apply after fetching, an agent will eventually find the code path where you forgot. If ownership is part of the WHERE clause, there is no path to forget.

For multi-tenant systems, take it one level deeper and enforce isolation at the engine, not the developer. EF Core's HasQueryFilter applies a tenant predicate to every query for an entity automatically — so the junior dev who writes a new repository method next quarter inherits the isolation whether they remember it or not.

// OnModelCreating — isolation becomes a property of the model, not of discipline.
modelBuilder.Entity<Invoice>()
    .HasQueryFilter(invoice => invoice.TenantId == this.tenantProvider.CurrentTenantId);

Explicit scoping in each query and a global filter aren't either/or — the filter is your safety net for human omission, the explicit WHERE is your intent on the hot paths. Just remember that IgnoreQueryFilters() exists, so keep it out of tenant-scoped code and flag it in review.

3. Rate limiting is no longer optional plumbing

The old assumption was that abusive traffic looked obviously abusive. AI-driven traffic can mimic real user patterns while still probing thousands of variations. You need limits that are boring, default-on, and applied per-identity — not just per-IP, since IPs are cheap to rotate.

.NET has this built in. Use it.

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    // Partition by authenticated user where possible; fall back to IP.
    options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(context =>
    {
        string partitionKey = context.User.Identity?.IsAuthenticated == true
            ? context.User.FindFirst("sub")?.Value ?? "anonymous"
            : context.Connection.RemoteIpAddress?.ToString() ?? "unknown";

        return RateLimitPartition.GetFixedWindowLimiter(partitionKey, _ => new FixedWindowRateLimiterOptions
        {
            PermitLimit = 100,
            Window = TimeSpan.FromMinutes(1),
            QueueLimit = 0
        });
    });
});

application.UseRateLimiter();

One critical caveat: AddRateLimiter counts requests in-process, per node. On a multi-node or Kubernetes deployment, an attacker's round-robin traffic gets a fresh limit on every pod — so pair it with a shared enforcement point: a Redis-backed distributed partitioner, or edge/gateway limiting at YARP, an API gateway, or Cloudflare. In-process limiting is your last line, not your only one.

This won't stop a determined adversary alone, but it removes the free lunch. It turns "probe everything instantly" back into "probe slowly and get noticed."

4. If your app calls an LLM, its input is now an attack surface

This is the genuinely new category, and OWASP now tracks it in its own top-ten list: LLM01, Prompt Injection and LLM02, Insecure Output Handling. If any part of your system feeds untrusted text into a model — a support summarizer, a document Q&A feature, an agent that calls tools — then prompt injection is now in your threat model. A malicious document can carry instructions that hijack your agent's behavior.

Two rules hold the line. First, never let model output trigger a privileged action without a deterministic check you control. Second, treat everything the model returns as untrusted user input, not as a command.

// The model SUGGESTS an action. Your code DECIDES whether it is allowed.
ModelToolCall suggestion = await this.assistant.GetSuggestedActionAsync(userPrompt);

// Deterministic authorization — the model has no say in this.
if (!this.policy.IsActionPermitted(suggestion.ActionName, caller.Permissions))
{
    this.logger.LogWarning("Model suggested unpermitted action {Action} for {Caller}",
        suggestion.ActionName, caller.Id);
    return Results.Forbid();
}

await this.executor.RunAsync(suggestion);

The model can be tricked. Your authorization layer cannot be talked out of its rules. Keep the decision in code.

The Practical Impact: This Is Cheaper Than You Think

None of the above is a rewrite. It's a set of defaults you apply once and enforce in review. The payoff compounds: a global exception handler and a query-scoped repository pattern don't just close today's holes — they make it structurally hard to open new ones.

For your team, this becomes a review checklist, not a security sprint. New endpoints inherit the rate limiter. New data access inherits the ownership filter. The secure path becomes the path of least resistance, which is the only kind of security that survives a busy backlog.

And the maintainability win is real. Code that leaks nothing, trusts nothing from the client, and keeps decisions deterministic is simply easier to reason about — for humans and for the next audit.

Actionable Takeaways: Your Hardening Checklist

Silence your app. Ship a global exception handler in production that returns a correlation ID and nothing else. Grep your codebase for verbose error responses and stack traces on the wire.
Move ownership into the query. Audit every data-access method. If tenant or user scoping is applied after the fetch, rewrite it into the WHERE clause.
Turn on rate limiting by default. Partition by authenticated identity, not just IP. Make new endpoints inherit it automatically.
Treat LLM I/O as untrusted. If you call a model, put a deterministic authorization check between its output and any real action. Log every rejected suggestion.
Rotate and centralize secrets. Assume any key that has ever touched a log or a repo is compromised. Move to a managed secret store and short-lived credentials now, not after the incident.

The warning from the industry wasn't "panic." It was "you have a narrow window." The good news is that the work fits inside your normal sprint cadence — if you start this one.

What's the first thing you'd harden in your own stack? I read every comment.

Sources:

Give Your .NET REST API an AI Mouth: Adding MCP So Claude and Gemini Can Actually Use It

Karam Khoury — Wed, 02 Sep 2026 10:18:11 +0000

A production engineer's guide to wrapping an existing ASP.NET Core API with the Model Context Protocol — without tearing out your JWT stack.

Last quarter a product manager dropped a Slack message that a lot of us are getting now: "Can I just ask Claude to pull the open invoices from our system?"

We already had the API. Fully built, JWT-secured, battle-tested in production. The problem was never the data — it was that an LLM has no idea our /api/invoices?status=open endpoint exists, and even if it did, it can't read our OpenAPI spec and authenticate itself.

The Model Context Protocol (MCP) is the missing adapter. This is how you bolt it onto an API you already own, in an afternoon, and what to do about authentication before security reviews it.

The Core Concept: MCP Is an Adapter, Not a Rewrite

MCP is an open protocol that lets AI clients (Claude Desktop, Gemini, Cursor, and others) discover and call your capabilities as "tools." You do not rewrite your API. You stand up a thin MCP server that exposes selected endpoints as tools and forwards the calls.

   AI Chat (Claude / Gemini)
            │   MCP protocol (JSON-RPC)
            ▼
   ┌──────────────────────┐
   │   MCP Server (.NET)  │  ← [McpServerTool] methods
   │   - GetOpenInvoices  │
   │   - CreateTicket     │
   └─────────┬────────────┘
             │   HttpClient + Bearer/API key
             ▼
   ┌──────────────────────┐
   │  Existing REST API   │  ← unchanged, still JWT-secured
   └──────────────────────┘

The MCP server is a translator: it speaks JSON-RPC to the model and plain HTTP to your existing API. Your business logic never moves.

Step 1: Stand Up the MCP Server

Use the official C# SDK (maintained together with Microsoft). Add it to a new minimal ASP.NET Core project so you can host a remote MCP server over Streamable HTTP:

dotnet add package ModelContextProtocol.AspNetCore

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddMcpServer()
    .WithHttpTransport()          // Streamable HTTP for remote clients
    .WithToolsFromAssembly();     // discover [McpServerTool] methods

// Typed client to your EXISTING API
builder.Services.AddHttpClient("BackendApi", static client =>
{
    client.BaseAddress = new Uri("https://api.internal.t1tech.com/");
});

WebApplication app = builder.Build();
app.MapMcp();                     // exposes the /mcp endpoint
app.Run();

That is the entire host. MapMcp() wires up discovery, so any compliant AI client can enumerate your tools.

Step 2: Turn an Endpoint Into a Tool

A tool is just a method. The attributes and XML-style descriptions are not decoration — the model reads them to decide when and how to call you. Be explicit; vague descriptions cause hallucinated arguments.

[McpServerToolType]
public sealed class InvoiceTools
{
    private readonly IHttpClientFactory _httpClientFactory;

    public InvoiceTools(IHttpClientFactory httpClientFactory)
    {
        _httpClientFactory = httpClientFactory;
    }

    [McpServerTool]
    [Description("Returns open (unpaid) invoices for a given customer ID.")]
    public async Task<string> GetOpenInvoices(
        [Description("The numeric customer identifier.")] int customerId,
        CancellationToken cancellationToken)
    {
        HttpClient client = _httpClientFactory.CreateClient("BackendApi");

        HttpResponseMessage response = await client.GetAsync(
            $"api/invoices?customerId={customerId}&status=open",
            cancellationToken);

        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync(cancellationToken);
    }
}

Notice there is no token in that call yet. That is the entire fight, and the next two sections are where production engineering actually happens.

Step 3: The JWT Question — Whose Identity Is Calling?

Your API trusts a JWT. The naive instinct is to bake a service account token into the MCP server. Do not. That collapses every user into one identity and hands the LLM god-mode over your data.

The correct model: the MCP server is an OAuth 2.1 Resource Server. The AI client authenticates the human, receives a token, and passes it through. The MCP Authorization spec standardizes this with Protected Resource Metadata (RFC 9728), so the client can discover where to log in.

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(static options =>
    {
        options.Authority = "https://login.t1tech.com/";
        options.Audience = "mcp-invoice-server";
    });

builder.Services.AddAuthorization();

// ...after Build()
app.UseAuthentication();
app.UseAuthorization();
app.MapMcp().RequireAuthorization();

Then forward the caller's identity instead of a hardcoded secret. Grab the incoming token from HttpContext and attach it downstream:

public InvoiceTools(
    IHttpClientFactory httpClientFactory,
    IHttpContextAccessor httpContextAccessor)
{
    _httpClientFactory = httpClientFactory;
    _httpContextAccessor = httpContextAccessor;
}

private async Task<HttpClient> CreateAuthorizedClientAsync(CancellationToken ct)
{
    HttpClient client = _httpClientFactory.CreateClient("BackendApi");

    string? token = await _httpContextAccessor.HttpContext!
        .GetTokenAsync("access_token");

    if (!string.IsNullOrEmpty(token))
    {
        client.DefaultRequestHeaders.Authorization =
            new AuthenticationHeaderValue("Bearer", token);
    }

    return client;
}

Now the existing API sees the real user's scopes and roles. Your authorization rules keep working, untouched. The LLM cannot read an invoice the human behind it could not read.

Step 4: Do You Need an API Key Instead? Pick By Client Type

JWT/OAuth is right for interactive chat where a human is present. But not every MCP consumer is a person clicking "Authorize." Choose the scheme by who connects:

Remote HTTP server, human in a chat client → OAuth 2.1 with JWT pass-through. This is the spec's blessed path. Full user identity, scoped access, revocable.
Local stdio server or machine-to-machine automation → API key. When there is no interactive login (a scheduled agent, a local dev tool), issue a scoped API key and read it from configuration, never from source.

// API key path — for non-interactive / stdio clients
string apiKey = builder.Configuration["Backend:ApiKey"]
    ?? throw new InvalidOperationException("Missing Backend:ApiKey.");

client.DefaultRequestHeaders.Add("X-Api-Key", apiKey);

My recommendation for a team shipping this: default to OAuth 2.1 JWT pass-through for anything remote, and reserve API keys for headless integrations where you can mint narrowly scoped, per-integration keys and rotate them. Treat a static API key like a password — short TTL, per-client, logged, revocable. Never a single shared secret with full API surface.

The Flow: What Actually Happens When Claude Uses Your Tool

Code is abstract until you watch a real request move through it. Here is the end-to-end round trip when a user types "Show me the open invoices for customer 4821" into Claude.

But first — the question everyone asks: where does Claude get that JWT? It is not magic and Claude does not "have your token." The MCP client obtains it through a standard OAuth 2.1 handshake the first time it connects, and this is worth seeing on its own.

[0a] Claude → MCP Server:  first call, no token
     ← 401 Unauthorized
       WWW-Authenticate: Bearer resource_metadata="https://mcp.t1tech.com/.well-known/..."

[0b] Claude reads Protected Resource Metadata (RFC 9728)
     → learns which Authorization Server (your IdP) issues tokens

[0c] Claude runs OAuth 2.1 Authorization Code + PKCE:
     → opens a browser window
     → USER logs in at login.t1tech.com and clicks "Allow"
     → IdP redirects back with an auth code
     → Claude exchanges code → access_token (JWT) + refresh_token

[0d] Claude securely stores the token and reuses it.
     Refresh happens silently; the login prompt does NOT repeat each message.

The critical point: the human authenticates directly with your identity provider, not with Claude. Claude never sees a password. It receives a scoped, expiring JWT through the same OAuth flow your web frontend would use — and your MCP server, as the Resource Server, advertises where that login lives via the 401 challenge in Step 0a.

On the .NET side, RequireAuthorization() already returns the 401. The one extra thing you owe the client is the discovery pointer in Step 0b — register the MCP server as a protected resource so the SDK emits the resource_metadata challenge and serves the metadata document:

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMcp(static options =>
    {
        // Advertises this server as an OAuth 2.1 Resource Server
        options.ResourceMetadata = new ProtectedResourceMetadata
        {
            AuthorizationServers = { new Uri("https://login.t1tech.com/") }
        };
    });

That single registration is what turns "Claude somehow has a token" into a discoverable, spec-compliant login the client can drive on its own.

Only after that handshake does the everyday request loop below run:

[1] USER  →  Claude Chat
    "Show me the open invoices for customer 4821."

[2] Claude → MCP Server:  discovery (once, on connect)
    "What tools do you have?"
    ← [{ name: "GetOpenInvoices",
         description: "Returns open (unpaid) invoices for a customer ID.",
         params: { customerId: int } }]

[3] Claude reasons:
    intent = list open invoices  →  tool = GetOpenInvoices
    extracts argument  →  customerId = 4821

[4] Claude → MCP Server:  tools/call (JSON-RPC)
    Authorization: Bearer <the signed-in user's JWT>
    { "name": "GetOpenInvoices", "arguments": { "customerId": 4821 } }

[5] MCP Server validates the JWT, then forwards downstream:
    GET /api/invoices?customerId=4821&status=open
    Authorization: Bearer <same JWT — user identity preserved>

[6] Existing REST API applies the user's scopes → returns JSON

[7] MCP Server → Claude:  tool result (raw JSON)
    [{ "id": 5567, "amount": 1200.00, "due": "2026-09-15" }, ...]

[8] Claude → USER:
    "Customer 4821 has 2 open invoices totaling $2,050 —
     one due Sep 15 ($1,200) and one due Oct 2 ($850)."

Two things are worth pausing on.

Step 2 happens once, not per message. The client caches your tool catalog on connect. This is why the [Description] text is load-bearing — the model chooses tools purely from it, long before your code ever runs.

Step 4 to Step 6 is the whole security story. The JWT the human logged in with is the same JWT that reaches your API. Claude never sees a service credential, and it can never retrieve an invoice the signed-in user isn't authorized to see. The model orchestrates; your API still decides.

If you want to see this concretely, the tool result at Step 7 is exactly the string your GetOpenInvoices method returned — Claude does the natural-language summarization in Step 8. You return data; the model handles the prose.

Practical Impact

The payoff is not "AI hype." It is that a capability you already built becomes usable by a new class of client with near-zero duplication.

Your team writes one thin tool method per endpoint you want to expose — not a second API. Because identity flows through, your security posture is unchanged: the same JWT, the same scopes, the same audit trail. And because tools are just decorated C# methods, they unit-test like any other service, and new endpoints become new tools in minutes.

The long-term maintainability win is that MCP is a stable seam. When you swap Claude for Gemini, or add a third client, nothing changes on your side. You built the adapter once.

Actionable Takeaways

Wrap, don't rewrite. Stand up a separate MCP server that forwards to your existing API over HttpClient. Business logic stays put.
Write ruthless tool descriptions. The model chooses tools from your [Description] text. Vague text produces bad calls.
Pass the user's identity through — never hardcode a service token. Make the MCP server an OAuth 2.1 Resource Server and forward the caller's JWT so existing authorization still applies.
Choose auth by client type. OAuth 2.1/JWT for interactive remote clients; scoped, rotatable API keys only for headless stdio or M2M integrations.
Ship the smallest surface first. Expose read-only tools before write tools, and let least-privilege scopes gate everything the LLM can reach.

MCP vs RAG: Two AI Buzzwords, Explained Without the Buzzwords

Karam Khoury — Thu, 06 Aug 2026 12:33:37 +0000

A few weeks ago, a junior engineer on my team asked me: "Should we use RAG or MCP for this feature?"

He said it like the two were competing options. Like picking between React and Vue.

They're not. One is about giving an AI knowledge. The other is about giving an AI hands. Once you see that difference, the buzzwords stop being scary.

The Core Concept, in One Line Each

RAG (Retrieval-Augmented Generation): Before the AI answers you, it goes and reads relevant documents first, then writes its answer based on what it just read.

MCP (Model Context Protocol): A standard way for an AI to connect to and use outside tools — like your calendar, your database, or your file system — instead of just talking about them.

Here's the simplest way to picture it:

RAG:  Question -> Search your documents -> Read the best matches -> Answer
MCP:  Question -> Call a real tool (email, calendar, database) -> Get a real result -> Answer

RAG makes the AI smarter about what it knows.
MCP makes the AI capable of doing something.

Where They're Similar

Both exist to fix the same core problem: an AI, by itself, only knows what it was trained on, up to a certain date. It can't see your company's internal wiki. It can't see today's stock price. It can't see the email that just landed in your inbox.

Both RAG and MCP are ways of feeding an AI fresh, outside information at the moment you ask your question, instead of relying only on what it memorized during training.

That's the whole family resemblance. After that, they split in very different directions.

Where They're Different

RAG is about reading. MCP is about acting.

	RAG	MCP
What it does	Finds and reads relevant text	Connects to and operates a tool
Typical use	"Answer using our documents"	"Book this meeting" or "Update this record"
Output	Better, more accurate answers	Real actions with real side effects
Example source	A PDF, a knowledge base, a set of notes	A calendar app, an email inbox, a database

Think of RAG as a very fast research assistant. You ask a question, they run to the library, grab the three most relevant pages, and hand them to you before you even finish your coffee.

Think of MCP as a universal remote control. It doesn't know anything by itself — but it can press the right buttons on whichever device you point it at: your calendar, your CRM, your ticketing system.

Where To Use Each

Use RAG when the problem is "the AI doesn't know this."

A customer support bot that needs to answer questions using your product manuals.
A legal assistant that needs to reference your actual contracts, not generic legal knowledge.
An internal chatbot that answers HR questions using your company's real policy documents.

Use MCP when the problem is "the AI needs to do this."

An assistant that checks your real calendar and books a meeting for you.
A support agent that actually creates a ticket in your helpdesk system, not just describes one.
A coding assistant that reads your real files and runs your real tests, instead of guessing.

Use both when you need an AI that is both well-informed and useful. A great example: a customer support AI that uses RAG to pull the correct refund policy from your documents, then uses MCP to actually process the refund in your billing system.

A Real-Life Example

Imagine you run an online store and you build an AI assistant for customer support.

A customer asks: "What's your return policy for items bought during the sale, and can you start my return?"

RAG kicks in first. It searches your actual return policy documents, finds the section about sale items (which usually has different rules than regular items), and pulls the exact, correct answer instead of a generic guess.
MCP kicks in next. It connects to your order management system, finds the customer's real order, and actually starts the return process.

Without RAG, the AI might confidently give the wrong policy. Without MCP, the AI could only tell the customer how to start a return, not actually start it. Together, the customer gets a correct answer and a completed action, in one conversation.

Practical Impact for Your Team

Getting this distinction right changes how you scope a project.

If a stakeholder says "make the AI smarter about our documents," that's a RAG problem — you're building a search-and-retrieve pipeline over your content.

If they say "make the AI actually do things in our systems," that's an MCP problem — you're building integrations and giving the AI safe, well-defined tools to call.

Confusing the two leads to wasted sprints: teams building elaborate document search when what the business actually wanted was for the AI to update a record, or vice versa.

Actionable Takeaways

RAG = knowledge. Use it when the AI needs facts it wasn't trained on.
MCP = capability. Use it when the AI needs to perform a real action in a real system.
They're not rivals. Most serious AI products end up using both together.
Scope your project by the verb. "Answer using X" → RAG. "Do X" → MCP.
Start small. Pick one document set for RAG, or one tool for MCP, prove it works, then expand.

Once you strip away the acronyms, both ideas are things you already understand: look it up before you answer, and use the right tool for the job.

Concurrency vs Parallelism: A Simple Guide

Karam Khoury — Tue, 04 Aug 2026 06:44:36 +0000

Concurrency: juggling tasks

Think of concurrency like a chef in a busy kitchen. The chef doesn't cook all dishes at the exact same time — they chop some vegetables, stir a pot, check the oven, and go back to chopping. They make progress on multiple tasks by switching between them quickly.

In computing, concurrency means a system can handle multiple tasks overlapping in time, but not necessarily running at the same instant.

Tasks take turns (like a single CPU core switching between processes).
Useful when tasks involve waiting (downloading files, handling user input).
Common in applications like web servers that manage many users at once.

Parallelism: doing tasks side by side

Now imagine two chefs in the same kitchen. One chops vegetables while the other grills meat — both working at the same time.

That's parallelism: tasks actually running simultaneously, using multiple resources (like multiple CPU cores).

Tasks run truly at the same time.
Requires hardware support (multi-core processors, GPUs).
Used for heavy computation (video encoding, scientific simulations).

Real-world examples

Concurrency: a chat app handling thousands of messages — it switches between users so fast it seems instant.
Parallelism: a weather-forecast model running calculations across multiple CPUs to predict storms faster.

When to use each

Use concurrency when tasks involve waiting (I/O, network requests).
Use parallelism when you need brute-force speed (data processing, rendering).

Takeaway

Concurrency = managing multiple tasks efficiently (even on a single core).
Parallelism = executing multiple tasks at the same time (needs multiple cores).

Both are essential in modern software, and understanding them helps you write faster, more responsive programs.

Written by Karam Khoury — Lead Software Engineer (.NET & Azure) with 14+ years building secure, scalable fintech systems. More at karamkhoury.me.

AWS Introduction for Beginner Software Engineers

Karam Khoury — Tue, 04 Aug 2026 06:39:39 +0000

As a software engineer starting with AWS, you might feel overwhelmed by all the services. Let me break down the key components with real-world examples to help you get started.

1. DNS & How AWS Route 53 Works

Problem: Users can't remember IP addresses like 54.210.167.101 for your app.

Solution: AWS Route 53 (DNS service) maps yourdomain.com to your servers.

Real example: Your startup has servers in Ohio and Frankfurt. Route 53 automatically sends European users to Frankfurt and routes US traffic to Ohio — faster load times for everyone.

2. Networking: VPC & Subnets

VPC: Your private cloud network (like an office building).
Public subnet: For web servers (needs internet access).
Private subnet: For databases (blocked from direct internet access).
Internet Gateway: Connects public subnets to the internet.
NAT Gateway: Lets private subnets reach the internet (one-way).

Real example: In your e-commerce app, the web server runs in a public subnet while the database sits in a private subnet.

3. Storing & Delivering Static Files (S3 + CloudFront)

Amazon S3: Stores images, videos, and logs.
CloudFront (CDN): Caches content globally for faster loading.

Real example: Your blog hosts images in S3; CloudFront caches them in 450+ locations, so a reader in Tokyo gets images from Japan instead of Virginia — cutting load time by ~50%.

Pro tip: Enable S3 Versioning to recover accidentally deleted files.

4. Running Backend Services

AWS Lambda (Serverless) — best for event-driven tasks. Example: a photo app resizes images automatically on upload.

EC2 (Virtual Servers) — best for full control (custom OS, legacy apps). Example: hosting a Java monolith with specific dependencies.

ECS/EKS (Containers) — best for microservices (Docker/Kubernetes). Example: a food-delivery app with separate services for orders, payments, and tracking.

5. Databases: Picking the Right One

Amazon RDS (SQL): Structured data with relationships — e.g. user accounts + orders.
DynamoDB (NoSQL): High-speed, scalable lookups — e.g. a ride-sharing app tracking real-time driver locations.
Aurora (High-Performance SQL): Low-latency apps — e.g. stock-trading platforms.

6. Adding AI/ML to Your App

Amazon Bedrock (pre-trained AI): e.g. a customer-support chatbot trained on your FAQ docs.
SageMaker (custom ML models): e.g. a recommendation engine ("users who bought X also liked Y").

7. Security Essentials

VPC: Controls how your networking works — what can connect to what, what reaches the internet, and what stays private.
NACLs (Network ACLs): A firewall for an entire subnet.
Security Groups: A firewall for each specific instance or service.
IAM (Identity & Access Management): Controls who can access what.

Golden rule — least privilege: a Lambda function should only access the one DynamoDB table it needs; backup processes get read-only access; only DevOps can reach production databases.

8. Monitoring & Debugging

CloudWatch: Tracks performance metrics and logs (EC2 CPU, Lambda errors). Example: alert when database CPU hits 90%.
CloudTrail: Audit logs ("who changed IAM policies?", "who deleted an S3 bucket?") — critical for compliance.

Putting it all together

Imagine building "Twitter Lite":

Route 53 routes users to the nearest server.
CloudFront + S3 deliver profile pictures fast.
EC2 or Lambda runs the backend API.
DynamoDB stores tweets for instant loading.
CloudWatch alerts you if something breaks.

Next steps for beginners

Hands-on: try the AWS Free Tier (12 months free).
First project: deploy a static website on S3 + CloudFront.
Deep dive: learn Lambda + DynamoDB.

Written by Karam Khoury — Lead Software Engineer (.NET & Azure) with 14+ years building secure, scalable fintech systems. More at karamkhoury.me.

Oops, I Committed a Secret: A Calm Guide to Scrubbing Git History

Karam Khoury — Fri, 24 Jul 2026 12:00:25 +0000

You just finished a great feature. You're in the flow.

git add .
git commit -m "Fixed the bug!"
git push

Then you see it, staring back from the GitHub UI: your live API key. 💀

We've all been there. Here's the calm, correct order of operations — from "quick save" for a mistake you caught instantly, to the deep clean for a secret that's been buried in history for months.

Step 0: Rotate the secret first (yes, before anything else)

This is the step people skip, and it's the only one that's non-negotiable. The moment a secret hits a remote, assume it's compromised. Bots scrape public GitHub for credentials within seconds.

So before you touch history:

Revoke / rotate the leaked key, token, or password at its source (AWS, Stripe, your DB, wherever).
Then clean the repo.

Cleaning history without rotating is like changing the locks after posting the old key online. Rotate first, always.

Case 1: You caught it before pushing (the quick save)

If the secret is only in your last, un-pushed commit, this is trivial:

# Stop tracking the file and ignore it going forward
git rm --cached .env
echo ".env" >> .gitignore

# Fold the fix into the last commit
git commit --amend --no-edit

Done. Nothing left the building. (Still rotate the key if it was ever real.)

Case 2: It's deep in history, or already pushed (the deep clean)

Once the secret is several commits back — or on the remote — you need to rewrite history. The modern, recommended tool is git filter-repo (Git's own docs now steer you here instead of the old filter-branch).

# Install (Python)
pip install git-filter-repo

# Option A: remove a whole file from ALL history
git filter-repo --path config/secrets.yml --invert-paths

# Option B: redact a specific string everywhere it appears
echo 'AKIAIOSFODNN7EXAMPLE==>REDACTED' > replacements.txt
git filter-repo --replace-text replacements.txt

Prefer BFG Repo-Cleaner if you like a faster, simpler tool for the common cases:

bfg --delete-files id_rsa
bfg --replace-text passwords.txt

# Expire the old refs and garbage-collect
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Then: force-push and warn your team

History rewriting changes commit hashes, so you must overwrite the remote:

git push --force

⚠️ This rewrites shared history. Tell every collaborator to re-clone or hard-reset — if someone merges an old local branch, the secret comes right back. And remember: on GitHub, the old commit can still be reachable via its hash / cached views for a while, which is exactly why Step 0 (rotation) is what actually protects you.

Prevention: never live on the edge again

.gitignore first. Add .env, *.pem, secrets.* before the first commit.
Environment variables / a secret manager (Azure Key Vault, AWS Secrets Manager, Doppler) — secrets never touch the repo.
A pre-commit scanner so a secret is blocked before it's committed:

# gitleaks catches secrets in staged changes
brew install gitleaks
gitleaks protect --staged

Wire that into a pre-commit hook and the "cold sweat" moment mostly disappears.

TL;DR

Rotate the secret (non-negotiable, do it first).
Un-pushed? git commit --amend.
In history? git filter-repo or BFG, then git push --force.
Tell your team to re-clone.
Add a pre-commit scanner so it never happens again.

How do you handle secrets in your workflow — pre-commit hooks, or living life on the edge? 👇

Written by Karam Khoury — Lead Software Engineer (.NET & Azure) with 14+ years building secure, scalable fintech systems. More at karamkhoury.me.

System Design: The 6 Core Load Balancing Algorithms, Explained

Karam Khoury — Fri, 24 Jul 2026 11:58:19 +0000

Stop guessing how your traffic scales — understand the routing mechanics. Here's how the six core algorithms actually dictate traffic distribution, and when to reach for each.

1. Round Robin

Distributes requests sequentially across the server pool.

Example: Dealing a deck of cards — Server A gets request 1, Server B gets 2, Server C gets 3, then the cycle repeats. Best for identical, stateless servers.

2. Weighted Round Robin

Sequential routing that accounts for unequal hardware.

Example: Server A has 64 GB RAM, Server B has 32 GB. Assign weight 2 to A and 1 to B, and A receives exactly twice as many requests.

3. Least Connections

Routes traffic to the server with the fewest active, open sessions.

Example: Joining the supermarket checkout with the fewest people. Ideal for long-lived connections — WebSockets, heavy database queries.

4. IP Hash

Uses a hash of the client's IP to guarantee the same client hits the same server every time.

Example: A user at 192.168.1.50 is always routed to Server C. Mandatory for legacy stateful apps that store session data in-memory rather than a distributed cache.

5. Least Response Time

A hybrid: lowest number of active connections combined with the lowest average response time.

Example: Joining the line that has both the fewest people and the fastest cashier. Essential when server performance degrades unpredictably.

6. Adaptive (Resource-Based)

Routes based on real-time hardware telemetry from an agent on each server.

Example: The load balancer queries CPU, memory, and I/O wait in real time, and avoids any server spiking above 80% utilization.

Takeaway

Choose your algorithm based on your infrastructure and state management — not trends. Build systems that scale predictably.

Written by Karam Khoury — Lead Software Engineer (.NET & Azure), building secure, scalable fintech systems. More at karamkhoury.me.