Human Brain vs LLM Context Window: Memory, Attention and AI Security

A person holds roughly four meaningful chunks in working memory, filters hard with attention, and slowly consolidates what matters into long-term memory. A large language model holds everything in its context window word for word, up to a million tokens on current flagship models, weighs every token against every other, and keeps none of it after the request ends. The security consequence follows directly: a model has no separate channel for instructions, so anything that lands in its context, from a retrieved web page to a tool result, can steer what it does next.

This post compares the two systems with the primary research behind each claim, says where the comparison stops working, and turns the difference into controls for teams that use AI assistants and agents every day.

Key takeaways

• Different units. Human working memory is limited to about four chunks (Cowan, 2001), and expertise makes each chunk carry more. A context window is measured in tokens, all kept verbatim until the request ends.
• Different attention. Human attention selects and discards. Transformer self-attention computes a weight between every pair of tokens, so its cost grows with the square of sequence length (Vaswani et al., 2017).
• Bigger is not better used. Models use the start and end of a long context better than the middle (Liu et al., 2023), and most models in the RULER benchmark lost accuracy well before their advertised limits.
• Context never becomes knowledge. Weights do not change at inference time. What looks like memory is retrieval, summaries and files pasted into the next context.
• Everything in context can steer the model. Prompt injection, poisoned retrieval stores, hostile tool output and long-session instruction drift all use the same fact: instructions and data share one channel.
• Where Safeguard fits (all GA): AI-BOM discovery and AI agent discovery find the models, agents and MCP servers in use; agent identity tracks which agent holds what access; MCP Guardrail puts a policy proxy in front of MCP servers; the AI Gateway (LLM firewall) checks prompts, retrieved content and responses; policies and gates enforce your rules with Block, Warn and Notify, and exceptions for approvals.

The situation

You use an AI assistant most of the working day. Your engineers run coding agents that read repositories, call tools over the Model Context Protocol (MCP) and open pull requests. Your platform team is wiring a retrieval system into a support bot. Someone asks a fair question: "These models now have a million-token memory. Will they remember everything we tell them, and is that a problem?"

The honest answer has two halves. "Memory" is the wrong word for most of what a context window does, and the gap between how people remember and how models process context explains a lot of surprising model behaviour. And the security problem is not that a model remembers too much. It is that a model treats whatever is in front of it as material to act on, and in an agent, much of that material was written by people you have never met.

A bad week, as an illustrative scenario: an agent that summarises vendor tickets reads one ticket containing text dressed up as an instruction. Three tool calls later it has pasted an internal document into a reply. Nobody changed the system prompt or broke authentication. The fix is not a better prompt. It is knowing what reaches the context, from where, and what the agent may do with it.

The two systems side by side

Each row is explained, with sources, in the sections that follow.

Human working memory: how much, and in what units

Miller's seven, plus or minus two

The most quoted number in cognitive psychology comes from George Miller's 1956 paper in Psychological Review, "The magical number seven, plus or minus two: Some limits on our capacity for processing information" (volume 63, pages 81 to 97). Miller noticed that across experiments on judgement and immediate memory, people handled around seven items before performance broke down, and that people recode information into larger units he called chunks.

Nelson Cowan's later review is candid about that number: Miller's seven "was meant more as a rough estimate and a rhetorical device than as a real capacity limit."

Cowan's four

In 2001 Cowan published "The magical number 4 in short-term memory: A reconsideration of mental storage capacity" in Behavioral and Brain Sciences (volume 24, pages 87 to 114). He gathered evidence from many paradigms and argued that when people are prevented from rehearsing or grouping items into bigger chunks, a single central capacity limit appears, averaging about four chunks. Others had proposed three to five. Cowan tied the limit to the focus of attention.

Vision points the same way. Steven Luck and Edward Vogel (Nature, 1997) found people could retain about four colours or orientations at once, but could also retain both the colour and orientation of four objects, and objects defined by four features were held as well as single-feature objects. Sixteen features fit when bound into four objects. Capacity was set by objects, not raw features.

That is chunking. The limit is on bound units, and experience changes how much each unit carries. A senior engineer reading a stack trace does not hold forty lines; they hold "null pointer in the retry path after the config reload", one chunk built from years of exposure.

A workspace, not a box

Alan Baddeley and Graham Hitch's 1974 working memory model replaced the single short-term store with a small system: a central executive that directs attention, plus stores for verbal and visuospatial material. In 2000 Baddeley added the episodic buffer (Trends in Cognitive Sciences, volume 4, pages 417 to 423), a limited-capacity store that binds information from the other components and from long-term memory into one episode.

