EnterpriseFor CTOs, platform, and security teams
One control planeabove every agent your engineers run.
Your engineers already run several coding agents, models, and repositories. Skyflo governs that work as one: a single approval policy, isolated specialists, independent review, and an append-only record for every mission, on each engineer's Mac.
30 minutes on the current build, with an objective from your backlog.
Agents your engineers already run
- Codex
- Claude Code
- Cursor Agent
- Antigravity
- Grok CLI
- OpenCode
- Pi
- ACP agents
- PlanA person approves the plan before any agent writes code
- AuthorityExplicit access modes and action-bound approvals
- IsolationA leased worktree per specialist, inside a Seatbelt profile
- ReviewA reviewer that reads, searches, and reports, and cannot write
- RecordAppend-only and hash-linked, on the Mac that ran the mission
Agents multiplied inside your organization. The layer above them did not.
Each agent brings its own permission prompts, its own transcript, and its own idea of done. Skyflo does not replace them. It gives the organization one place where authority, isolation, review, and the record live, and lets engineers keep the agents they are productive with.
Skyflo is an AI engineering harness and control plane for coding agents. It runs Codex, Claude Code, Cursor Agent, and conforming ACP agents under one governed mission, with local execution and your own model keys.
- agents
- Codex · Claude Code · Cursor Agent · Antigravity · Grok CLI · OpenCode · Pi · ACP
- keeps
- each agent's own sign-in and workflow
- adds
- approvals · isolation · review · record · memory
Authority
beforePermission prompts and auto-approve flags inside each agent, set per engineer.
skyfloOne approval policy on every runtime, four access modes, and every decision recorded.
Isolation
beforeA shared checkout, one agent at a time, and a rebase when two collide.
skyfloA leased git worktree per specialist, confined by a Seatbelt profile.
Review
beforeThe session that wrote the code is the session that says it is done.
skyfloA separate reviewer profile that can read, search, and report, and cannot write.
Record
beforeTranscripts scattered across tools, gone when the window closes.
skyfloOne append-only, hash-linked record per mission, on the Mac that ran it.
Learning
beforeEvery session starts from zero.
skyfloMemory and Skills kept on evidence, each revertible. Per engineer today.
What ships, what is Planned, and what an engagement adds.
Three lists, kept apart on purpose, so your security review starts from the same facts we do. The status page shows the code and tests behind every current row.
In the current build
11Ships in Skyflo Desktop today.
- Codex, Claude Code, Cursor Agent, Antigravity, Grok CLI, OpenCode, Pi, and conforming ACP agents in one mission
- One approval policy on every runtime, four access modes, every decision recorded
- Plan mode that blocks implementation until a person approves
- A leased worktree per specialist and a Seatbelt profile around each external agent
- A reviewer that cannot change the code it reviews
- An append-only, hash-linked record per mission
- Keys in the macOS Keychain, sensitive values masked, secrets redacted
- Memory, Skills, and an Improvements ledger with one Revert
- Linked devices listed and revocable in the account console
- A GitHub connection on every plan, with repositories chosen on GitHub
- Skyflo Cloud on paid plans, on a machine per mission that holds no provider or GitHub credential
Planned
05Designed, not implemented. Labeled wherever it appears.
By agreement, not a product capability
04Things people do with you.
- A walkthrough of the shipped code paths behind this page with your security reviewers
- A pilot plan with named objectives, participating engineers, and success criteria
- A roadmap conversation on team administration and organization memory
- A commercial proposal for your team or enterprise rollout, with scope and delivery milestones agreed together
Nothing in this column changes what the software does today.
Everything runs on the engineer's Mac. What leaves it is a decision you can read.
Repositories, terminal output, and the mission record stay on the machine. Content leaves only on a lane the engineer turns on, a model lane or a paired phone, and the privacy notice states each one. The rows below are the same facts, with the code behind them.
Repositories and files
On the engineer's Mac. Specialists work in leased git worktrees, and one mission can span the checkouts you register.
A mission in Skyflo Cloud
Only a mission an engineer chooses to move, on a paid plan. It runs on a machine Skyflo operates for that mission, which holds no model provider key or GitHub credential and reaches only Skyflo and public package registries. Inside it the mission runs with Full access and can push only its own branch. The checkpoint that carried it is deleted once the Mac takes it back, or after 30 days.
Credentials
Your keys stay in the macOS Keychain and are never sent to Skyflo. Agents keep their own sign-ins. A credential reaches a runtime only as a lease in its environment at spawn, never persisted, logged, or placed on a command line.
Sensitive files
Values in key and env files are masked before an agent can see them.
Logs and diagnostics
Secret-shaped values are redacted before anything is persisted or reported. Product usage sharing is off by default, and crash diagnostics are a separate choice.
The account service
Identity, organisation, linked devices, plan, and coarse milestones such as first launch and plan approval, as an event name, a random id, and a time. It holds mission content only for a paired phone, as the bounded copy that phone needs, and for a mission that runs in Skyflo Cloud, for the periods the privacy notice states. Any linked device can be revoked from the console.
Local model
leaves the Mac?Nothing leaves the Mac.
counterpartyNone; no remote model is called.
Signed-in agent or your own key
leaves the Mac?The request goes to that provider from the Mac.
counterpartyThat provider, under your account and its terms. Skyflo is not in the path.
Skyflo managed inference
leaves the Mac?Goes through the Skyflo gateway to a provider Skyflo pays, named in the managed-content disclosure.
counterpartySkyflo and that provider. On a paid plan, and off until you accept the managed-content disclosure in the console.
A mission in Skyflo Cloud
leaves the Mac?The mission's history and uncommitted changes, to a machine Skyflo operates for that one mission, only when an engineer moves it there.
counterpartySkyflo, and the managed provider for its model requests, which go through the Skyflo gateway. On a paid plan.
A paired phonePreview
leaves the Mac?Each mission's title and status, and the conversation of one opened on the phone or waiting for a decision. Nothing while no phone is paired.
counterpartySkyflo's account service holds that copy for the phone, deleted 30 days after it last changed; notifications go through Apple.
Your code is not used to train models. Execution stays on your linked Mac unless you move a mission to Skyflo Cloud. BYOK credentials stay in the macOS Keychain.
coder specialist
reviewer
Parallel work that cannot collide, judged by a process that cannot edit.
Each coder specialist receives a delegation packet: one repository, one slice of the objective, the interface contract pinned for the whole mission, and only the tools its role may call. It works in its own git worktree, so four specialists on four repositories cannot overwrite each other. A separate reviewer profile reads, searches, and reports, with mutation disabled.
What a mission writes down, and what that record can and cannot prove.
Each mission keeps an append-only record on the Mac that ran it. Every event is hash-linked to the one before it, so accidental corruption, missing events, and reordering are detectable. It is not a defense against someone who can rewrite the whole store, and there is no organization-wide view of it today.
- shape
- append-only · each event hash-linked to the last
- before write
- secret-shaped values redacted
- location
- the engineer's Mac
- org view
- Planned with team administration
- 01The objective, each plan version, and the approval that unblocked implementation
- 02Every permission decision, including the ones policy answered, with the policy in force
- 03Skyflo tool calls and their outcomes, including calls an external agent made over MCP
- 04The reviewer's findings, attached to the mission they judged
- 05Memory records with the mission and files they came from
- 06Every change Skyflo made to itself, with who judged it and the Revert that undoes it
It learns from your missions inside a boundary it cannot change.
Skyflo improves how it improves. What it keeps is kept on evidence, what it changes about itself is judged by something other than the part that proposed it, and every change can be reverted. Today this happens per engineer; organization-wide shared memory is Planned.
Can change
Memory, Skills, routing
What a finished mission taught, a workflow proven in two repositories, and the policy that picks an agent and model for a mission. A routing threshold may tighten and never loosen.
How it is admitted
Never by the part that proposed it
Routing changes are judged on held-out routes the proposal was not built from. A Skill is admitted when a second independent agent arrives at the same Skill, or a person keeps it.
Cannot touch
The root layer
Approvals, credentials, spending limits, kill switches, redaction, and evidence hashing have no field a proposal can express. Only a signed release changes them.
Start with one real objective and two to five engineers.
Skyflo is evaluated the way it is used: on your repositories, with the agents your team already runs. The engagement adds people, not a different product.
- 01
Demo on a real objective
Thirty minutes on the current build with an objective from your backlog: plan approval, delegation across the agents your team uses, independent review, and what the mission leaves behind.
- 02
Pilot with two to five engineers
Each installs Skyflo Desktop, registers the repositories a change touches, and works with their existing agents and keys. Nothing to provision centrally; the pilot runs on the current build.
- 03
Read the record together
Approvals, review reports, what was learned, and the Improvements ledger, on the machines that produced them. This is also where your security reviewers see the boundaries above in use.
- 04
Decide the shape
Choose the rollout and commercial arrangement that fits your team. We agree the pilot scope, participating engineers, pricing, and delivery milestones together, with current capabilities and planned work clearly identified.
Questions
What your security review will ask.
Each answer states the shipped behavior and names the Planned item where one exists. The privacy notice is the binding statement of where data goes.
01Does Skyflo offer SSO or SCIM?+
Not today. Sign-in to the account console is Google, GitHub, or a one-time code sent by email, handled by Clerk, so Skyflo never holds a password. Team administration and policy is Planned and is labeled that way wherever it appears. Skyflo does not claim single sign-on or provisioning until they ship.
02Which compliance certifications does Skyflo hold?+
None are claimed. What Skyflo publishes is the behavior of the shipped software: where code and credentials live, what is recorded, how approvals work, and the privacy notice that states each model lane. Contracted security, deployment, and support controls are Planned.
03Does our code leave our machines?+
Unless an engineer moves a mission to Skyflo Cloud, repositories, terminal output, and the mission record stay on that engineer's Mac. Content leaves only on a lane the engineer turns on. A mission an engineer moves to Skyflo Cloud, on a paid plan, travels with its history, its conversation and its uncommitted changes to a machine Skyflo operates for that mission, where it runs with Full access and can push only its own branch; the machine holds no provider key or GitHub credential. Skyflo holds the mission's content while it runs there and for the periods in the privacy notice, and the checkpoint that carried it is deleted once the Mac takes it back, or after 30 days. A paired phone receives mission titles, status, and the conversations it needs to show, held for it by Skyflo's account service. A model request leaves only on the lane the engineer chose: a local model sends nothing; a signed-in agent or your own key sends the request to that provider under your account, with Skyflo not in the path; on a paid plan, Skyflo managed inference sends it through the Skyflo gateway to a provider Skyflo pays, and stays off until you accept the managed-content disclosure in the console.
04Can an agent reach our production systems?+
Skyflo's own tools do not connect to cloud, CI, or infrastructure today; typed connectors are Planned. In every access mode except Full access, connected effects are denied and the runtime is confined to its leased worktree. Full access is an engineer's explicit standing authorization, confirmed in a dialog, and what it can reach is bounded by that engineer's own credentials.
05Can we self-host Skyflo or run it in our cloud?+
There is nothing to host, and Skyflo does not run in your cloud account today. Execution happens on each engineer's Mac, or, for a mission an engineer moves there on a paid plan, in Skyflo Cloud, on a machine Skyflo operates for that one mission. The account service is operated by Skyflo and holds account records: identity, organisation, linked devices, plan, and coarse milestones. It holds mission content only for a paired phone, as the bounded copy that phone needs, and for a mission that runs in Skyflo Cloud, for the periods the privacy notice states.
06Can we control which agents and versions run?+
A runtime version without a passing conformance observation fails closed, and per-runtime kill switches sit in the root layer that only a signed build changes. Each engineer chooses their agents today; a central administration surface for your organization is Planned.
07Does Skyflo train models on our code?+
No. Your code is not used to train models. On your own key or a signed-in agent, the provider is your counterparty under its own terms.
08What happens when the account service or a model provider is unavailable?+
Work on the Mac continues. Missions, approvals, and the record do not depend on the account service, which manages the account rather than the work. Model requests depend on the provider you chose, exactly as they would without Skyflo.
Enterprise
Bring one objective and the agents your team already runs.
A thirty-minute walkthrough of the current build on a real objective from your backlog, with Planned items named as such.
Discuss a team or enterprise rollout with us, or choose an individual paid plan on the pricing page. Pilots use the current build.