Security

To use a capable AI, you are usually asked to hand over the work first and read the policy afterwards. Your files go somewhere you cannot see, an agent acts on your behalf without asking, and the only thing between your material and a mistake is a promise you have no way to check.

gOS gives you the keys instead. You are in control of your intellectual property, and you decide the terms of your data flows: what stays secret, what gets licensed, and what gets added to the commons.

Everything below is what makes that decision yours to make, and it is three boundaries drawn one inside the next. Your Garden is sandboxed by built-in system boundaries no agent can rewrite. You hold the keys, because Touch ID authorizes every Secure Enclave protected action. And inside both sits your intelligence: the data, the models and the workflows the fence is around.

Almost none of the ground is ours. gOS stands on the security Apple already built into the Mac, on the App Sandbox, FileVault, Touch ID and the Secure Enclave. It adds one rule of its own. Every consequential action has to be signed by hardware you are holding.

Your Garden is sandboxed by built-in system boundaries no agent can rewrite.

You hold the keys. Touch ID authorizes Secure Enclave protected actions.

Your Intelligence. Data, models and workflows are safe.

The ground all three stand on. Five pieces, four of them Apple's; the fifth is a P-256 key that exists only inside this Mac's Secure Enclave.

Your Garden is sandboxed by the system itself.

The fence around your Garden is not one gOS draws for itself. gOS is a fully sandboxed macOS app: its data lives in the container the system hands it rather than loose in your home folder, and the kernel enforces that on every launch. It is not a setting the app, or an agent running inside it, can talk itself out of. Access to mail, contacts, calendar, reminders, the microphone and the screen is granted one permission at a time in Settings → Authorizations, and revoked in the same place.

The container is what the app gets by default. Everything else is a door you open individually.

Sandboxed on every launch, not by policy.
App data lives in the app's own container.
Permissions are granted one at a time.

At rest, your work is FileVault's problem, not ours.

Apple Silicon encrypts the internal disk in hardware, and FileVault binds that encryption to your login, so a powered-off Mac is not a readable disk. gOS writes into that volume like any other app and ships no second encryption scheme of its own. That is deliberate. A private AI workspace is exactly the kind of product that would be tempting to give home-made cryptography, and home-made cryptography is how workspaces get lost. The one secret that would matter most was never written to the disk in the first place: the private key is generated inside the Secure Enclave and cannot be exported from it.

Three separate questions, and gOS only answers the first one itself.

No gOS-invented crypto to trust for files at rest.
The container sits on the FileVault volume.
The private key was never on the disk at all.

You hold the keys, and Touch ID is the gate.

Creating your identity vault prompts Touch ID, and so does every signature after it. The sheet you see is macOS's own, the one reading gOS is trying to authenticate to access your gOS vault, and gOS never sees your fingerprint or your password. It only learns whether the system said yes. The key is created with .biometryCurrentSet, which means it is bound to the fingerprints enrolled at the moment it was made: add a new finger to the Mac and the old key stops working. The key belongs to the hand that made it.

The same sheet appears when the vault is created and again on every signature.

The prompt is macOS's, not ours.
gOS learns yes or no, and nothing else.
Change the enrolled fingerprints and the key is gone.

The Secure Enclave holds two keys, and neither can leave.

gOS provisions two P-256 key pairs inside the Secure Enclave, which is separate hardware on the same chip with its own memory. One is your identity vault. The other signs approvals, and can be rotated deliberately without disturbing your identity. Both are created WhenUnlockedThisDeviceOnly and require your presence, so they are unusable on a locked Mac, unusable on a different Mac, and unextractable from this one. There is no software fallback in production: if the enclave will not sign, the action does not happen.

Identity and approval are separate keys so that rotating one does not change who you are.

Two keys, two jobs, one piece of hardware.
Unusable locked, unusable elsewhere, unextractable.
No software fallback in production.

One key, three names.

Everything downstream is derived from that single enclave public key rather than from a second secret you have to keep in step with the first. Signatures are ECDSA on NIST P-256, through Apple's own CryptoKit. Hash the uncompressed public key with Keccak-256, take the last twenty bytes and apply the EIP-55 checksum, and you have an Ethereum-format address, the same shape the rest of the world can already pay, name and attest to, which is how ENS names and on-chain reputation attach to a gOS machine at all. Compress the same key and encode it base58btc and you have a decentralised identifier, did:agtp:z… . The Wallet shows both and lets you copy either. There is no seed phrase anywhere in this, because there is nothing to write down. The key that signs cannot be copied off the machine, so the usual twelve words on a piece of paper, the thing that actually gets phished, never exists.

The address and the identifier are two views of the same hardware key, not two secrets to manage.

ECDSA on P-256, from Apple's own CryptoKit.
Keccak-256 and EIP-55 give an on-chain address.
No seed phrase, because there is nothing to write down.

Your Intelligence does not run until it is admitted.

A flow is not a run. It becomes one only when it is validated, fully bound, and carried by an envelope: a budget, a depth limit, the effects it may have, how much autonomy it gets, what it may persist, its risk class, its approval posture, and whether you have to be present. The envelope is where the terms of a data flow are fixed: what it may touch, what it may spend, what it may keep. They are fixed before anything moves. That check is a single gate, and no surface has a path around it.

A flow is not a run. It becomes one only after admission: validated, fully bound, and carried by an envelope you can read.

Every run carries an envelope.
One gate, no bypass.
Unbound work never starts.

Approvals are approve or reject, every time.

There are two answers, and for protected changes there is no third one that means stop asking. Each protected edit prompts again. What the enclave signs is a token that names one specific action: a hash of the action itself, a nonce so it cannot be replayed, an expiry so it goes stale on its own, and a field recording that the signature came from the enclave rather than from software. An approval is evidence about a single action, not a preference someone once set.

The signature covers the exact action, once, and cannot be moved onto another one.

Two answers, and no standing yes.
The token is bound to one action hash.
It carries a nonce and an expiry.

Every run leaves a trace.

Runs are recorded as they happen: what was asked, what was chosen, what was called, what it cost, what changed. Diagnostics shows the live half of the same picture: which models are resident, how deep the queue is, what failed recently. Inspecting a run is a normal thing to do here, not a developer mode.

The recorded half and the live half of the same picture.

Read what actually ran.
See which context was used.
Keep learning under supervision.

Security here is not a label on top of the product. It is the gate the product runs through, and the key that opens it is in your hand.