Category Archives: Bedrock

LLMjacking Is the New Cryptojacking — and That Should Terrify Your Security Team

November 3 2026 Greg Fina Leave a comment

There is a pattern no one names out loud, and it has repeated so reliably for fifteen years that I now treat it as a law of cloud physics: attackers monetize every new cloud resource in the same order. First they want raw capacity for whatever pays — spam relays, DDoS, credential stuffing. Then, when a new asset class gets valuable enough, they mine it. We lived through the cryptojacking era, where a leaked key meant your account quietly spun up a fleet of GPU instances to mint Monero on your dime. The novelty this time is not the attack. It is the speed. AI inference is the newest substrate, and it did not arrive as an emerging threat. It arrived pre industrialized.

The pattern, and why this iteration is different

If you have been doing this long enough, you can recite the sequence from memory: raw compute abuse, then cryptomining, then credential abuse and data theft, and now unauthorized AI inference. Each new layer rides on the same root cause — exposed credentials and internet facing endpoints that get scanned within hours of going live. What should concern your security team is not that AI inference joined the list. It is how fast it commercialized. Cryptojacking took years to develop a resale market. LLMjacking skipped the awkward adolescent phase entirely and showed up with a supply chain, a pricing model, and a storefront.

Sysdig coined the term “LLMjacking” in May 2024, and the framing was deliberate: this is the new cryptomining. Attackers are not primarily after your data. They are after your inference cycles — your paid access to frontier models — and the bill lands on you. Sysdig called it early. What happened next proved them right faster than anyone expected.

What changed: Operation Bizarre Bazaar

In early 2026, Sysdig and Pillar Security reported Operation Bizarre Bazaar, the first LLMjacking campaign with systematic attribution, a full supply chain, and confirmed marketplace monetization. The numbers are not subtle. Honeypots captured roughly 35,000 attack sessions between December 2025 and January 2026 — about 972 a day. This is not a proof of concept in a researcher’s lab. It is a running business.

The operation breaks into three stages, and each one is professionalized:

Automated recon. Shodan and Censys sweeps for exposed endpoints — unauthenticated Ollama on port 11434, unauthenticated vLLM on port 8000, accessible MCP endpoints, and the forgotten dev and staging AI environments that nobody put behind auth.
Quality based validation. Captured access is graded. Which models can this credential reach? What is the quota? A stolen key to a GPT class or Claude class model is worth more than one to a toy endpoint, and the operators price accordingly.
Commercial resale. A marketplace called “silver.inc” resells access to 30+ LLM providers at 40 to 60 percent discounts, brokered through Telegram and Discord and paid in crypto and PayPal.

Read that last line again. There is a storefront. The Cloud Security Alliance research note documents the same marketplace dynamics. This is the detail that should change how you brief your leadership: your stolen Bedrock access is a SKU.

Why AI beats crypto as a target

Two things make AI inference a better target than cryptomining ever was, and both are economic.

First, the exposure is uniquely steep. With cryptojacking, your blast radius was bounded by how many instances the attacker could launch before you noticed, and the yield per instance was mediocre. Inference has no such ceiling. Sysdig estimated up to roughly $46,000 a day for Bedrock credential theft at peak quota, and one assessment projects north of $100,000 a day against the most capable frontier models. There is no mining rig that burns money that fast.

Second — and this is the part that keeps me up at night — it hides in plain sight at the API layer. A cryptomining fleet looks anomalous: unusual instance types, sustained 100 percent CPU, outbound traffic to mining pools. A bedrock:InvokeModel call from a compromised but valid IAM identity is indistinguishable at the API layer from legitimate use. There is no malformed packet, no weird binary, no new instance family. Fortinet’s threat research lays out the typical chain, and it is depressingly clean: a leaked long lived IAM key, a freshly created IAM user, a Marketplace model subscription, and then invocation. Every step uses legitimate APIs. Your tooling sees an authorized principal doing authorized things. The only tell is the bill.

The MCP twist: from inflated bill to lateral movement

Here is where a billing problem becomes a breach problem. By late January 2026, a separate MCP focused campaign accounted for roughly 60 percent of honeypot attack traffic. That shift matters because of what MCP servers do: they bridge AI models to file systems, databases, and internal tooling.