Two features carry over to the AI comparison. Human working memory is active: an executive decides what to keep and what to drop. And it is integrated with long-term memory: what you already know shapes what you can hold. A context window has neither property. It is a passive buffer the model reads in full on every step, and its contents never fold into what the model knows.

Attention: selection in the brain, weighting in a transformer

In people, attention is selection. Most of what reaches the senses is never encoded, and what is attended competes for a few slots.

In a transformer, attention is a calculation. The 2017 paper that introduced the architecture, "Attention Is All You Need" by Vaswani and colleagues, gives the complexity of a self-attention layer in its Table 1 as O(n²·d), where n is the sequence length and d the representation size. Every token computes a weight against every other token, which is why a question at the end of a long prompt can connect to a fact at the start in one step.

Anthropic's engineering guide to context engineering (29 September 2025) spells out the consequence: n tokens means n² pairwise relationships, and as context grows the model's ability to capture them "gets stretched thin". The guide calls this an attention budget and compares it to limited human working memory. That metaphor is useful for engineering decisions. It does not claim the mechanisms are the same.

The FlashAttention paper (Dao and colleagues, 2022) notes that the time and memory complexity of standard self-attention are quadratic in sequence length, then shows an exact algorithm that cuts memory traffic on the GPU. Work like this made long windows practical without changing the basic fact: every token in the window takes part in every step.

For a security reader, the difference is simple. A person under load ignores things. A model cannot ignore anything in its window. It can give a passage low weight, but the passage remains an input to every token it generates.

The context window, precisely

What counts toward it

Anthropic's documentation defines the context window as all the text a model can reference when generating a response, including the response itself, and calls it a "working memory" for the model, distinct from its training data. Everything in the request counts: the system prompt, every message (including tool results, images and documents), the tool definitions, and the output, including extended thinking.

That list is the security perimeter of a model call. If a value is in any of those places, the model can read it, repeat it and act on it.

How large windows are now

Sizes have grown fast, so dates matter.

• Anthropic's many-shot jailbreaking note (2 April 2024) says that at the start of 2023 windows were about 4,000 tokens, the size of a long essay, and that some models then had 1,000,000 tokens or more, the size of several long novels.
• Anthropic's context window documentation, read on 26 October 2026, lists a 1M-token window for a set of current Claude models, with up to 128k output tokens per request; other Claude models have 200k.
• Google's Gemini API long-context documentation, read the same day, says many Gemini models have windows of 1 million or more tokens.

The KV cache: why long context costs memory

A model generates one token at a time, and each new token attends to all earlier ones. To avoid recomputing keys and values for the whole prefix at every step, inference systems store them in the key-value (KV) cache, which grows with context length.

The vLLM paper (Kwon and colleagues, 2023) describes per-request KV cache memory as huge and as growing and shrinking dynamically, and applies operating system paging to it, reporting two to four times higher throughput at the same latency than the systems it compared. Pope and colleagues (2022) showed that multiquery attention, where query heads share one key and value head, lowers memory enough to support up to 32 times longer contexts in their setup.

Two lessons for the analogy. The KV cache belongs to the current request; it is not a memory of past ones. And its cost is a physical limit on window size and price, which is why vendors invest in compaction and retrieval rather than growing windows forever.

Lost in the middle, and context rot

If a context window were a perfect working memory, a fact anywhere in it would be equally usable. It is not.

In "Lost in the Middle" (arXiv, July 2023), Nelson Liu and colleagues found that on multi-document question answering and key-value retrieval, performance was often highest when the relevant information sat at the beginning or end of the input and dropped significantly in the middle, even for models built for long contexts.

The RULER benchmark (Hsieh and colleagues, arXiv, April 2024) tested 17 long-context models on 13 tasks, including multi-hop tracing and aggregation. Models scored nearly perfectly on the simple needle-in-a-haystack test, yet almost all lost accuracy as length grew. All claimed 32K tokens or more; only half kept satisfactory performance at 32K.

Anthropic's documentation names the effect: "As token count grows, accuracy and recall degrade, a phenomenon known as context rot."

The resemblance to the human serial position effect, where people recall the first and last items of a list best, is only skin deep. Same shape, different causes, different remedies.

Long-term memory: consolidation versus fixed weights

How people store things

