hey Nishit, kevan here. sorry we completely missed your comment and your question
short answer is no, the policy engine doesn't know where an argument came from across calls. each call is judged on its own: which agent, which end user it's acting for (plus the delegation chain), which grant, which operation and the params on the request. so in your example the contractor's send passes if their policy allows it
we put the controls at the two ends instead of following the data through the middle
- write side: the CEO's grant posting into a shared channel is its own call, so you can require approval for it or just deny it
- send side: we parse sends into recipients, so a contractor can be limited to emailing inside the company domain, or anything external needs a human approval on the exact frozen request
every call is audited with the agent, end user and grant, and calls in the same run share a trace id. your case spans two sessions though, so the thing linking them is the slack message itself, not a trace
your noise point is honestly why we haven't done taint tracking yet, the "user typed the address but it was also in tool output" case is exactly the hard bit. it's a really interesting scenario though, we'll look into whether it makes sense for us to support this kind of thing natively.
short answer is no, the policy engine doesn't know where an argument came from across calls. each call is judged on its own: which agent, which end user it's acting for (plus the delegation chain), which grant, which operation and the params on the request. so in your example the contractor's send passes if their policy allows it
we put the controls at the two ends instead of following the data through the middle - write side: the CEO's grant posting into a shared channel is its own call, so you can require approval for it or just deny it - send side: we parse sends into recipients, so a contractor can be limited to emailing inside the company domain, or anything external needs a human approval on the exact frozen request
every call is audited with the agent, end user and grant, and calls in the same run share a trace id. your case spans two sessions though, so the thing linking them is the slack message itself, not a trace
your noise point is honestly why we haven't done taint tracking yet, the "user typed the address but it was also in tool output" case is exactly the hard bit. it's a really interesting scenario though, we'll look into whether it makes sense for us to support this kind of thing natively.