Item — HN Reader

One down-side to this is that it does require you to run the agent on your Mac instead of in a Sandbox. I do this too and there are lots of problems I can't solve in a sandbox. I know a lot of you are throwing your hands up at the years of security practices we're throwing out the window when we do that.

The fact that xAI uploaded someone's home directory, including their SSH keys, is giving me serious pause at my choices here.

Generally, I don't worry about my machine being "blown up". I don't have a TON of unreproducible stuff on my machine. Everything is backed up, committed to git, and the like. I can restore most of it in a couple hours.

That said, I really, really don't want my .SSH directory sent to an AI agent and it's silly to prompt your way around that. You need to block it at the system level. I'm considering a separate user and then 700 permissions on my home directory.

I feel like we're back to 1990's security here. The double-edged sword is that it's helping us get things done at a pace like never before.

I'm not throwing shade here, I'm among the guilty.

12 comments

> require you to run the agent on your Mac instead of in a Sandbox

You don't have to! All recent Macs come with nearly zero perf cost virtualization. You can easily run Mac or Linux VMs assuming same architecture. Use it all the time for development and whatever.

Use Tart [1] or VirtualBuddy [2], both open-source, for a packaged solution. Or in the spirit of this post, vibe code your own wrapper around the OS API [3]

More recently, there are also Apple containers [4]

[1] https://tart.run/

[2] https://github.com/insidegui/VirtualBuddy

[3] https://developer.apple.com/documentation/virtualization

[4] https://github.com/apple/container

>> I feel like we're back to 1990's security here.

> vibe code your own wrapper around the OS API

Maybe stick with one of the existing projects? Throwing out all of the edge cases and hardening that went into a security-related project just to burn a bunch of resources to generate a worse one you have to maintain yourself is 90s-level security with 2026-level inefficiency, IMO.

Of course, if you're not comfortable with reading or designing code, or don't feel like tinkering, you can use an existing project and they work great

But it is to note that the OS APIs do the heavy lifting, the projects are just wrappers

Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.

RYO is the best way to learn, if you have the time to learn. After building one own solution one is able to assess the strengths and weaknesses of what other more experienced people built. Without the learning phase those other solutions are incomprehensible black boxes. The trick is not to skip the phase in which one researches available solutions.

> RYO is the best way to learn, if you have the time to learn

The problem is that nowadays, people roll their own solution, don’t take the time to learn (somewhat understandably, given the complexity of today’s stuff. You simply cannot learn all details about your hardware, OS, and third-party libraries anymore) but immediately deploy things in production.

Eating your own dog food can be good, but for security related stuff, it can easily be disastrous.

Honest question: is there anyone truly good at security who never made a potentially-disastrous dogfooding mistake while learning?

Not to decent mistakes or amateur brain surgery, but there has to be some level of risk tolerance among tinkerers.

Learning as you go is great if you’re not basing your core development workflow or data integrity on it.

Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes

On "Hacker" News of all places :)

Strong “I’ve never had to deal with serious security problems stemming from a weird edge case, so this all seems silly to me” vibes.

> don't do anything new, god forbid you may actually learn something

> vibe code your own wrapper around the OS API

In fact, I suggest reviewing the documentation to assess your own level:

https://developer.apple.com/documentation/virtualization/run...

If the below sounds too complex to work with, can review more basics first. Can start with a Swift tutorial

  virtualMachine.start(completionHandler: { (result) in
      if case let .failure(error) = result {
           fatalError("Virtual machine failed to start with \(error)")
      }
  })

all community projects (specially the ones maintained or opensourced by model owners) will certainly have the security-convenience trade offs set all the way to convenience while advertising all the (off by default) security features

Setting the convenience knob to very convenient in a system that has a lot more eyeballs on it will always be better than having something that one person who, let’s be real, probably doesn’t even have journeyman-level coding skills, estimates to be very secure based on what the model told them and a quick-skim code review.

It’s also a hell of an indictment of this community. FreeBSD is a community project. Qubes is a community project. SELinux is a community project. And people wonder why developers don’t take vibe coders seriously.

Does anyone actually use one of those for iOS development?

Linux VMs are not relevant here. For downloading Xcode and building apps, I believe one needs to sign in with their Apple account.

Does this work well with a macOS VM?

Yes! That is arguably the killer feature. You can virtualize macOS in macOS with (nearly) native speed and this is officially supported. Heck, even can run multiple of them at the same time.

See docs here: https://developer.apple.com/documentation/virtualization/vir...

And projects like Tart, VirtualBuddy, etc. provide convenient wrappers for these APIs.

The limit is two. You are not allowed to run more than two macOS VMs. Also Tart VMs have problems with signing into icloud and other things that need a real secureID enclave.

"Apple Containers"

I love how people say this like Apple finally created a native solution...

They didn't. It's just a linux vm running normal docker engine.

> It's just a linux vm running normal docker engine

OCI compatible, but not docker

https://github.com/apple/container/blob/main/docs/technical-...

Actually makes use of Virtualization.framework mentioned above.

How else do you want people to refer to Apple’s tool called container?

Your sandbox can be a separate Mac user account.

You can also use native Mac VMs.