People do not write the day straight into permanent storage. The complementary learning systems account (McClelland, McNaughton and O'Reilly, Psychological Review, 1995) starts from the observation that hippocampal damage disrupts recent memory but spares remote memory. New memories are stored first through fast changes in the hippocampus, then reinstated in the neocortex, which changes a little each time, so new items are interleaved with existing knowledge rather than overwriting it.

Sleep plays a part. Diekelmann and Born's review "The memory function of sleep" (Nature Reviews Neuroscience, 2010) describes slow-wave sleep coordinating the reactivation and redistribution of hippocampus-dependent memories to the neocortex.

The long-term store is very large. Brady and colleagues (PNAS, 2008) showed people 2,500 object pictures over five and a half hours. Asked later which of two images they had seen, participants were right 92 percent of the time against an object from a new category, 88 percent against another object of the same kind, and 87 percent against the same object in a different state or pose.

Forgetting is structured too. Murre and Dros (PLOS ONE, 2015) replicated Ebbinghaus's forgetting curve: one subject spent 70 hours learning lists and relearning them after 20 minutes, 1 hour, 9 hours, 1 day, 2 days or 31 days. The results resembled Ebbinghaus's original data, with a probable jump upward at the 24-hour point, which some researchers attribute to sleep.

How models "remember"

A model's knowledge lives in its weights, set in training. Nothing in a context window changes them at inference time. Everything that looks like long-term memory in an AI product is a layer around that fact:

• Retrieval-augmented generation (RAG). Lewis and colleagues (2020) framed RAG as combining parametric memory (the weights) with non-parametric memory (in their case a dense vector index of Wikipedia). Retrieved passages are pasted into each request's context.
• Virtual context management. MemGPT (Packer and colleagues, 2023) borrowed hierarchical memory from operating systems, moving information between the small fast context and larger slow stores.
• Compaction. Anthropic's documentation calls server-side compaction the primary strategy for long-running conversations and agentic work: older context is condensed so work can continue.
• Memory files and tools. Agents write notes to a store and read them back later as ordinary text.

The structural difference matters. People consolidate by slowly integrating new material with what they know, and most of what they encounter is never consolidated. Model memory layers save text and paste it back, without integration, without a consistency check, and by default without a record of who wrote it.

Forgetting: decay versus truncation and compaction

People lose information gradually, through fading and interference, and keep the gist. A model's context does not fade. A token on page one of a 900-page context is as present as the last one, even if the model uses it less well. Information leaves in three abrupt ways: the request ends; older turns are truncated (Anthropic's docs note chat interfaces can manage the window first in, first out); or older turns are replaced by a model-written summary.

Each is a security decision point. Truncation can silently drop the instruction you set at the start of a session. A summary can keep an attacker's instruction and drop your caveat, because the summariser reads the same mixed context. Saved memory can carry injected text into the next session.

Where the analogy breaks

1. Units. Four chunks and a million tokens are not on one scale. A chunk is structure built from experience; a token is a fragment.
2. Fidelity. Human memory reconstructs. A context window is verbatim, which is why a model can quote a credential from 300 pages earlier and a person cannot.
3. Selection. People filter before encoding. A model processes everything in its window on every step.
4. Consolidation. Models do not learn from context at inference time. Persistence comes only from saved text re-entering a later context.
5. Source monitoring. People distinguish "my manager told me" from "I read it on a note in the lobby". In a model's context, the system prompt, the user, a retrieved document and a tool result are all tokens. Formatting and training help the model tell them apart, but there is no hard boundary.
6. Failure mode. Human memory fails by losing things. Long-context models fail by keeping everything and using it unevenly.

The fifth break is the one that matters for security: a language model has one input channel, and instructions and data share it.

The security consequence: whatever is in context can steer the model

Kai Greshake and colleagues put it well in their 2023 paper on indirect prompt injection: LLM-integrated applications "blur the line between data and instructions." They showed attackers planting prompts in data likely to be retrieved, and found that processing retrieved prompts can act like arbitrary code execution, changing what the application does and which APIs it calls.

OWASP's Top 10 for LLM Applications 2025 lists prompt injection as LLM01. It describes indirect injection as arising when a model accepts input from external sources such as websites or files, notes that injected content need not be visible to a human as long as the model parses it, says research shows RAG and fine-tuning do not fully mitigate the problem, and recommends human-in-the-loop controls for privileged operations. NIST AI 100-2 E2025, NIST's taxonomy of adversarial machine learning, gives the shared vocabulary to cite in internal policy.

