I tried this a while back and found it ended up being easier to just give the firmware agent a dedicated machine, there’s so much low-level stuff you want access to for iterating on firmware, and the docker layers kept confusing the agents when they were debugging faults, crashes, brownouts etc.
Combining a dedicated small machine with a USB hub that supports per-port power cycling lets the agent iterate and un-wedge stuff with no human intervention for very long (days) periods. Obviously any software produced that way is unusable, but it’s incredible for debugging. Agent gets a programmable oscilloscope, power-cycling, and peripherals (also power-cycleable) emulating the various things our product talks to in the wild.
TL;DR I found the docker layers just caused confusion for the agent and giving her an old laptop was way simpler and much more powerful
I have to agree. Attaching both hardware and networks to Docker containers is still incredibly cumbersome unreliable and generally garbage. Can't do most things on the fly, if at all. Especially annoying in compose setups or when building a container. Even outside the context of AI agents.
Not ESP32, but development in general with (let's just say) "AI", I've gone to a dedicated machine. I'm not sure how many peers have told me, or articles I've read, saying to use containers/VMs/whatever, but taking an old-but-still-decent business class laptop, slapping Ubuntu on it, and running right in the native OS has so much less admin overhead.
I can just turn it off. I can unplug it from the network if I'm worried. I can easily isolate it network-wise using just a VLAN and normal firewalls. Hardware connectivity (ESP32 stuff I'm doing this weekend) -- as you describe -- is just easier.
I find this a rather interesting quirk of linguistics. In many languages, nouns have a "grammatical gender". For example, in Czech, "inteligence" has a feminine grammatical gender, so you are supposed to use feminine pronouns when refering to it. This sometimes leaks through with ESL people. I wonder if speakers of these languages anthropomorphize AI (or even animals or non-living objects!) more than native english speakers...
The money has gone to pay power plants that can supply winter capacity, exactly as the market is designed to do.
The intention of the payments is to increase revenue for that kind of power generation capability to encourage more such plants be constructed.
The argument in the article is dubious to me. Of course the higher price isn’t leading to more generation today, that’s not the point, the point is to reward developers that build and built capacity CA needs in winter. The disagreement then becomes which model is correct about how much capacity is actually needed.. but the fact that a tiny move in demand moves the price so substantially seems to me to undermine the entire premise of the blog post, clearly supply is severely constrained?
But that's why they're arguing that repricing the entire generation fleet is bad compared to having a different auction for new capacity. You don't need the same incentives to keep an existing, profitable plant online as you do to invest in a new plant.
I can assure you the spreadsheets at firms building plants factor in forecasts of revenue for the life of the plant into investment decisions. If they don’t pay past the first few years, that directly translates to lower forecast lifetime plant value for new plants.
I’m not a quant, and I’ve worked energy trading desks long enough to know there is a lot I don’t understand.. but I don’t see how separating auctions by plant age does anything other than move numbers around while keeping the total bill the same. Plants still need the same lifetime revenue to make investment decisions pencil out; whether you front-load payments or spread them evenly, the total in current value needs to be the same.
Even if the total cost is the same, if our payments better align with the behavior we want to incentivize, we may gain greater utility from the spending.
So it can matter how we distribute that revenue as to whether or not the business responds in the desired way, eg, actually investing in new capacity by linking payments directly to new capacity.
What's to say that encouragement works? Does the 12B subsidy stipulate that more plants must be built? If not, keeping supply limited and price per Watt high may be more profitable.
I'm assuming nothing -- the party that burns 12B of taxpayer money on subsidies should show that it works. It is plausible that there are no new potential market participants as building power plants is expensive and the entrenched players don't want to compete with themselves.
1. It does not seem to be “taxpayer money” nor “subsidies”? It’s customers paying money for electricity.
2. If no new or existing market participants are willing to expand capacity, that would indicate that existing prices aren’t worth it for them to do so. Companies are willing to spend far more than the cost of building a new power plant for things like AI - and they’re often even building power generation on top of the AI build outs. So it has to be more than “It’s expensive”.
What you're touching on is an ancient debate :) Should this part of society be top-down planned or should it be market organized?
I know how I feel about this - I much prefer price signals here; it allows any developer that can meet the spec to build energy production - distributed decision making over centralized decree - and it allows the other side of the equation, consumers, to decide they'd rather not pay for this generation: Curtail demand rather than increase supply.
Like - maybe I don't want to pay energy prices this high, I can choose to insulate my house better or get a heat pump and thus reduce my electrical bill. The price signal lets everyone in the market choose how to act, rather than a central authority declaring we must build, say, more gas turbines and share the cost of that across rate payers.
But, there are people much, much smarter than I that completely disagree with this position. In the end I think the answer is how you feel about human nature, the capability and shortfalls of markets and the complexity of deciding how societies' resources should be allocated.
Can you explain how that works? With the row-per-item I can see how you’d use locking primitives etc easily to deal with multiple concurrent shopping carts claiming available inventory.. but how does your solution solve contention? There’d need to be some “number of items in inventory” row, wouldn’t there be contention on that?
The point of one row per item is that thousands of concurrent shoppers don’t need to block each other as they can each claim as many free rows as they need for themselves?
One other advantage is item serial numbers. Or something else that makes an item that seems the same but actually be unique (perhaps the warehouse it’s in?)
Right, except the researchers are the ones that added the button, pressed it and now are upset at Ford, in your example.
GitHub agents don’t have access to unrelated private repos by default, nor respond to public issue comments by default. The researchers manually configured the agent to have access to unrelated private repos and also process untrusted public comments.
How is this a Github vulnerability? The researchers are the ones that grant the agent access to private repos and then ask it to answer questions in public repos.. of course this allows extracting private information?
This is like setting up a normal CI job with access to secrets and running it on public PRs. If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.
"How is this a Github vulnerability? The researchers are the ones that grant the agent access to private repos and then ask it to answer questions in public repos.. of course this allows extracting private information?"
I think the assumption is that the permissions are scoped to the repository you're currently asking questions on, rather than your private repositories as well.
Half the crowd using GitHub ever thought about plugins that have org wide access but /promise/ not to misuse it.
And years ago that included a lot of popular plugins (my POV was that those were outright stupid) -- on par with Docker in standard configuration: brain dead, works on my laptop idiocracy.
I stopped disabling plugins from "managers" that overreached from their repos only to org wide years ago.
While I liked a lot of people I worked with in that institution on a personal level, I was happy not having to work with them as devs, when that institution got closed.
Some nice people behave rather dumb when it comes to tech.
And than comes AI and tramples along, because there are no boundaries (See the article what they are writing about /assumed/ security boundaries. They assume things so much, it becomes physical pain to read or listen to them.)
I also find this frustrating. Every time I want to add an app to Github, it defaults to org wide. So far, I've managed to keep the reins on that, and nobody has made a mistake, but I am just waiting for the day someone adds something org-wide that shouldn't be.
Another rant(ish). You can request a PAT for, say, 30 days for a repo, and if you don't have access, it'll prompt an admin to approve that PAT. Okay, makes sense. But then you can refresh that same token without permission going forward.
Giving an app full scope to all repos in an org does not automatically imply that it would leak information from private repo A in comments on public repo B. That’s the issue being discussed here.
Like I said earlier, I can see both points of view, and I think the answer is more granular scoped permissions (eg on a per-workflow basis). Right now the permissions are crude.
GitHub doesn’t exactly make it easy to configure agent access securely. In fact, their regular access tokens and app credentials don’t provide granular enough controls to give direct access to private repos securely. Even if tokens are tightly scoped, access to public repos is always allowed and exfiltration via public repo issues for example remains a vector. Securing this requires patching via MITM proxy that implements stricter controls than GitHub provides.
Now, presumably GitHub Agentic workflows are the proper 1st party solution for this exact issue, but seems like they still have some work to do, either on the security model, or at least in making it easier to use securely.
Agreed. It seems a core issue underlying these prompt injection attacks is a failure to properly scope the agent's permissions. In this case, depending on what exactly the agent is supposed to actually do, this might be defining a separate workflow agent per repo, or a workflow agent with broader repo access but configured to only be triggered by users on an allow list (still compatible with developing in the open, still allows outsiders to open public issues, but takes into account the different trust to be placed in each). And likely many more options when one properly thinks about it.
But that requires:
1. the technical ability for such fine-grained scoping / permissions
2. actually taking the time to think about what you want to achieve with the agent and what the smallest set of permissions / capabilities is for it to achieve it
Regarding 1., I think this will come, we're still in the wild west phase of agent usage. It'll be interesting to see which abstraction(s) will turn out to be the best interface for humans designing agents (minimize friction for finding and defining scope and permissions) and to limit agent capabilities (again finding the best trade-off between level of detail possible for defining capabilities and the ease of use of actually doing it).
Regarding 2., well, that's still the core problem that's always prevented the construction of high quality software, isn't it? Taking the time to properly think it out,and then taking the time to properly implement it. Which goes counter to the "move fast and break things" approach of people throwing agents at everything.
The fallacy here is expecting an agent that has access to ALL your repos to respect the singular repo it’s in. It won’t. If it has access to all your repos and you ask it about a private repo you aren’t in - it will definitely go look at that private repo. This is like giving your dog a bone and then being surprised when he buries it in the backyard.
Exactly. This is a rehash of a HN post from a week or two ago that discovered that Claude code / etc running in the user’s context can and will access filesystem resources the user has access too.
That post had crazy suggestions for harness-level rules or shell scripts or something, when the obvious and correct answer is to run agents using existing OS-level security features that grant appropriate access (if you don’t want an agent accessing ~/ , run it as a user that doesn’t have access!)
In my agent sessions,which are scoped to one or more src/project folders, the model regularly tries to access src/ for no good reason. When asked what it’s looking for, it never has a good answer, and suddenly discovers that it can find what it needs in the folders it already has access to.
The dog analogy is quite apt - it just really wants to access src/, it doesn’t need a reason.
> If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.
Is there a way to segment access per agentic workflow, so that you can have both habe an agentic workflow that has access to sensitive data and one that has only access to public data? Is the default to set the scope to only the current repository? Does Github appropriately inform about the risk of combining an agentic workflow with access to private repository data?
If the answer to any of those questions is "no", then that's a problem.
(Classic GH Workflows are also riddled with priveledge escalation via PR-triggered workflows, but that's another topic.)
> Is there a way to segment access per agentic workflow, so that you can have both habe an agentic workflow that has access to sensitive data and one that has only access to public data? Is the default to set the scope to only the current repository?
If the author had used the native secrets.GITHUB_TOKEN then yes.
> Does Github appropriately inform about the risk of combining an agentic workflow with access to private repository data?
Not really, but also this highlights a broader issue: GitHub introduced fine-grained access tokens quite a while ago to prevent these situations. However, fine-grained access tokens don't work for a fair segment of the GitHub API for whatever reason. So often you have to use a personal access token to create a GitHub integration, and these have extremely broad permissions. Having said that, that is still the author's choice.
LLMs are just a dumb terminal related to permissions. What they apparently want is some synthentic permissions spun up based on their prompt which is... not a "prepared statement" solution and more of a "I will clean user SQL statements with my handy regex" and we know how that works out.
The real solution is a better UI for controlling permissions on a per prompt basis - just as we can select "search the web or not" the solution would be to have a "include my private repo" option that can be trivially toggled.
There are attacks that allow dumping RAM if the device is powered on though and you have physical access. Depending on config it may be very easy (just plug in a dumper over Thunderbolt on USB C and do direct memory access) or hard (freeze and swap physical RAM to an unlocked machine).. but the idea was defense-in-depth here; a well configured device should both be hard to dump RAM on and it should not give encryption keys if an attacker succeeds.
I’ve had very good success in similar setups where you have some sort of “oracle” and can generate enormous corpuses of test data, such that you really, really trust the LLM code must work for the inputs you expect it’ll ever need to handle.
Makes me think of all the algorithms we specify in proof languages and then hand-implement in production languages - this setup could maybe let you just specify the proof of an algorithm and then let LLMs derive efficient implementations with the (slow) proof as an oracle
I used to say this as well but like.. industry has, for a long time now equated “durable” with “stored on disk”. Any DBA will assume that’s what it means, and use that fact when they work out the replication they need either in clustering or in raid.
If you’re building a data storage system and are using the term “durable” to mean “it’s in RAM on three virtual machines”, for example, I don’t think it’s unfair to say that you are lying to your customers, because you are intentionally misusing a well-established term.
I forget the product, but more than a decade ago I remember someone broke out their durability into a table with columns for all the settings their data store offered between “ram on one node” and “fsync confirmed on a quorum of nodes’ disks” and rows for example failure cases ranging from “unexpected reboot of one machine” to “catastrophic loss of quorum-1 machines”. Cells were data loss risks from “prevented” to “possible” to “likely”.
That was very helpful when choosing durability levels.
I don’t have any respect for the viewpoint that “durable” is equatable with “stored on disk”, and I don’t want to spend time accommodating that viewpoint. It is just an oversimplification in a very bad way.
AFRs and discussions about different failure scenarios are the bare minimum. The bare minimum for scenarios is disk loss, total machine loss, and data center loss. This is just my take on things. I don’t care if something is on disk or not. I do care what happens when a sector on disk goes bad, when a faulty power supply destroys all the disks in a machine, or when a data center floods.
That forces you to think about things like whether you want to turn on synchronous replication.
The point of “durable” implying stored to durable media is precisely that it allows the operator of the system to make that kind of calculation. They know the disks they picked and the replication chosen, and as long as the database calls fsync, their calculations will work.
My beef is with database systems that use the argument you made further up thread to skip fsync to juice their performance numbers. Data is not “durable” if turning off the machines storing it means it’s lost, that’s a category difference, not a pure probability difference as you are claiming.
It is of course totally fine to not store data to durable media and say the risk of devops doing a coordinated reboot is as low as the risk of raid disk data loss, but then don’t use the word “durable”.
If a company says “encrypted at rest” that is generally compliance-speak for “not encrypted, but the hard drive partition is encrypted”.
Various certifications require this, I guess because they were written before hyper scalers and the assumed attack vector was that someone would literally steal a hard drive.
A running machine is not “at rest”, just like you can read files on your encrypted Mac HDD, the running program has decrypted access to the hard drive.
"encrypted at rest" is great to guard against stolen laptops, or in the server room both against people breaking in and stealing servers (unlikely at the security level of most hyperscalers, but possible) or more commonly broken HDDs being improperly disposed
How does that transalte to VMs? If "encryption at rest" is done at the guest level, instead of (or in addition to) host, that would be pretty close to minimal "encrypted except when it use" time and protect against virtual equivalents of pulling a hard drive out of a data center.
Combining a dedicated small machine with a USB hub that supports per-port power cycling lets the agent iterate and un-wedge stuff with no human intervention for very long (days) periods. Obviously any software produced that way is unusable, but it’s incredible for debugging. Agent gets a programmable oscilloscope, power-cycling, and peripherals (also power-cycleable) emulating the various things our product talks to in the wild.
TL;DR I found the docker layers just caused confusion for the agent and giving her an old laptop was way simpler and much more powerful
reply