OpenHands vs Claude Code for security: how do permissions, secrets, and repo access get scoped and audited?

Most engineering leaders evaluating OpenHands vs Claude Code for security are asking the same thing: when an agent touches my repos, secrets, and production-adjacent systems, what’s the actual blast radius—and can I see, prove, and replay what happened?

Quick Answer: OpenHands scopes permissions, secrets, and repo access through a containerized sandbox runtime you control, with RBAC, SSO/SAML, and full auditability of every run, command, and diff. Claude Code is powerful inside an editor, but it largely inherits whatever access the developer already has and offers less opinionated, runtime-level controls for scoping and auditing agent behavior across teams and pipelines.

Why This Matters

The difference between “AI assistant” and “agent platform” is security mechanics, not marketing. If an agent can git push, access vaulted secrets, or call CI/CD APIs, you’re effectively giving it an operational identity inside your SDLC. Whether you use OpenHands or Claude Code, you need:

• Clear scope of repo and environment access
• Tight control over which secrets can be read and where they can be used
• A durable audit trail you can hand to your security team or a regulator

Without that, autonomy becomes a liability: you’re shipping changes you can’t trace and running tools you can’t replay.

Key Benefits:

• Smaller blast radius: OpenHands agents run in isolated Docker/Kubernetes sandboxes with scoped credentials, so a misconfigured agent can’t wander across repos or infrastructure.
• Stronger governance: RBAC, SSO/SAML, and auditable runs give security teams the levers they expect from any system that touches source code and production-adjacent services.
• Production-grade traceability: Every OpenHands run is reviewable and re-runnable, so you can inspect diffs, see exactly what executed, and reproduce decisions for incident or compliance reviews.

Core Concepts & Key Points

Concept	Definition	Why it's important
Scoped execution environment	A containerized sandbox (Docker/Kubernetes) where agents run with narrowly defined credentials and network access.	Limits blast radius: even if an agent misbehaves, it can only touch what its sandbox allows.
Secrets and repo access control	How tokens, SSH keys, and repo permissions are stored, injected, and constrained at runtime.	Prevents agents from overreaching—e.g., reading every repo in GitHub when they only need one.
Auditability and replay	The ability to see every command, API call, file change, and commit an agent made, and deterministically re-run the same workflow.	Turns autonomy into something your security team can trust: inspect, trace, and reproduce runs for forensics and compliance.

How It Works (Step-by-Step)

At a high level, here’s how security, permissions, and auditing differ between OpenHands and a tool like Claude Code.

1. Execution Environment & Identity

   • OpenHands:

     • Agents run in a containerized sandbox you control (isolated Docker or Kubernetes).
     • You decide what that container can see: specific repos, network egress, tools, and environment variables.
     • The “identity” of the agent is effectively the scoped credentials mounted into that container (Git tokens, CI tokens, etc.).
     • This runtime can be self-hosted in your VPC or run via OpenHands cloud, with fine-grained access control.

   • Claude Code:

     • Primarily runs inside your developer’s IDE/editor context.
     • Inherits the user’s local filesystem and Git permissions; if a developer can clone/push a repo or read a secret file, Claude Code can often operate on it.
     • The security boundary is mostly the developer’s workstation, not a purpose-built sandbox or container with its own scoped identity.

2. Repo Access & Permissions

   • OpenHands:

     • Repos are mounted into the sandbox on a per-task or per-agent basis.
     • You can restrict agents to specific repos, branches, or directories.
     • Integrations with GitHub/GitLab are configured centrally, often with scoped tokens (e.g., read-only for summarization tasks, read-write for automated PRs).
     • Repo access is audited: every diff, commit, and PR an agent generates is logged and tied back to a run.

   • Claude Code:

     • Works on whatever repo the developer has open.
     • Access is effectively co-extensive with the developer: if they can see it, the tool can read it for context.
     • There’s typically no central policy to say “this agent cannot operate on these repos” beyond normal Git permissions.

3. Secrets Handling

   • OpenHands:

     • Secrets (API keys, DB creds, CI tokens) are stored and injected into containers as scoped environment variables or mounted files.
     • You can define which agent, which workflow, and which environment can see each secret.
     • Because the runtime is containerized, you can enforce network egress rules so that secrets can only be used against allowed endpoints (e.g., CI APIs, Git hosts).
     • Secrets usage is indirectly auditable via the commands/API calls run inside the sandbox.

   • Claude Code:

     • Generally doesn’t manage secrets as a first-class, centrally-governed surface.
     • If the agent code or tooling inside your dev environment reads local config or environment variables, it can effectively use whatever secrets the developer has configured.
     • There’s usually no central “this token only for this agent in this project” policy; you’re relying on normal endpoint/token scoping.