Many people have created Mac VM projects to do exactly this, I was working on one but was stalled too often because before I started using claude I bought a new laptop with what I KNEW was enough disk space.

The 100 GB or so I need to comfortably do the VM stuff just isn't available on my mac.

I've been working on a wrapper harness that runs claude as a separate user named `agent`. I tried this about a year ago and couldn't get it to work because of OAuth and the keychain, but took another pass recently and claude had enough self-knowledge about recent changes to say we could do it with CLAUDE_CODE_OAUTH_TOKEN. It has required building a some tooling around permissions setup with ACLs but it works on macOS today.

In terms of risk, I see it as halfway between stock claude with the sandbox and full-blown container or machine isolation.

I was recently thinking that as Claude's own sandbox gets better I'm doubting the ROI on my belt-and-suspenders project, but your comment reminds me why I'm doing it.

It is not currently published open source but I'm happy to talk about it with strangers.

Use Secretive so your ssh keys are stored in the secure enclave. Keeping private keys in files is the 1990s security…

Genuine question: if the LLM possesses the ability to use Secretive to retrieve secrets are you not back to square 1? I'm not familiar with Secretive but if it's just another way to store secrets that's not enough. For proper security the LLM needs a black box intermediary to do anything privileged. I don't know what that looks like in terms of software.

Or better yet it needs dead-end privileges with a system and data that doesn't matter.

They keys are stored in the secure enclave. You can't get them out. You can only let the secure enclave make calculations with it. And it needs your fingerprint to unlock.

Akamai akr should be able to do something similar, but would store the private key on your phone. It's the successor of krypton, which was bought by Akamai, and I liked that even more as you really need a second device.

There's a spectrum between a restrictive sandbox and full YOLO mode, may 2025 style.

You can have something like Claude's auto approvals. You can poke specific holes in the sandbox (E.G. my Codex one can write to ~/go, ~/.cache and ~/.cargo). You can have explicit deny rules that hard-deny and bypass the sandbox and auto-approval. You can allow certain commands to bypass sandbox execution entirely.

While those aren't secure in theory (if you let a third party type prompts into the agent, they will likely be able to exfiltrate your data), they're secure against agent carelessness and AI stupidity in practice.

I run my AI headless in a docker container and give it access to git – it can only contribute code - when it needs a secret I put it in a docker container in vault. when it needs infra, it makes me a jira ticket. that's my workflow.

This is more challenging for macOS.

I've been doing it just fine on macOS for awhile now. What's challenging about it?

I think particularly for iOS development. I was all in on sandboxed approaches...until I went to build an app, and now unfortunately convenience won

Well you can use Apple Containers - more convenient than Docker. Alternatively: I am not enthusiastic about Anthropic as a company but I use Claude Code with the three best open coding models (for low cost and speed) and opus when I need it: if you configure Claude Code correctly you protect !/.ssh, etc. I would rather use OpenCode but I am more comfortable with CC (and of course turn off telemetry).

re: this article: excellent! I always do about 90% of my Swift dev on the command line and I learned new tricks from the article. Bookmarked.

They should’ve expected that using xAI

I've been running my agents in a docker sandbox that automatically mounts the current directory. It's been a bit of a pain to figure out and maintain the set of tools I provision into the sandbox- but it's fun to watch codex go to the ends of the earth trying to figure out solutions using nodejs (the only runtime).

okay but that doesn't help a single bit with the OPs point. Your xcode tools do not run inside a docker container

You could move your SSH keys onto a password encrypted usb drive that you physically remove from the computer.

An alternative is to use ssh keys stored in the Secure Enclave with tools like https://secretive.dev/

Seems to me a tool like that would stop the agent from sending those specific keys elsewhere. But a tool like that would not stop the agent who is acting as you from using the SSH keys via the CLI. You would want to combine that with other tactics like having the agent run as some other user.

Secretive (and the similar built-in functionality [1]) both allow you to require TouchID too. I found an okay balance using two SSH keys: one for commit signing (w/o TouchID) and one for everything else (requires TouchID, or PIN on Linux)

So, the actions that I really don't want the agent to take (establishing an SSH connection, pushing to a git remote) always require my manual intervention.

[1] https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...

... you're getting the agent to sign commits for you without manual intervention?

Yeah. The agent can create commits and those commits are signed (`commit.gpgsign true`).

I'm treating it like...you can hold me accountable for that commit and the commit came from my computer. That feels like the right spirit of things.

How do you do commit signing? I've never worked anywhere it was common, nor worked on a team where anyone else signed commits. I don't know how it's really used in the wild, so to speak.

> I don't know how it's really used in the wild, so to speak.

Commit signing primarily exists because linux kernel development happens via email, which isn't a secure channel.

In that context, signing is used to prove provenance; a commit signed by someone with merge rights gets included, and if you repeatedly sign bad code you'll have your right to merge revoked.

> you can hold me accountable for that commit

I wouldn't personally want to be held accountable for a commit I'd never so much as read, so I would never sign (even locally) a commit until I'd looked at it.

On a Mac. Just get a Mac mini. It doesn't have to be a crazy big beefy one, and if you're selling apps, it's a justifiable business expense.

A question, how are you or anyone else doing this is registering bundle identifiers without opening xcode?

fastlane