I think that people are just not ready for the sort of novel privilege escalation we are going to see with over-provisioned agents. I suspect that we will need OS level access gates for this stuff, with the agents running in separate user spaces. Any recommended best practices people are establishing?
The hard part is stopping it leaking all the information that you've given it. An agent that can read and send emails can leak your emails, etc. One agent that can read emails can prompt inject a second agent that can send emails. Any agent that can make or trigger GET requests can leak anything it knows. An agent that can store and recall information can be prompt injected to insert a prompt injection into its own memory, to be recalled and triggered later.
Applying the Principle of Least privilege [1] you should not let this system download from arbitrary sites and maintain a blacklist. I don't think the field has advanced to the point of having one specific to this use case.
One of my first thoughts when I saw Computer Use was it needs some secondary agent controlling what the controlled computer is able to do or connect to. Like a firewall configuration agent or something.
It's probably because of the poorly-designed "flamewar detector" that censors posts if they are upvoted/downvoted too quickly. @dang explained it to me a few weeks ago[1] on another YC-related post that conveniently got scrubbed from the front page.
I'm fairly convinced that the arrest of Pavel Durov on content-moderation related issues is actually an attempt by a NATO state at securing information about adversaries, as it's the most used messaging app by Russian forces in Ukraine. Apparently the Wagner Group had developed their own messaging client, ostensibly for this reason.
> actually an attempt by a NATO state at securing information about adversaries
Or disrupt their communications and cause chaos in their command structure. If Russia had to actually build it's own app; the corruption in the Russia state would give as strong of a showing as it's broken tanks.
It wouldn't surprise me to learn it's the US trying to spy on Ukraine. We don't want to end the gravy train for the Military Industrial Complex with a surprise or cheaper victory, do we?
Exactly. If he's allowed to be free, but banned from leaving the country, FVEY SIGINT can throw their entire bag of tricks against his comms while working remotely. Maybe they can recover keys, infrastructure details, etc.
Dude is going to need to build his own SCIF, surrounded by proximity detectors and armed guards, offgrid power generation, fed by quantum-resistant encrypted fiber lines with splice detection alarms in a hurry.
Nothing but disdain for FVEY, but this is a solid approach on their part.
I have recently been playing Cyberpunk 2077 in which ammo vending machines are legion. Up until today, I had thought that this phenomenon was just a poignant critique of a fictional dystopian future.
> You can buy this single-use pistol from most vending machines for a price not much higher than a can of NiCola. At first glance, you can clearly see why. It's made from the cheapest plastic, liable to not only melt if left out in the sun, but also prone to jamming, breaking, and snapping inexperienced wrists with its high recoil. Still, a gun's primary purpose is to kill, and that's what it does. But when you've fired the last round, don't bother reloading. Just toss it in the trash and buy a new one.
We waited on this issue for 2 years before migrating off EKS Fargate to Managed Node Groups due to this very reason. In the end, it turned out to be much better of an environment anyway, because you didn't have to deal with Kubernetes oddities (like lack of Daemonsets) requiring anti-patterns and ultimately resulted in cheaper pricing due to better bin-packing. If you're doing K8s orchestration with Fargate, I highly recommend the switch.
(founder of WarpBuild - we offer hosted GHA runners)
This is a common issue.
A common pain point we see with users approaching some scale with self-hosting on k8s is that the k8s node autoscaling can become inefficient because of spiky loads.
We have a lot of users migrating off self-hosted setups using `actions-runner-controller` to ours because of this. Essentially, not having to deal with bin-packing is more efficient and concurrency, uptime guarantees are nice.
Sidecars are definitely a workaround but are hard to manage lifecycle for in conjunction with the primary container. This is now easier to do in 1.29+ with Sidecars officially supported via restartPolicy, but it was a colossal hassle prior to the advent of that. Also, we had noticed (maybe this has changed) that often logging frameworks were distro'd as DaemonSets (Helm, etc) and you'd have to shoe-horn the sidecar approach a bit.
It's nice to know that we have an ARM64 fallback if our perfectly robust and cheaper self-hosting of GHA (gha-runner-scale-set* components) were ever to go down, I suppose, but I can't help but feel like I am part of a huge market segment that GitHub lost during the ARM64 runner absence. Seems a little too late given they have natively supported action-runners images in ARM64 for some time.
As a former ASCII / ANSI artist, I wish this thing existed like 20 years ago and could make exportable animations for all my BBS needs. Can't wait to tinker!
less than quarter mil number, that's very very early on! mine is over 3.8 million, and I created it relatively early on considering I was living in Europe :)
I think I remember my number because back then when you had to reinstall software or put it on new machine you always went by your number, instead of your email or username. That's why I think I still remember it :)