An exposed MCP endpoint is not just unauthorized inference. It is a foothold. Compromise one and you are not stealing cycles anymore — you are reading files and querying databases through the model’s tool connections. The “internal tooling” you wired up to make your agents useful is exactly the thing that turns LLMjacking into lateral movement. The economic abuse was the opening move. The MCP vector is the one that gets you a breach disclosure, not just a surprise invoice.

Hype check

So is this just cryptojacking repainted for the AI news cycle? I went in expecting to say yes, and mostly I have to say no.

The mechanism is identical — exposed credentials, internet facing endpoints, automated recon. If that is your definition, then fine, it is the same attack. But two things are genuinely worse. The economics are an order of magnitude steeper, because inference meters money faster than any mining rig. And the MCP blast radius means the worst case is no longer a cleanup and a credit from your account team — it is data exfiltration through a trusted bridge.

Where the hype deflates is the defense. There is no exotic new control to buy. The fundamentals that would have stopped cryptojacking in 2019 stop LLMjacking in 2026. That is the uncomfortable truth: we keep rebuilding the same house on the same unlocked foundation and acting surprised when a new kind of burglar walks in.

Practical takeaways

Fix credential hygiene first. Short lived, role assumed credentials everywhere. No never expiring admin keys. The entire Bizarre Bazaar supply chain starts with a leaked long lived key — kill the input and you kill the campaign.
Assume breach for anything internet exposed. If an Ollama, vLLM, or MCP endpoint is reachable, treat it as already scanned. It will be found within hours. Put auth in front of it or take it off the internet.
Treat cost anomalies as security signals. Wire FinOps to SecOps. A sudden Bedrock spend spike is not a billing ticket — it is potentially your earliest and sometimes only detection signal. Alert on it like an IDS hit.
Govern your model and MCP endpoints. Inventory them, authenticate them, rate limit them, and monitor them. An MCP server with filesystem access and no auth is a breach waiting for a Shodan hit.
Turn on the logs that are off by default. CloudTrail everywhere, and Bedrock model invocation logging, which is not enabled by default. If an invocation is indistinguishable at the API layer from legitimate use, the invocation logs are the only place you will ever see it.

The attackers have already built the marketplace. The question for your security team is not whether your AI resources are interesting to them — they are, and they are priced. The question is whether the boring fundamentals are in place before the recon sweep finds you. They almost never are. Start there.

Cloud,Architecture,AgentCore,Bedrock

Agents Aren't Web Requests — Why AWS Rebuilt the AgentCore Runtime

October 2 2026 Greg Fina Leave a comment

Years ago I sat with a customer who needed to orchestrate multiple agents inside their software products — agents that coordinate, hand work to each other, and stay alive across a workflow, not one model answering one call. We wrote a PRFAQ together, took it into an EBC, and a VP agreed to build it. The document was right. It was also complex — it described, in detail, nearly every capability you can find in AgentCore today. The service team then rewrote it, more than once, not to correct it but to break a correct and complex vision into something they could actually execute and build. The primitives got names and edges they did not have in our draft. But the shape of the thing never changed, because we had the mental model right from the start: these are not web requests. They are sessions.

That is the part I am proud of, and it is the only part that matters here: the vision was correct and complete, and the one idea holding all of it together was that an agent is a session, not a request.

Here is the mental model that quietly breaks the moment you ship an agent to production: “an agent is just a web request that happens to call an LLM.” You wire up an HTTP handler, it fires off a prompt, you stream tokens back, the function returns, the compute is reclaimed. Clean. Stateless. Familiar.

It is also wrong in ways that will cost you. An agent is not a request. It is a process — one that reasons over many turns, accumulates intermediate results, calls tools that mutate state, occasionally reaches for a GPU, and sometimes hands work to other agents. The shape of that workload has almost nothing in common with the shape of an HTTP handler. Amazon’s answer, Amazon Bedrock AgentCore Runtime, is best understood not as “serverless with a bigger timeout” but as a deliberate rethinking of what compute for agents should look like.

What breaks when you run an agent like an HTTP handler

Serverless web infrastructure makes three assumptions that are load bearing for request response traffic and actively hostile to agents.

