Context Windows Are Your New Attack Surface

The Productivity Advice Nobody Pairs With the Risk

Every AI productivity guide tells you to stuff as much context into your prompt as possible. Paste in the whole codebase. Drop in the full meeting transcript. Give the model everything — it performs better with more context, so more is always better.

That’s not wrong. But it’s incomplete in a way that should make any security-conscious team pause.

Context windows are where your AI does its best work. They’re also where your most sensitive data goes to live for the duration of a session, gets echoed back in outputs, and occasionally ends up in places you didn’t intend. I’ve spent over two decades watching organizations get burned by treating performance and security as separate conversations. Context window management is the latest version of that mistake.

Here’s how I think about it — and what I’ve changed in my own workflow as a result.

What’s Actually In Your Context Window

When you interact with an AI assistant, the model doesn’t have persistent memory between sessions (with some exceptions we’ll get to). What it has is the context window: everything currently loaded into the active session. That includes your system prompt, the conversation history, any documents or code you’ve pasted in, and tool call results if you’re running an agentic workflow.

In a typical enterprise session, that context might contain:

• Internal process documentation with organizational structure details
• Code with hardcoded environment variable names (sometimes worse)
• Customer data excerpts pasted in to “give the AI an example”
• Authentication flows, API endpoint structures, internal tooling names
• Employee names, roles, project names — the organizational map an attacker would love

None of this is hypothetical. I’ve seen developers paste database schemas into AI chat interfaces to get help writing queries. I’ve seen analysts drop in support ticket exports to summarize trends. I’ve seen people share architecture diagrams in text form to get feedback. All of that data is now in the context window, and depending on your AI provider’s data handling policies, logging configuration, and your organization’s controls — you may have limited visibility into where it goes from there.

The Three Context Risks Worth Operationalizing

I’m not going to tell you to stop using AI or to starve it of context — that defeats the purpose. But there are three specific risks I think about when designing AI workflows for any team handling sensitive data.

1. Context exfiltration via prompt injection

I covered prompt injection in depth in a recent post. The short version: if your AI workflow ingests external content — emails, documents, web pages, tickets — an attacker can embed instructions in that content designed to manipulate the model’s behavior. One reliable manipulation target is the context itself. A malicious instruction can tell the model to summarize and output sensitive context as part of its response, or to include it in a tool call that routes data somewhere unexpected.

The mitigation isn’t just “sanitize inputs.” It’s thinking architecturally about what data should ever be in the same context window as external content. Keep high-sensitivity context segregated from workflows that process untrusted input.

2. Accidental output exposure

Models are very good at synthesis. Give them enough context and they’ll produce outputs that surface sensitive details you didn’t explicitly intend to share. A developer asks for help writing release notes from a sprint summary. The model helpfully includes internal project codenames, the name of the security vulnerability being patched, and the previously-confidential deployment timeline — all of which were in the context but weren’t supposed to be public-facing.

This isn’t the model misbehaving. It’s doing exactly what you asked. The problem is context contamination: sensitive material mixed into a context being used for a less-sensitive task.

The workflow fix: define context tiers. What’s safe for external-facing tasks gets loaded into those sessions. Internal-only context stays in internal-only sessions. This sounds obvious until you watch how most teams actually work, which is one context window, everything thrown in, let’s go.

3. Persistence and memory features

Some AI tools now offer memory — the ability to store information across sessions. This changes the threat model significantly. A context window is ephemeral by default; memory is not. If a user’s AI assistant is configured to remember organizational details, project specifics, or workflow patterns, you’ve now got a persistent data store with its own access controls, backup implications, and exfiltration surface.

Before enabling memory features in any enterprise AI deployment, treat it like you’d treat any new data store: Where does it live? Who can access it? How is it encrypted? What’s the retention policy? What’s the deletion process? If you can’t answer those questions, memory stays off.

What I Actually Do in My Workflow

When I’m working on ABT infrastructure, I run different Claude Code sessions for different sensitivity tiers. One session handles public-facing content and the blog pipeline — no internal architecture details in that context. A separate session handles anything touching configuration, tooling, or internal process logic. They don’t share context.

I also have a rule I hold myself to: before pasting anything into an AI session, ask whether I’d be comfortable with that content appearing verbatim in the output. If the answer is no, it doesn’t go in — or I strip it down to the minimum necessary structure without the sensitive details.

For code specifically, I paste schemas with fake data, not production data. I describe authentication flows without including actual credentials or token formats. I use placeholder values for anything that looks like it could be sensitive, even if the current value isn’t. Habits built in low-stakes contexts hold in high-stakes ones.

A Checklist for Teams

If you’re formalizing AI use across a team, add context hygiene to your AI policy. Here’s a starting point:

• No production data in AI sessions. Use anonymized or synthetic datasets for AI-assisted analysis.
• No credentials, tokens, or secret names in context. Not even “example” credential formats that mirror real ones.
• Define context tiers. Internal-only content goes in internal-only sessions. External-facing tasks use sanitized context.
• Audit memory features before enabling. Apply the same data governance standards you’d use for any persistent store.
• Review AI outputs before external publication. Models surface what’s in context. Check outputs for inadvertent disclosure.
• Inject-aware workflows. Any workflow that ingests external content should be architecturally isolated from high-sensitivity context.

None of this is burdensome if you build it into the workflow design from the start. Retrofitting security onto an AI deployment after something goes wrong is the expensive version.

The Broader Point

Context windows are a performance tool and a security boundary simultaneously. The teams getting the most out of AI without creating new exposure are the ones who designed their workflows with both properties in mind from day one — not the ones who optimized for performance first and worried about security later.

The “more context is always better” advice is right about model performance. It’s silent about everything else. Fill in that gap before your compliance team does it for you.