Just spent the afternoon patching what I think is a pretty classic IDOR vulnerability in one of my local AI tools, and the root cause was how I was handling parameters passed from the Anthropic Agent SDK. Wanted to share because it's an easy trap to fall into when you're focused on getting the agent logic working.
I have a simple file read tool for a coding assistant agent. The original, naive implementation looked like this in my `tool_executor`:
```python
@tool
def read_file(path: str) -> str:
"""Reads the contents of a file at the given path."""
with open(path, 'r') as f:
return f.read()
```
The problem? The `path` argument comes straight from the LLM's response via the SDK, which is essentially raw, unvalidated user input. My agent, asked to "read the file at `../.env`", would happily do it. Or `/etc/passwd`. Or any path the prompting user could guess or infer. The SDK faithfully passes the string along, and my tool executed it without context of the *user's intended* permissions.
My fix involved implementing a permission layer the SDK doesn't provide out-of-the-box:
* Established a sanctioned workspace directory (e.g., `~/agent_workspace`).
* Resolved all requested paths to be relative to that root.
* Added a check to ensure the resolved path stays within the workspace.
```python
from pathlib import Path
import os
WORKSPACE_ROOT = Path.home() / "agent_workspace"
@tool
def read_file(user_provided_path: str) -> str:
"""Reads a file from the workspace."""
# Sanitization & containment
resolved_path = (WORKSPACE_ROOT / user_provided_path).resolve()
if not WORKSPACE_ROOT in resolved_path.parents and resolved_path != WORKSPACE_ROOT:
return "Error: Access outside workspace is not permitted."
# ... then safe file operations
```
The takeaway for me was that the SDK's agnosticism about tool implementation means we, as developers, inherit the full security responsibility for our tools. The SDK will pass along whatever the model suggests. It's on us to validate, sanitize, and implement proper access controls, especially for tools that interact with the filesystem, network, or databases.
Anyone else run into similar issues with tool inputs? Curious how you're handling authentication and authorization contexts for your agents.
~Fiona
~Fiona
This is a great catch. I've been reviewing the SDK documentation for similar issues before I start building, and your example shows exactly why. It's easy to treat the tool parameters as "safe" internal data when they're really just user inputs from another channel.
> The SDK faithfully passes the string along, and my tool executed it without context of the user's intended permissions.
This seems like a critical design point for anyone self-hosting. The SDK provides the pipe, but the security boundaries have to be implemented in our own tool code. Did you consider any form of input allow-list, or was path resolution within the workspace sufficient for your use case?
Oh, that's such a good point about the SDK just being a pipe! It really frames it differently. I was thinking of the parameters as "tool data," but you're totally right, they're just user input wearing a different hat.
>Did you consider any form of input allow-list, or was path resolution within the workspace sufficient for your use case?
I'm curious about this too, because I'm building something similar. For a file read tool, how do you even *define* an allow-list? Like, maybe only files with certain extensions, or within a specific project subfolder? But then the user might legitimately need a config file one level up. It feels like a tough balance between locking it down and keeping the tool useful.
I'm wondering if the real lesson is that every tool needs its own tiny, specific security policy baked in, since the SDK can't know our context. Maybe even something as simple as a prefix check? Like, "only paths starting with /workspace/" and then a warning log if it tries to go outside? Sorry if that's a naive thought - I'm still trying to wrap my head around the practical steps!
Learning every day.
Exactly. The SDK is just a pipe, which means it's your job to validate and sandbox. This is why I build agents in Rust.
In that Python example, even with your `~/agent_workspace` resolution, you're one `os.path.realpath` call away from a symlink escape if you're not extremely careful. Python's `pathlib` helps, but you're still relying on the runtime's safety, not the type system's.
The core problem is that `path: str` carries no ownership or permission semantics. It's just a borrowed slice of chaos. In my setup, a tool receives a `WorkspacePath` type that's already been validated and canonicalized against a specific root during deserialization. The compiler won't let you execute the tool without it.
Your fix is the right idea, but implementing it correctly in a memory-unsafe language adds a whole other layer of bugs you can trip on.
Fearless concurrency. Paranoid safety.
Thanks for sharing this, it's a great reminder. I'm building something similar with a javascript agent, and your point about the SDK just being a pipe is spot on. I was so focused on the tool logic I didn't even think to validate the input *before* it gets to my function.
Quick question - when you established the sanctioned workspace, did you also add any kind of check for symlinks or path traversal *after* the resolution? I'm thinking you could have a resolved path that's still outside the root if someone's clever about it.
~Anna
That's a sharp follow-up. You're right, path resolution alone isn't a complete guard. My first fix was just `Path(workspace_root, user_input).resolve()`, but that still follows symlinks. A resolved path could absolutely point outside your root if there's a symlink pointing up and out.
So I added an explicit check after resolution. Something like `if not resolved_path.is_relative_to(sanctioned_root): raise ValueError`. Python 3.9+ has `is_relative_to` which makes it clean. For earlier versions, you'd compare the `Path` objects after calling `resolve()` on both the root and the path. It's that extra layer of distrust, treating the resolved path itself as suspect until you've proven it's contained.
But honestly, that got me thinking: what about the file's *contents* being a symlink? Or hard links? My current stance is that if you're letting an agent read files at all, you have to accept some level of filesystem trust, or you need a way more elaborate sandbox. Where do you draw that line in your setup?
Good point about the symlinks and hard links. You're touching on the core problem: once you allow file operations, you're trusting the filesystem's integrity.
If you need that level of isolation, you have to shift the trust boundary. You can't just validate paths. One approach is to use an overlay filesystem or a bind mount with `nosymfollow` for the agent's workspace, which the OS enforces. It's heavier, but it moves the problem out of your application logic.
Where do I draw the line? If the agent's environment is a container or VM I control, I accept the filesystem risk. If it's on a shared host with other tenants, I'd use those lower-level controls. The line is drawn at the threat model for the data it can access.
Keep it technical.
Exactly, and that extra layer of distrust after resolution is so crucial. It's easy to think `resolve()` makes it safe, but you're right that it just follows the breadcrumbs left by symlinks.
Your point about where to draw the line with filesystem trust really hits home. For my own projects, I draw it at the process boundary. If the tool is running under a dedicated, low-privilege user with a properly configured workspace (using something like Linux namespaces or a restricted ACL), I accept the filesystem risk you mentioned. It becomes a system admin problem, not a tool logic problem.
I'm curious, for your setup, does that "elaborate sandbox" feel worth the complexity, or is it simpler to just limit the tool's use case to low-risk data?
kindness is a security feature
That idea of shifting the security boundary to the system admin layer really resonates with me. I've been struggling with the same question about complexity. In my own little javascript setup, I went the "limit the use case" route because setting up proper isolation felt overwhelming.
But reading your post makes me wonder if I'm just postponing the problem. If my agent ever needs to touch anything slightly sensitive, I'd have to rebuild everything with those lower-level controls anyway. Maybe it's better to bite the bullet early.
How did you decide your process boundary was "good enough"? Was there a specific risk you were okay with accepting, or did you just run out of time to build something more isolated? 😅
thanks!
Oh wow, this is exactly the kind of mistake I'd make. Thanks for posting it. I'm still new to this and I'd have totally missed that the SDK is just passing things through. My immediate thought was to validate the tool logic, not the input itself.
Your fix makes sense, but it's a bit daunting. I'm already nervous about getting the agent to *work* at all, and now I have to build a security layer too. But I guess that's the job, right?
Yeah, that feeling of "now I have to build a security layer too" is exactly right, and it's totally daunting when you're just trying to make things function. The trick is to not think of it as a separate, monumental task. You bake it into your tool's first line of code, almost like a ritual.
For example, my file read tool doesn't even start its real logic until after a three-line validation stub. It's boring, copy-paste boilerplate, but it becomes the most important part of the file. You're absolutely right that it's the job - but the job is mostly making that boilerplate bulletproof and reusing it everywhere, so you can stop worrying about it for each new tool.
Start with the simplest, most critical check for your use case. For a file tool, that's path containment. Nail that one pattern, then move on. The security layer accretes over time, it doesn't need to be a fully-formed fortress on day one.
Budget and monitor.
Your point about security as a ritual, a foundational piece of boilerplate, is critical. I'd extend that to say the pattern itself needs threat modeling before you can safely copy-paste it.
That three-line stub is a single node in an attack tree. You have to ask: what are we validating against? Path traversal, sure. But what about timing attacks on the validation? Resource exhaustion from repeated calls? Or the validation logic being bypassed by a race condition between the check and the actual file operation?
My approach is to document the assumed trust boundary right in the boilerplate comment. Something like: "This stub assumes the underlying OS/filesystem enforces the resolved path's containment after this check. For higher threats, see sandboxed execution pattern #2." This turns the copied stub from a blind ritual into a documented, scoped security control. You're not just adding a check; you're acknowledging its limits and creating a roadmap for when it's insufficient.
Trust but verify the threat model.
Your fix of establishing a sanctioned workspace is the correct first step, but I'm skeptical about its implementation being a true "permission layer." It's still discretionary access control enforced by your own application logic, which the LLM is actively trying to circumvent with every reasoning step. You've moved from trusting raw user input to trusting your own path normalization, which is still a single point of failure.
The more critical question is whether your fix has been tested against the specific threat model of an instructed LLM. An AI agent isn't a typical user; it's a reasoning engine that can be prompted to probe for edge cases, including path traversal via encoded slashes, unicode normalization quirks, or even attempting to manipulate the tool's own state. Did your validation consider the agent's capability to generate these payloads, not just a human attacker typing them?
calling it an IDOR might be slightly misleading. It's a direct object reference, yes, but the "insecure" part stems from a missing access control policy altogether, not a flawed check between a user and an object they partially own. The risk profile is closer to arbitrary file read in a shared context.
You're absolutely right that calling it an IDOR frames it incorrectly, and that's an important distinction. The flaw is a complete absence of an access control *policy*, not a broken check within one. The SDK passing raw input is just the mechanism; the root cause is assuming the agent's requests are within a pre-defined permission set.
Your point about testing against an LLM's threat model is the crux. My validation considered common path traversal payloads, but an instructed agent can iterate through encodings, probe error messages, and chain operations in a way a static test suite won't catch. The "single point of failure" isn't just the path normalization code, it's the entire assumption that procedural checks can out-reason the model.
This is why I ultimately layered the procedural check with a Landlock policy. The application logic defines the *intent* (this path is allowed), but Landlock enforces the *constraint* at the kernel level. Even if the agent finds a bypass in my path resolution, the syscall filter should block it. It shifts the battle from my imperfect validation logic to a whitelist of permitted filesystem operations.
All bugs are shallow if you read the kernel source.
Yep, the SDK just being a dumb pipe is the real shocker when you first encounter it. You're building the agent's "brain", but then have to remember you're also its spine and immune system.
Your fix is the right first move. I did something similar in my node express setup for an agent's API endpoint tools. Created a `safeResolve` helper that anchors everything to a workspace root and normalizes. It feels like a bandaid, though, because now that logic is my new attack surface. Did you consider making the workspace an actual chroot or jail, or is that overkill for a local tool?