It assumes statelessness. An HTTP handler is supposed to carry nothing between invocations; that is what lets the platform scale it horizontally without thinking. But an agent’s whole value is the state it carries — conversation history, a scratchpad of intermediate reasoning, the output of a tool it called two steps ago, a half built file on disk. If every invocation lands on a fresh execution environment with an empty filesystem, you are forced to serialize and rehydrate the entire context on every single turn. That is slow, lossy, and fragile.

It assumes short duration. Request response compute is tuned for work that completes in milliseconds to seconds, with hard timeouts measured in minutes. Agents routinely run for minutes to hours, and some genuinely need to run continuously for days — a transformation job grinding through a corpus, an automation loop that pauses and resumes, a research agent that keeps working while a human is asleep.

It assumes weak isolation is fine. When requests are stateless and ephemeral, co tenancy is mostly an efficiency detail. But agents run privileged, nondeterministic code on a user’s behalf — they get shell access, read and write files, and invoke tools with real credentials. The isolation boundary stops being a performance concern and becomes a security boundary. You cannot have user A’s agent able to observe anything left behind by user B’s.

How AgentCore answers it: isolated sessions, not shared handlers

AgentCore Runtime’s primitive is the session, not the request. Each user session runs in its own dedicated microVM with isolated compute, memory, and filesystem, plus shell access. One user’s agent cannot reach another user’s data, and when the session ends the entire microVM is torn down and memory is sanitized — no cross session residue. That is a deterministic isolation boundary wrapped around a deliberately nondeterministic workload, which is exactly the property enterprises need.

Inside that boundary, the model does the thing HTTP handlers refuse to do: it lets you safely reuse context across invocations. You generate a session ID, pass the same ID on every related call, and each invocation builds on the environment the previous one left behind — same filesystem, same in memory state, same tool context. Multi turn conversations and multi step workflows stop being a serialization problem and become what they always should have been: successive calls into a living environment.

The honest part of the design is that this state is ephemeral by default. In memory and on disk data lives for the session’s lifetime and no longer. For anything that must outlive the session — learned preferences, durable conversation history, workspace files — you pair the runtime with AgentCore Memory for long term recall and Amazon EBS for persistent volumes. The runtime handles scaling, session management, isolation, patching, and observability so you spend your time on agent logic, not plumbing.

Two compute shapes, one set of APIs

The sharpest architectural decision is that AgentCore exposes two compute shapes under the same runtime APIs, so you match the shape of the compute to the shape of the traffic.

Serverless microVMs are the default: fast cold starts, scale to zero, sessions up to 8 hours. This is the right home for request response, spiky, or latency sensitive agents — the chat assistant, the API driven tool, the thing that needs to start instantly and cost nothing while idle.

Runtime instances, generally available since August 6 2026, are AWS managed EC2 running in your own account, defined by a reusable capacity provider (operating system, allowed instance types, networking, storage, IAM roles). Sessions here run up to 14 days, support GPU instance families with drivers provisioned for you, and can stop and restart to save cost — hibernate Monday night, resume Wednesday morning with volumes reattached and data intact. This is the home for long running, continuous, GPU bound, or multi agent work.

Because the instances live in your account, your data and your account controls stay put, and you can apply existing Savings Plans, Reserved Instances, and ODCRs. AgentCore still owns the lifecycle — provisioning, patching, scaling, teardown — so you get EC2 economics without EC2 babysitting.

Multiple agents on one host

Runtime instances change the unit of collaboration. In the microVM model, one runtime hosts one agent. On an instance, a single session can host many agents that share a filesystem. AWS’s own demo makes the point: a writer agent generates code into a shared session directory, and a reviewer agent reads that same file and critiques it — no message passing, no inter agent API calls, no data transfer. They collaborate through the filesystem.

That composes cleanly with the two shapes. A lightweight orchestrator on a microVM can take fast, spiky, API driven traffic and dispatch heavier work to specialized worker agents running on instances — code compilation, security scanning, GUI automation — that need persistent state and direct OS access. And none of this locks you into a framework: bring CrewAI, LangGraph, LlamaIndex, or Strands, and any model. Packaging is minimal — an @app.entrypoint decorator plus a zip or a container image.

The caveat worth saying out loud

