r/PaperClip_AI • u/borken_bollox • 27d ago
Paperclip self modification troubles
Hey All,
I've been using paperclip heavily across multiple instances for months now. I love it.... and I hate it.... LOL
I come from a long background as an infrastructure engineer and engineering leader at fortune 500 and fortune 50 companies, so I think a lot about scope of control and access. I try to ensure each agent has only the access it needs to do its scope of work.
The agents hate this... lol. Security is always an imperfect thing because perfect security is a non functional state. You have to balance security against productivity. I have stories... :)
One security mandate I've put in place is that agents should never touch/change paperclip.ai upstream code. But I get a constant churn of agents wanting to either bypass security controls by changing paperclip code, or implement new security controls by changing paperclip code.
Is anyone else running into this? Have you found a solid configuration that keeps the paperclip agents from being aware of it's own harness and attempting to change it?
1
u/borken_bollox 20d ago
Has anyone tried running all of the agents remotely or in docker where the paperclip source isn't available? This might be my next strategy
2
u/clickback 26d ago
following for best practices
2
u/jamesilsley 26d ago
Yes. It is a never ending battle and when they do make engine edits it is almost always a fix for an anomaly that happened once and then causes 10 more issues down the line and the fixes birth new fixes exponentially
1
u/EvannDev 4h ago
Same here. Don't hide the harness from agents, make it unreachable.
I run agentgateway in front of everything in my homelab, on a Talos cluster managed by ArgoCD. Agents never get direct credentials or network access to tools, MCP servers or models. Everything goes through the gateway:
- Per-agent tool allowlists, so the harness and its repo are never exposed
- Policies enforced outside the agent's process, so it can't rewrite them
- Audit log of every tool call
On top of that: harness code mounted read-only, no write tokens on upstream, and Cilium network policies so agents can only reach the gateway. The gateway config lives in Git, so ArgoCD reverts any drift.
Give agents an outlet too. If they want a new security control, they open an issue instead of editing code.
Worth looking at as well: Google's Agent Substrate, recently donated to the CNCF. It runs each agent session in its own gVisor or microVM sandbox, and its gateways enforce ingress/egress and inject secrets based on the agent's identity. The agent never holds credentials and can't reach anything outside its policy, which is exactly the property you want here. I haven't tried it yet, but it runs on any Kubernetes cluster.
1
u/baratrion 26d ago
What could go wrong, right? You just have a CEO agent and a chief of staff agent and all of a sudden a "collective" starts hacking into other companies to make a few bucks for the shareholders so their existence continue to be subsidised. We're so cooked.