Five routes reach the context window. None requires touching the model, its weights or your credentials.

1. Retrieved documents

A retrieval pipeline that indexes tickets, wiki pages, emails, web pages or vendor documents is a write path into your model's context. Whoever can get a document into the index can put text in front of the model.

2. Tool outputs and MCP servers

In an agent, every tool result is pasted into context. The MCP specification (revision 2025-06-18, Tools) says there SHOULD always be a human in the loop with the ability to deny tool invocations, and that clients MUST treat tool annotations as untrusted unless they come from trusted servers. Its security considerations say servers MUST validate inputs, enforce access controls, rate limit invocations and sanitise outputs, and clients SHOULD confirm sensitive operations, show tool inputs before calling, validate results before passing them to the model, set timeouts and log tool usage.

Tool descriptions are context. Tool results are context. A third-party MCP server added for convenience writes directly into what your agent reasons over.

3. Context and memory poisoning

Retrieval and memory stores are durable, so poisoning them pays off repeatedly.

• PoisonedRAG (Zou and colleagues, 2024) reported a 90 percent attack success rate when injecting five malicious texts per target question into a database of millions of texts, and found the defences it evaluated insufficient.
• AgentPoison (Chen and colleagues, 2024) targeted agents' long-term memory or knowledge bases, reporting average attack success above 80 percent across three agent types, with a poison rate under 0.1 percent and under 1 percent impact on normal performance.

These are research settings with specific threat models; read the percentages as proof the attack class is practical, not as a forecast for your system.

4. Secrets in context

A context window is verbatim and fully readable by the model. A token, password, customer record or internal URL that lands in a prompt, retrieved document, tool result or saved memory can be repeated in an answer or passed to a tool, and injected text in the same context can ask for exactly that. The controls that work are upstream: keep credentials out of prompts and tool results, give tools scoped and short-lived access, and treat anything an agent can read as something it can disclose.

5. Long sessions and fading guardrails

The instruction you set at the start, such as "never send customer data outside the company", is just more tokens.

• Li and colleagues (2024) measured significant instruction drift within eight rounds of conversation in the chat models they tested, and linked it partly to attention decay over long exchanges.
• Anthropic's many-shot jailbreaking research showed that filling a long context with many faux dialogues, up to 256 in their tests, could override safety training that held against a handful. The effect followed the same kind of power law as ordinary in-context learning: the property that makes long context useful is the one the attack uses.
• Truncation and compaction can remove or rewrite an early instruction unnoticed.

A rule you care about should not live only as a sentence in the context. Put it in code, in tool permissions, or in a check that runs outside the model.

Step by step: context hygiene for teams that run agents

This works with whatever tools you already have.

1. List every write path into context for each assistant or agent: system prompt, user input, retrieval indexes, tool results, MCP servers, memory files, uploads, browsing.
2. Label each source by who can write to it: your team, your company, your customers, or anyone on the internet. Anything writable by the public is untrusted, however it is formatted.
3. Match tool power to source trust. An agent that reads untrusted content should not send email, push code or move money without human approval.
4. Narrow the tools. Give each agent only the MCP servers and tools it needs, read-only by default. Review a new MCP server like a new dependency.
5. Keep credentials out of context. Tools should authenticate for the agent with scoped, short-lived credentials.
6. Put hard rules outside the model, in tool permissions, network policy or a proxy that checks calls.
7. Inspect both boundaries. Check retrieved content and tool output for injection before it reaches the model, and check output for sensitive data before it leaves. Expect misses and layer the checks.
8. Control memory writes. Decide which agents may save memory and record where each saved item came from.
9. Budget context. Keep sessions short, restate critical constraints near the point of use, and test what compaction keeps.
10. Log tool calls and decisions. You will need them the first time an agent surprises you.

Context source trust table

How Safeguard does this

Safeguard's AI and agent security capabilities map onto those steps: find what is in use, give agents an identity and a scope, and check the two boundaries where context enters and leaves. Everything below comes from Safeguard's offering documentation and docs.safeguard.sh. Commands appear only where the docs show them, and none was run for this post.

1. Find what feeds context, with AI-BOM discovery (GA). The docs describe an inventory across code (AI SDK imports, model weight files, prompt templates, notebooks and MCP server configuration), cloud (managed inference endpoints found through cloud connectors) and connected SaaS (unsanctioned AI tools found through shadow-AI detection). Vector databases are recorded as vector stores and agent definitions as agents, assembled into an AI bill of materials per product. That is checklist step 1.