4. Audit Logging & Governance

   • OpenHands:

     • Designed as an open, secure, and model-agnostic platform for cloud coding agents, not just a code assistant.
     • Every agent run produces an audit trail:
       • Commands executed in the sandbox
       • Files read/modified
       • Diffs and PRs generated
       • Tests run, tools invoked, and external APIs called
     • Integrates with SSO/SAML and RBAC for enterprise rollouts: who can trigger which agents, on which repos, with which permissions.
     • You can re-run tasks deterministically, which is key for security reviews: same agent, same runtime, reproducible behavior.

   • Claude Code:

     • Focuses on developer experience inside the editor; logging is typically limited to editor history or provider-side request logs.
     • There’s no unified, cross-team view of “what did our agents do to our repos this week?”
     • Governance is mostly mediated through user accounts and provider access controls, not runtime-level RBAC for agents themselves.

5. Operational Modes & Surfaces

   • OpenHands:

     • Terminal/CLI: Run agents interactively or headlessly in CI, cron, or internal orchestration systems; ideal when you want agent runs to be part of controlled pipelines.
     • Web GUI: Shared workspace for scoping tasks, monitoring runs, and reviewing diffs and logs—very useful for security and platform teams.
     • SDK/API: Programmatically orchestrate domain-specific agents and internal platforms, with your own policy layer on top.
     • Same agent, same sandbox runtime, across all surfaces—so your security posture is consistent.

   • Claude Code:

     • Primarily IDE/editor-based, optimized for local development and inline suggestions.
     • Great for single-user productivity; less oriented around fleet-level governance, CI/CD integration, or headless, auditable pipelines.

Common Mistakes to Avoid

• Treating repo access as an afterthought:

  • Don’t just give an agent your org-wide GitHub token and hope prompts keep it constrained.
  • Use scoped tokens per project/workflow in OpenHands and mount only the repos needed into each sandbox.

• Skipping auditability because “it’s just dev tooling”:

  • When agents start fixing tests, upgrading dependencies, or patching vulnerabilities, they’re not “just assistants” anymore—they’re part of your SDLC.
  • Make sure you can trace every automated change back to a specific agent run, with logs and diffs attached.

Real-World Example

A regulated fintech team wants to:

• Automatically upgrade dependencies weekly
• Remediate known vulnerabilities before merge
• Generate PRs with diffs and tests that security and platform teams can review

With OpenHands:

• They deploy OpenHands in their private Kubernetes cluster, in a locked-down namespace.
• GitHub access is configured with scoped tokens: read-only for analysis workflows, read-write for maintenance agents that open PRs.
• Secrets for dependency scanners, SCA tools, and CI tokens are injected via Kubernetes secrets into specific agent runtimes.
• Agents are triggered from CI pipelines on a schedule (nightly/weekly) and gated by RBAC—only the platform team can modify the workflows or credentials.
• Every PR opened contains:
  • The agent run ID
  • A link back to the full execution log and diff view in the OpenHands Web GUI
  • Generated tests and release notes that can be inspected before merge
• During an audit, they can show exactly which agents changed what, when, under which credentials, and re-run a given task with the same inputs to prove repeatable behavior.

With Claude Code alone:

• Individual developers can use it to help refactor, patch vulnerabilities, and write tests in their IDE.
• It speeds up local work, but the security team doesn’t have a centralized view into what was changed by “the agent” vs by humans.
• There’s no single audit trail for automated bulk upgrades or vulnerability remediations because changes are happening per-developer, per-IDE, not via a controlled, sandboxed agent runtime.

Pro Tip: If you’re piloting both, use Claude Code to accelerate individual developer workflows—but route any autonomous, repo-wide, or security-sensitive tasks (dependency upgrades, vulnerability remediation, policy enforcement) through OpenHands, where you get a containerized sandbox, scoped credentials, and auditable runs.

Summary

For security, the real comparison isn’t “which AI writes better code?” It’s “which system gives me an explicit runtime, scoped permissions, and a durable audit trail when agents touch my repos and secrets?”

Claude Code excels as an IDE-embedded assistant that inherits the developer’s existing access. OpenHands is built as an open, secure, model-agnostic platform for cloud coding agents, where:

• Every agent runs in a secure, sandboxed runtime you control
• Permissions and secrets are scoped per agent, per workflow, per environment
• Repo access, diffs, and PRs are fully auditable and reproducible, integrated into your CI/CD and governance stack

If your risk model assumes that anything touching source code, CI tokens, or production-adjacent systems must be observable, replayable, and controllable, OpenHands gives you the levers your security and platform teams expect.

Next Step

Get Started