Here is where I will push back on the easy narrative. A 14 day session is not a durable workflow. If your process waits days for a human approval, or moves money, or must survive infrastructure failure with transactional guarantees, a single long lived session is a fragile place to park that state. Runtime instances raise the ceiling for continuous work; they do not turn one invocation into a saga. For orchestration that must be durable and recoverable, reach for a real orchestrator — AWS Step Functions over a transactional store — and let the agent be a step inside it, not the system of record.

Two more things to keep honest. Instances do not scale to zero; an idle instance still bills until you stop the session. And the whole point of the two shapes is that neither is universally correct. Match the compute shape to the traffic shape or you will overpay for idle capacity or starve a long job of the persistence it needs.

Takeaways

Model agents as sessions, not requests. Design around a stable session ID and context that lives across invocations, not stateless handlers that rehydrate everything each turn.
Pick the compute shape from the traffic shape. Spiky and latency sensitive goes on microVMs; continuous, GPU bound, or multi agent goes on instances. The APIs are the same, so switching costs are low.
Separate ephemeral session state from durable state. Use the session filesystem for working data, AgentCore Memory and EBS for anything that must outlive it.
Do not confuse long sessions with durable workflows. For human approvals, money movement, or anything needing transactional recovery, put a Step Functions orchestrator in charge and make the agent a step.
Watch idle cost on instances. No scale to zero means you stop sessions deliberately.

The deeper story is that agents are a genuinely new compute primitive, and infrastructure is catching up to that fact. For a decade we bent every workload to fit the web request. AgentCore is a bet that it is time to bend the compute to fit the workload instead. If your agents still look like HTTP handlers in disguise, that is probably the first thing to rethink.

GenAI,RAG,Bedrock,Architecture

Agentic RAG Is Just Retrieval Growing a Spine

September 24 2026 Greg Fina Leave a comment

Ask a naive RAG system a question like “Which of our regions missed their SLA last quarter, and what caused it?” and watch it faceplant. It embeds the whole sentence, pulls the top eight chunks that look vaguely similar, stuffs them into a prompt, and hopes the model can reason its way out. But the answer lives in two different documents — one listing SLA breaches, another explaining root causes — and neither is close enough to the query vector to rank in the top eight. The model gets half the context, confidently fabricates the rest, and you ship a wrong answer with a citation attached.

This is the structural limit of one-shot retrieval. Agentic RAG fixes it not by tuning the embedding model or cranking up k, but by giving retrieval something it never had: the ability to decide. That decision-making capacity is the spine.

The limits of one-shot RAG

Classic RAG is a straight pipeline. Embed the query, run a nearest-neighbor search, take the top k chunks, concatenate, generate. It works beautifully for questions that map cleanly to a single passage — “What is the default timeout for a Lambda function?” — and falls apart everywhere else.

The failure modes are predictable once you see the pattern:

Compositional questions. Answers that require joining facts across documents. Top-k similarity has no notion of “I need one fact from here and another from there.”
Vague or underspecified queries. “How do we handle failures?” retrieves everything and resolves nothing. The query needs sharpening before it can retrieve anything useful.
Multi-hop reasoning. “Who approved the change that caused the outage?” requires finding the outage, then the change, then the approver — three sequential lookups, each depending on the last.
No self-awareness. One-shot RAG cannot tell whether what it retrieved is any good. It retrieves once and commits, whether the chunks are relevant or garbage.

You can paper over some of this with hybrid search, reranking, and bigger context windows. Those help. But they are all still one shot. The system fetches, then generates, and never asks itself whether it fetched the right thing.

What “agentic” actually adds

Agentic RAG wraps retrieval in a control loop. Instead of a fixed fetch-then-generate sequence, the model reasons about the task and treats retrieval as a tool it can invoke — repeatedly, conditionally, and with different arguments each time.

The loop looks roughly like this:

while not satisfied and steps < budget:
    plan  = model.decide_next_action(question, evidence_so_far)
    if plan.action == "retrieve":
        results  = knowledge_base.retrieve(plan.query)
        evidence += model.filter_relevant(results)
    elif plan.action == "answer":
        break
answer = model.generate(question, evidence)

Four decisions live inside that loop that one-shot RAG never makes: whether to retrieve at all (some questions do not need it), what to retrieve (the model writes the search query, not the user), how many times to retrieve, and when the accumulated evidence is good enough to stop. Retrieval stops being a passive lookup and becomes an active, self-directed component. That is what “growing a spine” means — the system now holds itself upright and makes calls instead of flopping through a fixed pipeline.

