Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can I Run a Coding Agent on My Own Server?

Yes, a coding agent runs on whatever machine you give it, and Claude Code's documentation covers both a local session and a hosted one that keeps the GitHub credential outside the virtual machine. Your server inherits every credential you leave on it, so inventory the files, sessions and cloud identities the agent can reach before the first task.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Install a coding agent on a machine you control and it inherits that machine's position: the repositories mounted on it, the shell profile, the home directory, the browser profile and whatever identity the host holds in your cloud account. The installation is the simple part; the custody question arrives with it. Anthropic's Claude Code documentation puts both arrangements on one page, noting that a hosted session's virtual machine "holds a short-lived credential scoped to that session" while in a local session "the boundary is a permission prompt" (Anthropic, Security, 2026). Self-hosting keeps the isolation benefit and moves the custody work to the team that owns the box. This page sets out what a server hands an agent that a hosted session does not, what the vendors document, how far an approval prompt governs a machine you own, what to settle before the first run, and what a governed environment changes when the agent opens a rendered page. The worked example is a CodeCell on an on-prem server, working one repository and one internal service.

Key findings

  • Anthropic's Claude Code security page states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," custody a hosted session supplies and a server you own does not (Anthropic, Security, 2026).
  • Its permission documentation gives the rule that covers a file on disk: "To block Claude's file tools from reading a file or directory, add a Read deny rule for its path," and it adds that a .claudeignore file "has no effect" (Anthropic, Configure, 2026).
  • A study of prompt injection against agentic coding editors found that "attack success rates can reach as high as 84% for executing malicious commands," which is the risk a shell on your own server concentrates (Liu et al., 2026).
  • Browser Use's sensitive-data template states that "The LLM only sees placeholders (x_user, x_pass)" and that "Real values are injected directly into form fields after the LLM call," the substitution pattern applied to a page an agent drives (Browser Use, 2026).
  • Tokens replace the values a policy selects before any model reads the screen, and real values resolve only at the destination a named person approved, so a run works on placeholders it cannot spend (What Is Least Exposure?).
  • Every screen as tokens, every action and every approval lands in a record that exports to the team's own monitoring, so the evidence of a run does not stay on the machine (What Is a Tethered Agent?).

What changes when a coding agent runs on a server you own?

A hosted session and a server you own differ in three ways. The hosted session is a virtual machine created for one task and discarded after it; your server stays, and its home directory, shell history and installed packages carry over from last month. And the session's credentials are issued for that session, while the process on your server runs as a user account you made, with the privileges that account has collected.

The question then splits into two surfaces, and different controls govern each. What a governed browser environment covers is the rendered page: what an agent reads and does on a dashboard, a console, a settings page or a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A self-hosted coding agent spends most of its hours in the terminal and the working tree, which no browser control governs, and the pages it opens from that host are the part a page-level control can reach: the internal Git host's repository settings page, a cloud console, an admin dashboard.

Authority and capability are worth separating, which is the distinction What Is a Tethered Agent? draws: the tether is a description of authority, not of capability. A coding agent on your server holds the authority of the account you gave it and the capability of everything installed on the machine, and the distance between those two is where most of the findings on this page sit. One vendor's agent design takes the same split seriously, with surrogate tokens the model never sees and a separate component approving each network egress, as What Would an Enterprise Version of Meta Muse Need? describes it. The worked example is a CodeCell on an on-prem server: one repository, one internal service, one user account, and a browser the agent drives when a task leaves the shell.

What does the server hand the agent that a hosted session does not?

Start with an inventory of the ordinary things on a working server. The home directory holds an SSH key; the shell profile exports a token for a package registry; the working tree holds a .env that a test suite reads; the Git configuration points at a remote with a credential helper; a browser profile carries open sessions for the internal Git host. None of these were placed there for the agent, and all are reachable from the process it runs in.

A hosted session solves part of this by construction. Anthropic's security page states that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM," so the repository is reached through a proxy that holds the credential rather than cloned into a machine that also has your key. Whether a local session gets the same custody is not described in the pages reviewed. On a server you run, that layer is a decision you make, and by default it does not exist.

The largest single item is usually not a file. The Model Context Protocol's security guidance warns that "Cloud metadata endpoints often expose IAM credentials, API keys, and other secrets," and an instance profile attached to a server is exactly that endpoint: a request from the agent's process returns credentials for the role the machine holds, whatever the agent was asked to do (Model Context Protocol, 2026).

The working tree is the other half. GitGuardian's count for 2025, as How Do You Let an AI Agent Manage API Keys Without Reading Them? reports it, put 28,649,024 new credentials in public GitHub commits that year, with 24,008 in MCP configuration files alone.

