{"slug": "we-secured-the-ai-then-we-checked-the-laptop", "title": "We secured the AI. Then we checked the laptop.", "summary": "A blog post warns that Claude Code, Anthropic's coding agent, saves conversation transcripts as JSONL files under ~/.claude/projects/ by default, meaning sensitive data such as patient information processed through Amazon Bedrock can persist as readable text on local workstations. The post notes Claude Code's automatic session cleanup removes sessions older than 30 days only when the tool runs, and recommends setting CLAUDE_CODE_SKIP_PROMPT_HISTORY=1 to disable local prompt history and session transcript persistence. The author argues that routing Claude through AWS-managed Bedrock infrastructure secures the model connection but leaves the agent's local footprint unaddressed.", "body_md": "[Back to blog](https://bluebear.io/blog/)\n\n# We secured the AI. Then we checked the laptop.\n\nHow 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.\n\nImagine a doctor walks into your office with a simple request.\n\n**Doctor:** “Hey, can I use Claude to help me analyze patient information?”\n\n**Me:** “Of course! AI is amazing.”\n\n**Doctor:** “Great! So can I start?”\n\n**Me:** “Well…”\n\nWelcome to AI with sensitive data. Everyone wants AI superpowers. Nobody wants their private information ending up somewhere it shouldn’t.\n\nAnd sometimes, even after securing everything, there’s one tiny detail you forgot. Usually, it’s a folder.\n\n### We’ve become a little too comfortable with AI\n\nIf you’re a developer using Claude Code, your relationship with AI probably looks something like this:\n\n“Hey Claude, here’s my entire codebase, access to my terminal, and basically all my permissions. Please fix this before lunch.”\n\nAnd honestly? It’s incredible.\n\nBut what happens when the information isn’t your codebase? What if it’s medical records, financial information, or confidential customer data?\n\nSuddenly, “give Claude access to everything” sounds a little less exciting.\n\nIn 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.\n\nSo, how do we give doctors access to Claude without compromising their patients’ privacy?\n\n### Amazon Bedrock to the rescue!\n\nMeet Amazon Bedrock. It lets us access models like Claude through AWS-managed infrastructure instead of connecting directly to Anthropic's API.\n\nFor 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.\n\nAnd the best part? Claude Code supports Bedrock directly.\n\n```\nexport CLAUDE_CODE_USE_BEDROCK=1\n```\n\nOf 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.\n\n**Doctor:** “So I can finally use Claude?”\n\n**Me:** “Yes!”\n\n**Doctor:** “And everything is secure?”\n\n**Me:** “Absolutely!”\n\nWell… Almost.\n\n### Plot twist: Claude Code keeps a diary\n\nHere’s something interesting about Claude Code. By default, it saves conversation transcripts locally.\n\nWhere? Right here:\n\n```\n~/.claude/projects/\n```\n\nInside that folder, you’ll find JSONL files containing session history, potentially including prompts, responses, and tool outputs.\n\nAnd 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.\n\nThink 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.\n\n**We secured the model.** **But what about the agent?**\n\n### Don’t worry, Claude deletes old sessions!\n\nLuckily, Claude Code has automatic session cleanup. By default, sessions older than 30 days are removed when its cleanup process runs.\n\nGreat, right? Not exactly.\n\nFirst, 30 days is a long time for sensitive information to sit on a workstation.\n\nSecond, 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.\n\nSo our security strategy now depends on someone remembering to open their AI assistant. Not ideal.\n\nFortunately, there’s another option. We can disable local prompt history and session transcript persistence:\n\n```\nexport CLAUDE_CODE_SKIP_PROMPT_HISTORY=1\n```\n\nProblem solved? Not so fast.\n\n### The agent doesn’t need a diary to leave evidence\n\nClaude Code isn’t just a chatbot. It’s an agent. It reads files, runs commands, generates reports, and creates new files.\n\nImagine our doctor asking:\n\n“Analyze these medical records and create a summary.”\n\nClaude 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.\n\nWe stopped Claude from keeping a diary. But we didn’t stop it from leaving sticky notes everywhere.\n\nThat’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.\n\n### The next AI agent doesn’t care about your Bedrock configuration\n\nImagine 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.\n\nThat 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.\n\nOur first agent followed the rules. The second agent might not even know those rules exist.\n\nSuddenly, 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.\n\n### You can’t fix an OS problem with one Claude setting\n\nSo 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.”\n\nWe need continuous visibility and enforcement at the operating-system level. That means monitoring actual filesystem operations, process activity, and network connections.\n\nWhen 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.\n\nIf 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.\n\nAnd 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.\n\nClaude 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.\n\n### So, can the doctor finally use Claude?\n\nOur 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.\n\nThat’s when the real lesson became clear:\n\nSecuring an AI model isn’t the same as securing an AI agent.\n\nAnd securing one AI agent isn’t necessarily enough to secure the entire endpoint.\n\nThis is exactly the kind of problem we’re working on at Bluebear.\n\nBluebear 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.\n\nCombined with proper isolation, data-access controls, and retention policies, that gives organizations a stronger foundation for working with sensitive information.\n\nBecause 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.\n\nWant to see why agent security needs to go beyond individual tools?\n\nRead our research: [The tool blocked it, but the agent kept going.](https://bluebear.io/blog/the-tool-blocked-it-but-the-agent-kept-going/)\n\nOr [request a Bluebear demo](#contact) to explore runtime visibility and security controls for your AI agents.", "url": "https://wpnews.pro/news/we-secured-the-ai-then-we-checked-the-laptop", "canonical_source": "https://bluebear.io/blog/we-secured-the-ai-then-we-checked-the-laptop/", "published_at": "2026-10-13 00:00:00+00:00", "updated_at": "2026-11-10 11:23:20.231359+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-tools", "ai-policy"], "entities": ["Anthropic", "Claude Code", "Amazon Bedrock", "AWS", "Claude", "HIPAA", "GDPR"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/we-secured-the-ai-then-we-checked-the-laptop", "markdown": "https://wpnews.pro/news/we-secured-the-ai-then-we-checked-the-laptop.md", "text": "https://wpnews.pro/news/we-secured-the-ai-then-we-checked-the-laptop.txt", "jsonld": "https://wpnews.pro/news/we-secured-the-ai-then-we-checked-the-laptop.jsonld"}}