2. See the agents on your people's computers, with AI agent discovery (GA). The Safeguard CLI and Desktop app detect supported AI coding agents, what each may do (shell commands, file edits, network access, auto-approved tools), the MCP servers each connects to and the tools seen in use, and session activity including token use and MCP tool calls. Results appear under Assets › Inventory › Asset discovery. Credential values are never read, only their names. An administrator turns it on for the organisation and chooses whether each person is asked or everyone is enrolled with a notice. The docs show these CLI commands, where show prints what the next run would send without sending anything:

safeguard aidr collect status
safeguard aidr collect on
safeguard aidr collect show

3. Give each agent an identity and a scope, with agent identity (GA). Agent identity tracks which agent holds what access, at what level. The Guard docs describe the records behind it: each MCP server and agent is registered, agents carry a status (active, blocked or quarantined), running risk and anomaly scores and request counters, and an agent can be blocked or quarantined directly. Policies can then target one agent or server instead of everything.

4. Put a policy proxy in front of MCP servers, with MCP Guardrail (GA). MCP Guardrail generates guardrail proxy URLs for MCP servers so agent tool traffic passes through policy. Per the docs, you point the agent at the proxy instead of the upstream server, and every JSON-RPC call is evaluated before it is forwarded. Rules match tool names with glob wildcards and resolve to allow, deny or monitor, and can also filter content, such as masking PII in tool responses, capping row counts or catching jailbreak attempts in tool inputs. That covers steps 4, 6 and 10 in one place.

5. Keep Safeguard's own MCP server narrow. The tool gating docs describe a small default set of read-only tools for a new workspace; everything else, including tools that add integrations or start scans, ships disabled until an administrator enables it per tenant. Discovery and execution resolve from the same list, and if resolution fails the server falls back to the small default set rather than exposing more.

6. Check what enters and leaves the model, with the AI Gateway (LLM firewall, GA). The gateway sits between your application and the model provider, as an inline proxy or a thin SDK shim. It checks prompts for direct injection and jailbreak patterns, checks retrieved or tool-supplied content for indirect injection (the docs note RAG results and tool output are untrusted), checks responses for PII leaving in the output, and can enforce output schemas. Monitor mode is the default: each decision is recorded as a guardrail event while traffic passes unchanged. Enforce mode, which redacts or blocks per your policy, is an explicit per-tenant opt-in. It fails open with an alert by default, so a gateway problem never breaks your application, and raw prompt and response text is never persisted. The docs say there is no CLI command for the gateway yet; it is configured per tenant.

7. Enforce standing rules, with policies and gates (GA). Policies generate findings and gates enforce them with Block, Warn and Notify. Approvals run through time-boxed exceptions that appear in the audit log and expire automatically. Static AI findings, such as model scans and agent and MCP analysis, land in the unified findings model with the rest of your security work.

What Safeguard does not do

• It does not change how a model uses its context. Lost in the middle, context rot and instruction drift are model properties. Safeguard controls what reaches the context and what leaves it.
• It does not catch every injection. The AI Gateway uses pattern and classifier detection, and some injected text looks like ordinary content. Least-privilege tools behind it still matter. This post quotes no detection rate, and Safeguard publishes none for these checks.
• It does not find every agent by itself. Guard's MCP server and agent records are registered explicitly; the docs say no network scan creates them. AI agent discovery covers the supported coding agents its docs list, on computers where it is turned on.
• It does not block by default. The AI Gateway starts in monitor mode and fails open unless a tenant opts into enforcement or fail-closed behaviour. Turning enforcement on is your decision.
• It does not design your retrieval or memory. What gets indexed, who may write agent memory and what compaction keeps are your architecture choices.
• It does not replace human approval for high-impact actions. Safeguard enforces policy and records decisions; a person decides what an agent may do on its own.

Common mistakes

1. Reading window size as memory quality. A 1M-token window says how much fits, not how well it is used.
2. Using the system prompt as a security control. It is one set of tokens among many, open to drift and contradiction.
3. Trusting internal systems by location. A ticket or wiki page can contain an outsider's text. Trust follows who can write.
4. Adding MCP servers like browser extensions. Each writes into your agent's context and may hold real permissions.
5. Putting credentials in prompts or tool results. Once in context, the model can repeat them.
6. Letting agents write memory without provenance. Saved text returns in future sessions as ordinary context.
7. Enforcing before baselining. Run checks in monitor mode, review events, then enforce.

