无论任何的Agent，Claude Code、Codex等等，它的首轮提示词都会包含你的工作区路径信息。而一个固定用户每次打开时，其实工作区前缀都是一致的，如果你使用一个账号去拼车，每次打开项目时，文件系统前缀都不一致的话，傻子都知道你不是一个用户，你是很多很多个用户路由到同一个账号。而这个项目的工作路径是没法通过任何办法去rewrite的，它贯穿整个对话的全文，LLM生成任何bash命令，都需要基于你的工作路径去生成。
那么因此就可以推导出一个简单的风控方式，分析一个账号的所有首轮提示词，然后对它进行路径前缀树构造，一旦出现前缀不匹配，那它一定是一台新的设备。当出现的新的设备多了，那指定是有问题的。
特别是喜欢在用户目录下面开agent的，比如说桌面，桌面就是用户的子目录，/home/username/desktop/xxx,不同的用户在自己的桌面打开Agent上传的工作区路径全都是不同的Username，这是一个极其明显的多用户共享账号的指纹
（帖子已被作者删除）
最简单的也是最容易伪造的呀。。。。
用户名是Administrator
绝对没有任何一个中转站会去rewrite你的项目路径，我自己也用过不少，因为rewrite项目路径会有一个问题，很多情况下， LLM生成的命令是随机性的，有时会用绝对路径，有时会用项目相对路径，还有时会直接拼。如果去做rewrite的话，基本处理不了这个问题。而且我保证中转站是不会去rewrite的，所有的开源的中转程序都不处理这个
完全无法假定所有的用户都是Administrator，只要有一个不是，那就炸了
懂你意思，我刚刚看了codex的 jsonl文件，确实有这个东西，但是好像是在上下文里，比如openai真的会读你的上下文做风控吗？
不是很简单吗？在代理层直接做目录映射不就完了吗。
出现路径转义的时候，sol生成命令都能失败，因此完全不能指望一个固定程序可以正确处理这些。
给上游一个对应的假路径，上游回来的时候再换成真路径给本地的agent。如果用的人多，按照用户来做key value映射就行了。
是，我也感觉，一个转换插件就差不多了
关键在于，这个占风控的比例大不大？办法总是有的。
astra读OpenAI的User Policy之后的回答：
按所核对的个人服务条款，OpenAI 原则上可以利用已提交的项目路径及其脱敏特征，辅助识别账户共享并进行风控。
那就把所有的特征都伪装了。比如在claudecode里面使用gpt，在代理上直接把claudecode的提示词全部换成codex的，把所有的工具全部映射成codex的，多人目录也映射掉，除了IP地址，我觉得他们能做的也不是很多了。再往下如果直接分析你的对话，肯定还是能发现一些东西，但是成本就上去了。
没有任何的知名的反代程序内置了这个功能，比如说CPA和sub2api中发现有任何类似的功能，因此这个功它很危险，遇到嵌套或者转义会失败。第二个，由于rewrite了路径，一个不小心就会造成rm的范围偏移，甚至删库
没有想象的风险大，现在的AI模型很强了，目录漂移我觉得不存在的，只要根目录一直是准确的，问题都不大。CPA和sub2api我都懒得用，抄了作业自己改的面目全非了，上传给上游的指纹太多了。
现在反代新的客户端都不用了sub2api，还不如让ai重开加个适配器就完事。
我对此的评价是 https://linux.do/t/topic/2910176?u=enze
企业风控体系的建设是很复杂的工程，仅靠前端的小动作做对抗是没太大意义的
我以为楼主说的是反代，gpt显然最大问题是用的订阅，订阅是二等公民 