We Secured the AI. Then We Checked the Laptop.
How to use AI agents with sensitive data you can't send directly to Anthropic, the hidden security risks you need to know, and how to protect against them.
Imagine a doctor walks into your office with a simple request.
Doctor: “Hey, can I use Claude to help me analyze patient information?”
Me: “Of course! AI is amazing.”
Doctor: “Great! So can I start?”
Me: “Well…”
Welcome to AI with sensitive data. Everyone wants AI superpowers. Nobody wants their private information ending up somewhere it shouldn’t.
And sometimes, even after securing everything, there’s one tiny detail you forgot. Usually, it’s a folder.
We’ve Become a Little Too Comfortable With AI
If you’re a developer using Claude Code, your relationship with AI probably looks something like this:
“Hey Claude, here’s my entire codebase, access to my terminal, and basically all my permissions. Please fix this before lunch.”
And honestly? It’s incredible.
But what happens when the information isn’t your codebase? What if it’s medical records, financial information, or confidential customer data?
Suddenly, “give Claude access to everything” sounds a little less exciting.
In healthcare, regulations like HIPAA and GDPR introduce additional requirements for handling sensitive information. You can’t simply send patient data to any AI service without the appropriate legal basis, agreements, and security controls.
So, how do we give doctors access to Claude without compromising their patients’ privacy?
Amazon Bedrock to the Rescue!
Meet Amazon Bedrock. It lets us access models like Claude through AWS-managed infrastructure instead of connecting directly to Anthropic's API.
For organizations already running sensitive workloads on AWS, that’s a big advantage. With the right agreements and security configuration, Bedrock can be part of an approved environment for processing medical information.
And the best part? Claude Code supports Bedrock directly.
export CLAUDE_CODE_USE_BEDROCK=1Of course, we still need to configure AWS authentication, permissions, and model access. But now we have a way to use Claude Code through our approved AI infrastructure.
Doctor: “So I can finally use Claude?”
Me: “Yes!”
Doctor: “And everything is secure?”
Me: “Absolutely!”
Well… Almost.
Plot Twist: Claude Code Keeps a Diary
Here’s something interesting about Claude Code. By default, it saves conversation transcripts locally.
Where? Right here:
~/.claude/projects/Inside that folder, you’ll find JSONL files containing session history, potentially including prompts, responses, and tool outputs.
And remember our doctor? The one analyzing sensitive patient information? Some of that information might now exist as readable text files on the computer running Claude Code.
Think about that. We carefully configured AWS, reviewed security requirements, checked compliance, and secured the connection to the model. Then we discovered patient information could be sitting in a local folder.
We secured the model. But what about the agent?
Don’t Worry, Claude Deletes Old Sessions!
Luckily, Claude Code has automatic session cleanup. By default, sessions older than 30 days are removed when its cleanup process runs.
Great, right? Not exactly.
First, 30 days is a long time for sensitive information to sit on a workstation.
Second, cleanup happens when Claude Code runs, not through a continuously running background service. If you never open Claude Code again, the old files might just stay there.
So our security strategy now depends on someone remembering to open their AI assistant. Not ideal.
Fortunately, there’s another option. We can disable local prompt history and session transcript persistence:
export CLAUDE_CODE_SKIP_PROMPT_HISTORY=1Problem solved? Not so fast.
The Agent Doesn’t Need a Diary to Leave Evidence
Claude Code isn’t just a chatbot. It’s an agent. It reads files, runs commands, generates reports, and creates new files.
Imagine our doctor asking:
“Analyze these medical records and create a summary.”
Claude might generate temporary files, export a CSV, or save a report somewhere on the filesystem. And those files might contain sensitive patient information. Even with session history disabled.
We stopped Claude from keeping a diary. But we didn’t stop it from leaving sticky notes everywhere.
That’s the real challenge. It’s not just about where the AI model processes our data. It’s about every place the agent can write it.
The Next AI Agent Doesn’t Care About Your Bedrock Configuration
Imagine another AI agent running on the same laptop. Maybe it’s another coding assistant. Maybe it’s connected directly to an AI provider that hasn’t been approved to process medical information. And maybe it has access to the same local files.
That agent doesn’t care that our first Claude session used Bedrock. It just sees a file it can read. And if it includes patient information, that data could now be sent to a completely different AI service.
Our first agent followed the rules. The second agent might not even know those rules exist.
Suddenly, configuring Claude Code correctly doesn’t seem like a complete security strategy. Because the problem isn’t only which AI service receives our data. It’s also which processes can access the data after it reaches the computer.
You Can’t Fix an OS Problem With One Claude Setting
So what’s the solution? We need security controls that operate independently of the AI agent itself. Not just another prompt saying, “Claude, please don’t save sensitive files.”
We need continuous visibility and enforcement at the operating-system level. That means monitoring actual filesystem operations, process activity, and network connections.
When an agent creates a file containing sensitive information, we need a way to protect it from unauthorized access, keep it inside an approved environment, and ensure it is cleaned up according to policy.
If another agent attempts to read that file, security controls should be able to restrict or block the access. If an agent tries to send sensitive data to an unapproved endpoint, network controls should be able to stop it.
And all of this needs to work even when the agent uses a different tool, launches another process, or changes its approach. Because the agent shouldn’t be the only one responsible for enforcing its own security rules.
Claude Code’s built-in permissions, settings, and sandboxing are useful. But they don’t replace security controls protecting the entire machine. This is why an independent runtime security layer matters.
So, Can the Doctor Finally Use Claude?
Our doctor just wanted an AI assistant. We thought the challenge was securing the model connection. Then we discovered local transcripts. We disabled them. Then we discovered the agent could still create files. And finally, we realized other agents might be able to access those files.
That’s when the real lesson became clear:
Securing an AI model isn’t the same as securing an AI agent.
And securing one AI agent isn’t necessarily enough to secure the entire endpoint.
This is exactly the kind of problem we’re working on at Bluebear.
Bluebear provides visibility and control at the point where AI agents actually execute, including their commands, file access, tool calls, and network activity. Instead of relying only on what an agent is configured to do, we can enforce policies against what it actually does.
Combined with proper isolation, data-access controls, and retention policies, that gives organizations a stronger foundation for working with sensitive information.
Because sometimes the biggest security risk isn’t a sophisticated attack. It’s a perfectly legitimate AI agent doing exactly what we asked. And leaving a file behind for the next agent.
Want to see why agent security needs to go beyond individual tools?
Read our research: The tool blocked it, but the agent kept going.
Or request a Bluebear demo to explore runtime visibility and security controls for your AI agents.