What do the vendors themselves say?

Four vendor pages bear on the question, and each documents a mechanism narrower than a buyer might want to quote. Anthropic's page for Claude Code describes a setting to "Sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security," and states plainly that "no system is completely immune to all attacks" (Anthropic, Security, 2026). The sandbox covers shell commands, and the vendor's permission page supplies the file rules that apply where the sandbox does not.

That page adds that deny rules "don't apply to a command that reads files without naming them, such as grep -r pattern ." and points to the sandbox for enforcement "that blocks all processes from accessing a path" (Anthropic, Configure, 2026).

Browser Use's template takes the other approach and substitutes before the model reads. It instructs the developer to "Set use_vision=False to prevent screenshot leaks" and to "Use Browser(allowed_domains=[...]) to restrict navigation," controls on what the agent can capture and where it can go (Browser Use, 2026). The page describes a pattern to copy into an agent you write, not a control the vendor enforces on a machine you run.

1Password describes a browser integration in which "the AI agent and underlying LLM never need to see nor handle the credentials," injected "if, and only if, the human approves the access" (1Password, 2025). Microsoft's managed identity documentation states that "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs," one way to keep a credential off the machine, though its subject is Azure resources (Microsoft, 2026).

Dimension Anthropic, per its documentation What a buyer should verify
Shell commands A sandbox setting adds filesystem and network isolation for bash Which tool calls run inside it and which follow permission rules
File paths A Read deny rule blocks the file tools from a named path Whether a script or a directory walk reads the same path
Hosted sessions The GitHub credential stays on Anthropic's servers and out of the session VM Whether a local session gets the same custody
Approval The boundary is a permission prompt Who approves, and what the approved action can reach

How far does a permission prompt govern a machine you own?

An approval prompt decides one action at the moment it is proposed. On a machine you own, the prompt inherits the account boundary. Anthropic's security page is blunt about what that means: an approved Bash command "can still write anywhere your user account can" (Anthropic, Security, 2026). A person approves the command; the account decides the blast radius, and on a self-hosted box the account is usually the one an engineer uses for everything else.

The prompt governs only what passes through it. A build script, a test runner and a package postinstall hook execute with the same account and no prompt at all. Values the model has already read are outside its reach as well: once a settings page or a configuration file has rendered a credential into the context, no approval question changes what the model holds. Approval bounds the next action, not the accumulated reading.

Research on privilege control points at the account rather than at the prompt. The Progent paper reports that its approach "significantly reduces attack success rates while maintaining high utility," and the mechanism narrows what a hijacked run may call rather than what it may read (Shi et al., 2026). Applied to a server, the account the agent runs under should be able to do the task and little else.

Credential scope is the other lever, and the protocol guidance names the failure. "Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails," which is what a single broad token on a server produces (Model Context Protocol, 2026).

What should a team settle on the server before the first run?

Settle the account first: a dedicated user for agent work, no personal SSH key in its home directory, no shared browser profile, no membership in a group that can read every repository on the host. The account is the boundary the approval prompt will lean on.

Then settle the credentials: no long-lived token in a .env, no deploy key in the working copy, no cloud access key in the shell profile. Issue a token per run, scoped to the repositories and operations the task needs, let it expire, and keep the record of the run where the agent cannot edit it. Two shortcuts are worth naming: a root account key on the host, which AWS advises against creating at all (see Is It Safe to Let an AI Agent Set Up Your Cloud Environment?), and a super admin account for setup work, which Google's Workspace guidance says to use only when needed (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

The base rates explain why the inventory matters more than the policy document. SecretBench contains "97,479 secrets (of which 15,084 are true secrets)" (Basak et al., 2023). GitGuardian's test of Copilot found repositories where "over 1,200 leaked at least one secret," measuring "3.0 valid secrets for one prompt on average" (GitGuardian, 2025). A server that can reach any host can send a value it has read anywhere. Adoption runs the same way, with 62% of organizations experimenting and 23% scaling (How to Use AI Agents for Google Cloud Deployment).

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values a policy selects are replaced with consistent tokens for the whole run, so a page the agent opens shows ACCT_001 or TOKEN_014 where the value sits. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For a self-hosted coding agent the change is narrower than a reader might expect and more useful than it sounds. It does not touch the terminal, and it does not harden the account the agent runs under. It changes what the model receives from the pages the agent opens on that server, which is where a value the machine holds turns into text that a model can repeat, summarize or carry into the next task. A repository settings page that displays a signing secret is the clearest case: the page is rendered inside the environment, the field holds a token, and the real value travels only to the endpoint the person approved.

