Local Execution: Keeping Code and Credentials on Your Machine

Originally published at getorquesta.com/blog/local-execution-keeping-code-and-credentials-on-your-machine

The problem with cloud sandboxes

Most AI coding platforms run agents in managed cloud environments. That means your source code, environment variables, and credentials are copied to a third-party server, processed, and then the results are shipped back. Even if the vendor promises isolation, the reality is that the code left your machine. That's a trust boundary I never wanted to cross.

When we built Orquesta, we made a deliberate decision: the agent runs locally. No cloud sandbox, no remote execution for code generation. The Claude CLI executes on your own machine. It's the same terminal you use every day, with the same SSH keys, .env files, and private repos already configured. We don't need to see your code to help you write it.

Local execution as an architecture, not a feature

Running the agent locally changes the security model fundamentally. Instead of uploading your codebase to a remote environment that could be compromised or subpoenaed, the code never moves. The agent reads files from disk, applies diffs, and commits — all through git on your machine. There is no network hop for source code.

This isn't just about privacy; it's about compliance. If you work in fintech, healthcare, or any regulated industry, sending proprietary code to a third-party sandbox can be a compliance nightmare. With local execution, your existing security controls — VPN, disk encryption, endpoint detection — apply to the entire agent workflow. You don't need to audit a new cloud perimeter because there isn't one.

Credentials stay encrypted, not just secret

Even with local execution, the agent needs to interact with services: GitHub, Jira, Slack, your LLM provider. Many tools store these API keys in plaintext config files or environment variables that get logged accidentally. We chose AES-256 encryption for all credentials stored in Orquesta.

The CLI encrypts secrets before they are written to disk. When the agent needs a token, it decrypts in memory, uses it, and never logs the plaintext. Even if someone exfiltrates your Orquesta config file, they get ciphertext without the key. The key itself is derived from your local machine's secure enclave or a passphrase you control — it never leaves your device.

Here's what that looks like in practice: when you run orquesta login, the CLI generates a local key pair and stores the private key in your OS keychain (macOS Keychain, Windows Credential Manager, or libsecret on Linux). The public key is sent to our server, and all secrets you add via orquesta secrets set are encrypted with that public key before they leave your machine. Our server can store the ciphertext but cannot decrypt it. Only your local agent can.

# Example: adding a GitHub token encrypted locally
orquesta secrets set GITHUB_TOKEN --value ghp_...
# The CLI encrypts with your local public key, then sends ciphertext to Orquesta cloud

Full audit trail: every prompt, every diff, every cost

Security isn't just about encryption; it's about accountability. When an AI agent modifies your codebase, you need to know exactly what changed, who approved it, and why. Orquesta logs every action the agent takes. That includes the original prompt, the full terminal output, every git diff, and the token cost for each LLM call.

These logs are stored with AES-256 encryption at rest and in transit. They are append-only — no one can modify history. For teams, this is invaluable. If a bug is introduced by an agent, you can trace it back to the exact prompt and the exact commit. You can see whether a human reviewed the diff before it was merged, or if the agent ran in Auto mode.

The audit trail also captures metadata: which agent executed the prompt, which execution mode was used, which branch was affected, and how long the run took. This isn't just nice-to-have; it's a requirement for SOC 2 and similar frameworks. We built it in from day one.

Quality gates: human sign-off before real execution

One of the biggest risks with autonomous agents is that they make changes you didn't expect. Orquesta's quality gates address this by simulating changes before they hit your real codebase. When a prompt is submitted, the agent can first generate a plan or a simulated diff. Then a designated team lead reviews it and either approves, rejects, or requests changes.

Only after approval does the agent execute the change for real. This happens in the same local environment, but the human decision is recorded in the audit trail. The result is a workflow that mirrors code review but for AI-generated changes. You get the speed of automation with the control of a traditional PR review.

For example, a junior developer might submit: "Refactor the authentication module to use async/await." The agent runs in Agent mode, produces a diff, and pauses. The team lead reviews the diff in the Orquesta UI, sees that the agent also changed an unrelated test file, and rejects with a comment. The next iteration includes only the intended changes. This loop is fast but safe.

Why we don't use cloud sandboxes, even for compute

Some platforms argue that cloud sandboxes are needed for scale, to run many agents in parallel. We solved that with the Agent Grid. You can monitor dozens of local agents from a single screen, with live terminal streams. Each agent runs on a machine you control — your workstation, a beefy dev server, or a CI runner. The grid aggregates their outputs, costs, and statuses.

This means you can scale to hundreds of agents without ever giving a third party your source code. The compute cost is on your hardware, which is often cheaper than cloud GPU instances for LLM inference. And because the agents run locally, they inherit your network policies: they can only reach the internal services you allow, not arbitrary internet endpoints.

For teams with strict data residency requirements, this is the only viable model. A cloud sandbox in us-east-1 cannot guarantee that data never leaves the region, but a local agent in your Frankfurt office can.

The security model, summarized

Here's what security by default means in Orquesta:

• Code never leaves your machine: agent runs locally, git operations stay local.
• Credentials encrypted with AES-256: secrets are encrypted before leaving your device; decryption keys never leave your OS keychain.
• Full audit trail: every prompt, terminal output, diff, and cost is logged append-only.
• Quality gates: AI-simulated changes require team lead approval before real execution.
• Local LLM management: Orquesta CLI supports Claude, OpenAI, Ollama, vLLM — you can run fully offline if needed.
• No remote execution ever: The platform orchestrates but does not touch your code.

This model isn't for everyone. If you want a zero-setup browser-based agent, you might accept the cloud sandbox tradeoff. But for engineers who care about where their code lives, local execution is the only sane default. We built Orquesta that way because it's what we wanted for ourselves.

What's next

The shift to local AI agents is part of a broader trend: bringing compute back to the edge where the data already lives. With models getting smaller and faster (thanks to quantization and specialized hardware), running an LLM locally is no longer a compromise. It's an advantage.

We're continuing to harden the local execution path: more granular permission controls for what the agent can read and write, signed commits for tamper-evident history, and deeper integration with enterprise identity providers. Security isn't a feature we bolt on; it's the foundation.

Takeaway: If your AI agent needs your source code to do its job, it should run where the source code lives — on your machine, under your control. Cloud sandboxes add a needless trust boundary. Keep the code local, encrypt the credentials, log everything, and make humans sign off before machines make changes. That's security by default.