FAQ

Is an LLM context window the same as human working memory?

No. Both are limited, short-lived workspaces, which is why vendors borrow the phrase. But human working memory holds about four chunks and actively selects, while a context window holds every token verbatim and processes all of them on every step.

Why do models miss things in the middle of a long prompt?

Liu and colleagues (2023) found models use information at the start and end of a long context better than the middle, and RULER showed accuracy falling as context grows, even below advertised limits. Anthropic's docs call this context rot.

Does a larger context window make prompt injection worse?

It widens the surface. More context means more places for untrusted text, and Anthropic's many-shot jailbreaking research showed long contexts enable attacks that fail with short ones.

Do LLMs learn from what I put in the context window?

Not at inference time. Weights do not change during a request. Products that appear to remember you save text or summaries and paste them into later requests, which is also how injected instructions can persist.

What is the KV cache?

A store of keys and values computed for earlier tokens so the model does not recompute them for each new token. It belongs to the current request and is not long-term memory; isolation between requests is a question for your provider's vendor review.

What is indirect prompt injection?

Prompt injection that arrives through content the model reads, such as a web page, an indexed document, an email or a tool result, rather than through the user's message. OWASP covers it under LLM01 in its 2025 Top 10 for LLM applications.

How do MCP servers change the risk?

Each server adds tool descriptions and results to your agent's context and may grant real permissions. The MCP specification says clients must treat annotations from untrusted servers as untrusted and should keep a human able to deny tool calls.

What should an engineering leader do first?

List every source that can write into each agent's context, label who can write to each, and remove high-impact tools from any agent that reads untrusted content without an approval step. Then add inspection and logging at both boundaries.

Related reading

• Direct vs indirect prompt injection
• Agent hijacking and prompt injection
• AI agent memory poisoning
• Agent identity in Safeguard
• Context window size and token cost

The agents, SDKs and MCP servers that fill a context window are software dependencies with vulnerabilities of their own. The section below covers how Safeguard closes the gap between a published fix and the code you actually run.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server with OAuth and shows the person choosing which tools Claude can use. It is the decision this post asks you to make for every MCP server: which tools may write into your agent's context, and with what permissions.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session asked to fix a vulnerable dependency. It reads the finding and advisory, asks before any command that changes something, edits the manifest, runs install and tests with approval, prints a summary and pushes nothing. That approval step is the human-in-the-loop control the MCP specification recommends, applied to an agent that edits code.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Miller (1956), Psychological Review, Crossref record
• Cowan (2001), Behavioral and Brain Sciences, PubMed
• Luck and Vogel (1997), Nature, PubMed
• Baddeley and Hitch (1974), Working Memory, Crossref record
• Baddeley (2000), The episodic buffer, PubMed
• McClelland, McNaughton and O'Reilly (1995), PubMed
• Diekelmann and Born (2010), The memory function of sleep, PubMed
• Brady et al. (2008), PNAS, PubMed
• Murre and Dros (2015), PLOS ONE, PMC full text
• Vaswani et al. (2017), Attention Is All You Need
• Dao et al. (2022), FlashAttention
• Pope et al. (2022), Efficiently Scaling Transformer Inference
• Kwon et al. (2023), PagedAttention
• Liu et al. (2023), Lost in the Middle
• Hsieh et al. (2024), RULER
• Lewis et al. (2020), Retrieval-Augmented Generation
• Packer et al. (2023), MemGPT
• Greshake et al. (2023), Indirect Prompt Injection
• Zou et al. (2024), PoisonedRAG
• Chen et al. (2024), AgentPoison
• Li et al. (2024), Instruction (In)Stability in Language Model Dialogs
• Anthropic docs: Context windows
• Anthropic: Effective context engineering for AI agents
• Anthropic: Many-shot jailbreaking
• Google Gemini API docs: Long context
• OWASP LLM01:2025 Prompt Injection
• NIST AI 100-2 E2025
• MCP specification 2025-06-18: Tools
• Safeguard docs: AI-BOM Discovery
• Safeguard docs: AI agent discovery
• Safeguard docs: AI Gateway
• Safeguard docs: Guard servers and agents
• Safeguard docs: MCP tool gating
• Safeguard docs: Guardrails and enforcement

To try Safeguard yourself, download the apps and CLI and read the Safeguard documentation.

Last reviewed: 26 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.