Three properties make that testable. The token is consistent, so a model that reads TOKEN_014 on one page recognizes it on the next. Resolution happens at the destination, so the value never enters the transcript. And the approval carries a name, so the record answers who allowed the change rather than which process made it.

Methodology and limitations

This page rests on three research preprints on credentials in source code, privilege control and prompt injection against coding editors; the Claude Code documentation from Anthropic, including its security and permissions pages; Browser Use's sensitive-data template; 1Password's write-up on credential injection; Microsoft's managed identity documentation; the Model Context Protocol's security guidance; one vendor research post from GitGuardian; and existing RedactSure research pages. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and figures from research posts are cited as reported, not as independently measured.

RedactSure did not test any of the named products hands-on. Where the page says a behavior is not described in the pages reviewed, it means the recorded documentation for that product did not state it, not that the product lacks the behavior. Vendor features change, and the page carries its date, so a release after that date should be treated as unreviewed until the check above is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a CodeCell on an on-prem server, and not an organization.

Determinations about whether a particular self-hosted arrangement meets a contractual, regulatory or insurance requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test on the organization's own server, run against a copy of the repository and one internal service, and repeated after each upgrade of the agent or the host.

What the record shows

The documentation answers more of the title question than the marketing around self-hosting suggests. A coding agent runs wherever you install it, the hosted version solves credential custody by keeping the credential off the machine, and the self-hosted version hands that problem to the team along with the machine's files, sessions and cloud identity. The vendor controls that remain are precise about what they cover: a sandbox for shell commands, a deny rule for a named path, a store that injects a value on approval. RedactSure's environment covers the rendered page, the surface where a value the server holds becomes text a model reads. Whoever owns the server can test this for one named agent and one task by listing the credentials on the machine it runs on and checking which of them the model could read on the last page it opened.

Frequently asked questions

Can I run a coding agent on my own server?

Yes, and the installation is the easy part. Claude Code documents a local session and a hosted one, and a self-hosted agent runs as a process under a user account you create. What differs is what the machine already holds: keys in the working tree, tokens in a shell profile, a browser profile with open sessions and any cloud identity the host carries. Decide what the account can reach before the first task, because the agent inherits all of it. The install is reversible; a leaked credential is not.

What should I remove from the server before the first run?

Start with anything durable the task does not need: personal SSH keys, long-lived access tokens in the tree or the shell profile, a shared browser profile with logged-in sessions, and a cloud role attached to the instance that the work does not require. Move what remains into a store that issues a scoped value per run. A clean account and a short list of permitted hosts do more than any prompt-level setting. Repeat the inventory after each upgrade.

Does a permission prompt stop a coding agent from reading a key on my server?

No. A prompt decides whether a proposed action runs, and the documentation says a command you approve can still write anywhere your account can. Reading is a separate question: a deny rule covers the file tools on a named path, and a command that reads files without naming them falls outside it. If the value sits in a file the account can open, the control that matters is which account the process runs under.

Is a sandbox enough on a machine I own?

A sandbox bounds what a command can reach, and the vendors describe it as one layer among several. It does not remove the credentials the account holds, and it does not change what the model reads from a page the agent opens outside the sandbox. On a server shared with a build runner or a test suite, the sandbox boundary is also the boundary of everything else the account can do. Treat it as a limit on execution, not as custody.

What does the agent see when it opens a page on my server?

Whatever the page renders for the account it is using. An internal repository settings page can show a signing secret, a console can show a key it just created, and an admin dashboard can list the accounts and the roles behind them. Each of those values enters the model's context and can appear in a summary, a commit message or a later request. Hiding the field from the model is a rendering decision, not a permissions decision.

Which credentials should live on the agent's machine at all?

Fewer than most setups carry. A repository-scoped token that expires with the task, a package registry token limited to reads, and a cloud role assumed for the run cover most coding work. A personal access token with organization-wide scope, a root account key or a password in an environment variable covers none of it and survives every cleanup. Where a value cannot be removed, put it behind a store that injects it on approval, and keep the store off the machine.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Keeps an On-Prem Server's Credentials Off the Screen

A server you own is a machine with history, and its sandbox, deny rules and hosted sessions do not decide what the model sees on pages it opens.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent reads the signing key already filled into the webhook form on the internal Git host's settings page. Inside the environment: the form renders as TOKEN_014, and the real value resolves into the submit endpoint on a named reviewer's approval.

RedactSure is deploying now with enterprise and government customers. Anthropic states on its own security page that "no system is completely immune to all attacks."

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

Keeping the agent on your own server keeps traffic inside your network, but the pages it reads still show credentials. Bring a task on your internal Git host and see, with test values, what the model reads in its settings. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.