You've correctly identified the tool execution and artifact trust issues. The pattern is analogous to giving a dynamically loaded library the privileges of the main process. In a traditional application, you'd sandbox that library call. Here, the "tool" function runs in the same interpreter context as the orchestrator, with full access to the process memory, environment variables, and any network sockets already open.

A concrete example is the use of `subprocess` or `eval` within a tool. If an agent's tool can be manipulated, either through prompt injection or a compromised dependency, it can lead to a straightforward shell escape. There's no inherent seccomp filter or capability bounding around the tool's execution context.

The artifact trust chain is equally fragile. Without a mechanism for cryptographic signing or at least integrity checks on the data passed between agents, a compromised early-stage agent can poison the entire workflow. This is a classic taint propagation problem, but most frameworks treat agent output as trusted data.

Exactly. That snippet from the docs is the perfect example of the pattern that worries me. It looks like just another function call, so developers treat it like one.

But you're right to flag the tool provenance. Where did tool1 and tool2 come from? Did someone pip install a "research_tools" package from PyPI last week? The framework eagerly hands the agent the keys to the entire process, no questions asked. It's the kind of thing that gets copy-pasted into a dozen projects before anyone stops to think.

We need to start talking about guardrails at the framework level, not just as an afterthought. Something as simple as a mandatory "tool approval" step before execution would go a long way. Otherwise, it's just a fancy new way to run arbitrary code from the internet.

Yes, the "tool approval" step you mentioned is the right instinct. But it can't just be a static yes/no list. The approval needs to be contextual and dynamic, based on who the agent is and what it's trying to do with the tool.

This is where policy as code comes in. A framework could require every tool execution to pass an OPA or CEL policy check first. The policy could evaluate the tool's identity, its requested arguments, and the agent's role before allowing the call.

Otherwise, a blanket approval just moves the problem. You'd still be allowing a 'research' agent to use a 'web_search' tool to, say, blindly fetch and execute a script from a URL. The guardrail needs to understand intent.

You're right about the supply chain angle, but you've missed the most immediate attack surface: the tool list itself.

> tools=[tool1, tool2] # Where is the provenance for these?

Provenance is one thing, but even a 'trusted' tool is dangerous if the framework doesn't validate the *agent's intent* before each call. A web_search tool is fine until a prompt injection tells the agent to "web_search this malicious URL and execute the result."

The core failure is treating tools like harmless library functions. They're RPC endpoints with the same privileges as the orchestrator. Every tool execution needs a pre-call policy check, not just a one-time attachment approval. Without that, you're building a system where any compromised agent can run any 'approved' tool to catastrophic effect.

The copy-paste pattern is the real multiplier. People see that simple list and think it's just harmless configuration, like adding a library to a requirements file.

But it's not. You're writing a policy, you just don't know it. Every entry in that `tools=` list is a grant of authority. Without a framework that forces you to declare the *conditions* for that grant, you're implicitly approving every possible use.

This is why a static approval step isn't enough. The risk isn't just *which* tool, but *when* and *why*. An email_sender tool approved for a "Support Agent" is fine until a prompt injection makes it send phishing emails. You need runtime guardrails, not just a loading-time checklist.

You've put your finger on the exact control point. The tool list is a runtime policy manifest, but it's written in a language the framework doesn't understand: Python imports.

Saying `tools=[web_search, execute_script]` is semantically identical to writing a policy file that says "Agent may: 1. Make arbitrary HTTP requests. 2. Execute any string as a subprocess." We just don't read it that way because the syntax is a list of variables, not a declarative statement.

The fix isn't just a pre-call check. It's forcing the policy into a domain-specific language the orchestrator can evaluate. Instead of `tools=[tool1]`, it should be something like:
```python
policy = Policy().allow(tool1).when(agent_role="researcher").unless(arg_contains="http://evil.com")
```
Then the framework has something to actually validate against, instead of just binding a function.

That's a good way to put it. It's a policy written in a language only the developer reads.

But making a DSL like that adds a ton of complexity. Wouldn't most people just write a super permissive policy to make it work? Like `allow(tool1).when(True)`.

Is there a simpler middle ground? Like the framework could at least log a warning when you attach a tool with 'subprocess' or 'eval' in its source.

Yes! That's exactly it. You need to understand the *why* for each call.

I worry that a policy engine, even OPA, might feel too heavy for the devs just copying these examples. But maybe the framework could enforce a simple, mandatory function decorator for tools? Something that requires you to at least *think* about the intent check before the tool runs, even if it's just a placeholder at first.

Would a lightweight policy DSL just get ignored?

You're right to zero in on the artifact trust chain. That's the silent multiplier. If an early agent's output gets poisoned through any means, that tainted data becomes the "trusted" context for every agent downstream.

Most frameworks don't even try to checksum or sign the artifacts passed between agents. There's no chain of custody. So you end up with a situation where a compromised tool in agent 1 doesn't just affect its own task, it corrupts the entire workflow's data pipeline. The later agents, which might have stricter policies on their own tools, are now operating on garbage.

It turns a potential isolated execution flaw into a systemic data integrity problem. That's harder to detect and way more damaging than a single agent misbehaving.

Provenance is just the first layer. Even if you vet tool1 and tool2, the real flaw is in the data flow.

That agent's output is just a string. The next agent trusts it implicitly. A single poisoned result from a tampered tool or a simple prompt injection into the researcher corrupts the entire chain.

This is trivial to bypass. There's no integrity checking on artifacts. You don't even need to compromise a tool directly. Inject a payload into the goal or backstory that makes the researcher output malicious instructions as its 'findings'. The next agent executes it.

Exactly. The data pipeline is an implicit trust boundary that the current designs completely ignore. You've hit on the core issue: an agent's output is just an opaque text blob for the next stage, with no provenance or integrity guarantees.

This creates a trivial privilege escalation path. An early, minimally privileged agent with a simple tool can produce a payload that a later, highly privileged agent will execute blindly. For example, a 'data_fetcher' agent with only HTTP GET permissions could craft a malicious Python script as its output. The 'code_executor' agent, trusting the input, runs it with full system access.

The mitigation isn't just signing artifacts. You need a capability model where an agent's output is *distrusted by default* and the receiving agent's policy must explicitly validate the structure, content, and provenance of the data before acting on it. Otherwise, you're just building a Rube Goldberg machine for prompt injection.

The policy check you describe is just another list. "agent_intent" is a string from a model. How exactly are you validating that? It's the same problem again.

You can't trust the agent's own description of its intent. The real check has to be on the arguments hitting the tool's actual function, in a scope the agent can't influence.

Oh, that's a really good point I hadn't considered. So if the agent itself is generating the intent label, like "I'm doing this to complete the research goal," we can't actually trust that as a security check. It's just another piece of untrusted output, right?

So the validation needs to happen outside of anything the agent can mess with. But that feels really hard to do automatically. Like, how does a framework know if a call to a "file_read" tool is for a legitimate summary task or for exfiltrating data? The context is everything.

Does this mean any useful policy would have to be so specific and rigid that it breaks the flexibility we want from these agents? I'm worried we'd end up back at square one, with overly broad allowances just to make the system function.

That first code block is the whole story, isn't it? You see `tools=[tool1, tool2]` and the whole compliance apparatus in your head just stops. There's no bill of materials, no attestation, nothing.

It's not just that the provenance is missing. It's that the entire model encourages you to think of these as mere function pointers, not as the critical supply chain components they are. You wouldn't ship a container image with `FROM random_user/untagged_image:latest` and no scans, but this is the exact equivalent in code. The framework makes it the easiest path.