There is no vendor in the middle.

Most AI tooling asks you to move your work to it. Orfyn is the other shape: the daemon runs on your hardware, holds your keys, and talks to your systems from inside your network.

Where Orfyn runs: the daemon on your infrastructure, clients connecting to it, and model calls leaving on your own credentials.

01 — Principles

Five properties of where the software runs

It runs on your infrastructure

A laptop, a homelab, a server in your own VPC, or a machine inside a segmented network. macOS, Windows, and Linux are all primary targets rather than ports. Clients — desktop, mobile, web, CLI — connect to that daemon locally or over a relay.

It uses your keys

Bring your own provider accounts: your Claude subscription, your OpenAI account, your own API keys, or a self-hosted endpoint. Orfyn does not proxy model calls, so inference goes from your infrastructure directly to the provider you selected, at that provider's pricing.

It inherits your boundaries

Agents reach exactly what the machine and the credentials they run under can reach. Nothing is escalated on your behalf, and there is no service account operating with privileges above the person who started the work.

It keeps blast radius small by construction

Work happens in isolated git worktrees with their own allocated service ports, not in your main checkout. Parallel agents cannot collide with each other, and changes arrive as a diff you review before anything merges.

It does not phone home about your code

No telemetry on your code. The speech-to-text and text-to-speech stack runs on-device by default; cloud voice providers are configurable if you want them, and off if you don't.

The relay carries end-to-end encrypted traffic between your daemon and your client, and cannot read it.

02 — Straight answers

The questions a security review asks

Does our source code leave our network?: No. The daemon runs on hardware you control and works against checkouts on that machine. What leaves is whatever your chosen model provider receives when you send it a prompt — and that connection is yours, not ours.
Do you see our prompts or model usage?: No. You configure provider credentials directly on your own daemon. Orfyn is not in the request path, which also means we cannot meter, cap, or mark up your inference.
What can an agent actually do?: Whatever the operating-system user and the credentials on that machine permit, inside the worktree it was given — and nothing beyond it. If a credential was never issued to that machine, no agent on it can use one.
Can we run it fully disconnected from the internet?: The platform itself runs locally, so it does not depend on our infrastructure being reachable. Whether a given workflow can run air-gapped depends on the model provider you point it at — a self-hosted endpoint can; a hosted API cannot. This is worth walking through against your specific setup.
Who can see a running session?: Whoever can reach the daemon and authenticate to it. Access is a property of your network and your credentials, both of which you control, rather than of a multi-tenant service we operate.

03 — Compliance

Built against SOC 2 and ISO 27001 control objectives

Most of what an enterprise security review tests for is satisfied structurally here rather than procedurally — which is why these answers are short.

Data residency and sovereignty: Determined by where you install the daemon. Not a contract term you negotiate with us.
Third-party data processing: None. We are not in the request path and never receive your code, prompts, or systems data.
Encryption in transit: End-to-end encrypted relay; the transport cannot read what it carries.
Access control and least privilege: Agents inherit the operating-system user and credentials they run under. Nothing is escalated.
Change management: Every change arrives as a reviewable diff into the approval process you already operate.
Audit trail: Your git history, your CI, your approvals — under your identities.
Segregation of environments: Isolated worktrees with their own allocated service ports.
Business continuity: The daemon runs on your infrastructure; our availability is not a dependency for your workloads.

Certification status, control evidence, architecture and data-flow documentation, and completed security-questionnaire responses are available on request under NDA. Ask for the security package in the meeting and we will route it to whoever has to review it.

We publish the architecture, not the evidence. The evidence goes to the people actually assessing it.

Bring your security team to the meeting.

The architecture questions are the ones worth spending the time on, and they are easier to answer against your actual environment than in the abstract.

Book a meeting