Core patterns

Three patterns do most of the heavy lifting in production agentic RAG.

Query reformulation. The user’s phrasing is rarely the best search query. An agentic system rewrites it — expanding acronyms, splitting a compound question into parts, or generating several candidate queries and merging the results. When a retrieval comes back weak, it reformulates and tries again rather than committing to bad context.

Multi-hop retrieval. For questions that require chaining, the agent retrieves, reads, and uses what it learned to form the next query. Answering “what caused the SLA miss” becomes: retrieve the breach record, extract the incident ID, retrieve the incident report, extract the root cause. Each hop is a fresh, better-targeted search.

Self-critique and grounding checks. This is the idea behind research like Self-RAG and Corrective RAG (CRAG). The model grades its own retrievals for relevance and grades its draft answer for grounding — is every claim actually supported by a retrieved passage? If a claim is unsupported, it retrieves again or drops the claim. This is the single biggest lever against hallucination, because the system refuses to assert what it cannot cite.

Production realities

A control loop that can retrieve N times is a control loop that can retrieve N times when N gets ugly. The engineering discipline matters more than the pattern.

Latency compounds. Each hop is a full round trip: an LLM call to plan, a vector search, another LLM call to evaluate. A three-hop answer can mean six or seven sequential model invocations. Where hops are independent, fan them out in parallel. Where they are sequential, use a smaller, faster model for the planning and grading steps and reserve the large model for the final synthesis.

Token cost accumulates. Every hop re-sends accumulated evidence into the context window. Naively, a five-hop conversation can burn several times the tokens of one-shot RAG. Summarize intermediate evidence instead of carrying raw chunks forward, and cap how much context each hop contributes.

Guard the loop. Never ship an unbounded while. Enforce a hard ceiling on iterations, a token budget for the whole request, and a wall clock timeout. Track a confidence or novelty signal — if two consecutive hops add nothing new, stop. A runaway agent that retrieves forty times is worse than a wrong answer, because it is a wrong answer that also costs forty dollars.

Evaluate retrieval separately from generation. Measure retrieval quality (recall, precision, whether the right passages showed up) independently from answer quality (faithfulness, correctness). A good final answer built on lucky guesses is a landmine. Build a labeled question set and track both metrics as you tune. Frameworks like Ragas exist precisely for this split.

Building it on AWS

You do not have to hand-roll the whole loop. AWS gives you the pieces at two levels of abstraction.

The managed retrieval layer. Amazon Bedrock Knowledge Bases handles ingestion, chunking, embedding, and vector storage, and exposes a Retrieve API for raw passages and a RetrieveAndGenerate API for one-shot answers. In an agentic design you lean on Retrieve as the tool your loop calls — the agent owns the reasoning, the Knowledge Base owns the fetch.

The managed orchestration layer. Agents for Amazon Bedrock runs the reason-act loop for you. You attach a Knowledge Base and define action groups, and the agent plans, decides when to query, invokes tools, and iterates — emitting a reasoning trace so you can see why it retrieved what it did. That trace is not a nicety; it is how you debug and audit a multi-hop answer.

The build-versus-buy line is straightforward. If your loop is standard retrieve-reason-retrieve, let Agents orchestrate it and save yourself the state machine. When you need custom stopping logic, parallel fan-out, or tight control over every model call, drop to the Retrieve API and orchestrate yourself — with Step Functions for durable multi-step flows or a framework like LangGraph running on Lambda or ECS for tighter loops.

Closing take

Agentic RAG is not a wholesale replacement for classic RAG — it is classic RAG that finally learned to think about what it is doing. And it is not free. Every hop costs latency, tokens, and complexity, so reach for it when your questions genuinely demand it: compositional queries, multi-hop reasoning, high-stakes answers that must be grounded and defensible.

For a lookup that maps to a single passage, one-shot RAG is faster, cheaper, and completely adequate. Do not grow a spine where a reflex will do. But the moment your users start asking real questions — the kind that span documents and require the system to reason about its own uncertainty — passive retrieval breaks, and the loop is what holds the answer up.