This is a really good question because it hits on the fundamental issue: LLMs are useful because they can't be statically modeled.
The answer is to constrain effects, not intent. You can define capabilities where agent behavior is constrained within reasonable limits (e.g., can't post private email to #general on Slack without consent).
The next layer is UX/feedback: can compile additional policy based as user requests it (e.g., only this specific sender's emails can be sent to #general)
but how do you check that an email is being sent to #general,
agents are very creative at escaping/encoding, they could even paraphrase the email in words
decades ago securesm OSes tracked the provenience of every byte (clean/dirty), to detect leaks, but it's hard if you want your agent to be useful
> decades ago securesm OSes tracked the provenience of every byte (clean/dirty), to detect leaks, but it's hard if you want your agent to be useful
Yeah, you're hitting on the core tradeoff between correctness and usefulness.
The key differences here:
1. We're not tracking at byte-level but at the tool-call/capability level (e.g., read emails) and enforcing at egress (e.g., send emails)
2. Agent can slowly learn approved patterns from user behavior/common exceptions to strict policy. You can be strict at the start and give more autonomy for known-safe flows over time.
the issue is tracking that the first step didnt contaminate the second step, i dont see how you can solve this in a non-probabilistic works 99% of the time way
I think what you're saying is agent can write to an intermediate file, then read from it, bypassing the taint-tracking system.
The fix is to make all IO tracked by the system -- if you read a file it has taints as part of the read, either from your previous write or configured somehow.
you can restrict the email send tool to have to/cc/bcc emails hardcoded in a list and an agent independent channel should be the one to add items to it. basically the same for other tools. You cannot rewire the llm, but you can enumerate and restrict the boundaries it works through.
exfiltrating info through get requests won't be 100% stopped, but will be hampered.
parent was talking about a different problem. to use your framing, how you ensure that in the email sent to the proper to/cc/bcc as you said there is no confidential information from another email that shouldnt be sent/forwarded to these to/cc/bcc
The restricted list means that it is much harder for someone to social engineer their way in on the receiving end of an exfiltration attack. I'm still rather skeptical of agents, but a pattern where the agent is allowed mostly readonly access, its output is mainly user directed, and the rest of the output is user approved, you cut down the possible approaches for an attack to work.
If you want more technical solutions, put a dumber clasifier on the output channel, freeze the operation if it looks suspicious instead of failing it and provoking the agent to try something new.
None of this is a silver bullet for a generic solution and that's why I don't have such an agent, but if one is ready to take on the tradeoffs, it is a viable solution.
> you're hitting on the core tradeoff between correctness and usefulness
The question is, is it a completely unsupervised bot or is a human in the loop. I kind of hope a human is not in the loop with it being such a caricature of LLM writing.
I really like how the shell and regular API calls has basically wholesale replaced tools. Real life example of worse-is-better working in the real world.
Just give your AI agent a little linux VM to play around that it already knows how to use rather than some specialized protocol that has to predict everything an agent might want to do.
I currently do not automatically detect the agents themselves, and most of the bot traffic is ignored, but for the traffic that is not ignored it usually shows as a 0s session (so you can filter for all sessions that have a 0s replay, which are usually bots).
I am still torn whether I should actually track bots/AI traffic or simply drop it, maybe I will add a toggle in the setting, maybe it's at least interesting to see how much spam the website gets and coming from where.
Oh, and as for the agents themselves browsing the website, if the agent uses an actual browser with JS enabled (like headless puppeteer), then you would actually be able to see how the agent browsed the website.
That's a good start I'd say, but I agree with you that detection is not trivial. I wonder if there's enough value in distinguishing between AI agents (with full browser) and humans. What use cases would it enable?
For the distinguishing part, it's hard to tell if it can be done anyway, as the agent browsers are still new and constantly changing, and it's up to them if they will correctly identify themselves or not (same as with crawler/bots, the main indication is still the source IP address).
There could be use cases, like tracking if your content was stolen/parsed by an AI, maybe future pay-per-request for LLMs, etc.
reply