It runs as you
An agent launched from your account holds your account. Every key, every repository, every mounted share, every browser profile. Nothing asked it to; macOS simply handed the whole desk over.
AI Capability Containment · macOS 15+Your agent works for you.
Your agent works for you.
It should not inherit everything you can reach. Nothing crosses without permission.
Claude Code, Copilot, Cursor, Codex, Gemini CLI, MCP clients, local models — every one of them runs with your entire account behind it. BitShout is an independent, deny-by-default boundary that sits between an AI-capable process and your files, your network, your credentials and your machine — and it is not part of the AI.
4authority domains
10security laws
0third-party dependencies
Localby default
Supported-apps list? Don't need one. BitShout recognises what it is containing by code signature, Team ID and bundle identity — never by vendor name. The AI tool you install next month is covered by the same rule as the one you opened today.
The problem
macOS has no idea your agent is an agent.
To the operating system, a coding agent is just a process you started. It gets your uid, your home directory, your keychain access, your network, your mounted volumes. The permission model was designed for software you read the source of — not for software that writes its own next step.
It spawns
Deny the app and it launches a shell. Deny the shell and it invokes Python. A boundary drawn around one process is a boundary around nothing at all.
It holds your secrets
Tokens in environment variables, keys on disk, credentials in config. Handing an agent a secret makes it permanent: you cannot take back what has already been read.
The boundary, visible
Every decision, on one screen.
BitShout does not run quietly and hope. It shows you what asked, what it asked for, what was decided, and whether the decision was enforced by the operating system or only evaluated by policy — because those are not the same claim.
Protected apps3All contained
Awaiting you2Approval requests
Denied today17Policy + OS
Evidence records842Local, hash-chained
Protected applications
CGChatGPTcom.openai.chatGuard Mode
CLClaudecom.anthropic.claudeGuard Mode
>_Codex CLIcom.openai.codexVault Mode
Recent activity live
Claude requested to read ~/.ssh/id_ed25519Denied2m ago
Codex CLI requested network access to 192.168.1.40:22Denied5m ago
ChatGPT requested to write ~/Documents/notes.txtAllowed once12m ago
Claude used MCP tool github.read_repositoryBrokered18m ago
Codex CLI spawned bash → curl → api.github.comDenied21m ago
Claude requested Keychain item aws-prodDenied24m ago
Law 3 · Containment follows execution
Launching a shell is not an escape hatch.
The containment session is attached to the process tree, not to a single PID. A descendant four hops down is governed by the policy its ancestor was given, whether it is a shell, an interpreter, a package manager or a binary that replaced itself mid-flight.
Two modes
Choose how much room to give it.
Guard Mode
The agent runs natively on your Mac at full speed, inside a policy boundary. Filesystem, network, execution, and capabilities are each deny-by-default and each answerable to you.
- Native performance, no virtual machine
- One workspace granted, everything else denied
- Policy follows every child process
- Approvals land on a surface the agent cannot touch
Vault Mode
The workload moves into a real virtual machine under Apple’s Virtualization.framework — a pinned Linux guest with no host sockets, no host processes, and one authenticated pipe back.
- Hardware-backed isolation, not a sanitised environment
- Guest-private tmpfs destroyed on stop
- Credentials stay host-side, always brokered
- Capability requests still cross the same broker
Capability broker & MCP
Give it the capability, not the credential.
An agent that holds your GitHub token can do everything your token can do, forever, and you will not find out until it has. BitShout registers MCP servers and tools by exact identity and brokers each call: it validates who is asking, which capability, which resource, which parameters, and which policy — and only then touches the secret.
What comes back is the result of one approved operation. The reusable credential stays broker-owned. There is no generic HTTP proxy, no raw token retrieval, and no “reveal secret” call to find.
here is the key→here is the answer
Fail-lock
When enforcement stops being provable, authority stops too.
Most software treats a broken security component as an inconvenience and keeps going. BitShout treats it as the thing it is. Protection configured is not protection active; a component that cannot be proven healthy does not get the benefit of the doubt.
- ProtectedAll boundaries proven healthy
- DegradedA boundary can no longer be proven
- LockedNew authority refused. Existing grants suspended.
- UnprotectedNever silently. Always stated.
- cannot determine → allow·cannot determine → deny
Audit & evidence
A record that says what actually happened.
Every decision lands in a local, append-only, hash-chained store: what asked, its lineage, the operation, the resource, the policy outcome, the grant that applied, and whether the operating system enforced it or BitShout merely evaluated it.
It stays on your Mac. Redaction runs before anything is written, export is an explicit action you take, and there is no mandatory telemetry to turn off.
policy denied≠OS denied
Security model
Ten laws that do not bend for convenience.
These are architectural invariants, not preferences. Every phase of BitShout is written against them, and a feature that would violate one does not ship in a weaker form — it does not ship.
Law 01
No ambient authority
A contained application does not inherit your authority just because you have it.
Law 02
Deny by default
Unknown or unapproved authority is denied. Nothing depends on an implicit allow.
Law 03
Containment follows execution
Process lineage is part of the boundary. Spawning is not escaping.
Law 08
Failure is not permission
BitShout never implements “cannot determine → allow”. It implements the opposite.
Law 09
Observed facts beat claims
Signing identity, lineage, resolved inode. Never the agent’s account of itself.
Law 10
Claims must be testable
No “unbreakable”. No “complete isolation”. Only what the threat model supports.
Law 10 · Claims must be testable
Where BitShout actually is.
A security product that overstates itself is worse than no security product, so here is the line, stated the same way it is stated internally.
Built and verified
- Deterministic, non-LLM policy engine across filesystem, network, execution and capabilities
- Process identity, code-signing identity and containment-session lineage
- Narrow grant model with revalidation, expiry and revocation
- Local stdio MCP brokering with broker-owned credential custody
- Protection health, Panic Lock and tamper-evident state validation
- Hash-chained local evidence with redaction, retention and export
- Vault Mode isolation proven live on Apple silicon under Virtualization.framework
Not claimed yet
- Production runtime filesystem and execution enforcement, which needs the Endpoint Security entitlement now in review with Apple
- Remote MCP transport and OAuth brokering
- Kernel-level fail-lock response
- Notarized production distribution, which follows that last approval
- Enterprise evidence collection and remote attestation
Apple has granted every entitlement BitShout needs except one: the Endpoint Security client entitlement is submitted and in review. Everything above passes its full suite on real hardware in our lab; what waits on that approval is production runtime verification, not the mechanism. The full trust page sets out exactly where the line is.
Contained by design.
BitShout is not an AI application, does not use a model to make security decisions, and does not send your work anywhere. It is a boundary. Nothing crosses it without permission.