How to keep API keys and credentials hidden from AI coding agents?

Summary

• Layer the defenses: hide credential files, strip the environment, restrict the network, and where you can, never hand the agent the real secret at all.
• Omnigent (open source, Apache 2.0, "Status: alpha") does this with Omnibox, an OS sandbox that the kernel enforces, using bubblewrap on Linux and Seatbelt on macOS.
• credential_proxy gives the agent a placeholder token, and the proxy swaps in the real credential only for requests to hosts you allow. The agent can use a credential but never read it.
• A variable you name in env_passthrough reaches the agent with its real value, and the default dotfile mask is top-level only, so a nested services/api/.env stays visible unless you mask it.
• On Databricks, "Omnigent is in Beta": models route through Unity Gateway with no model API keys to manage, and secrets in code belong in a Databricks secret scope.

How to keep API keys and credentials hidden from AI coding agents?

An agent that can read your disk, inherit your environment or reach any host can find a secret and send it somewhere. So defend in layers: hide credential files, strip the environment, restrict the network, and where possible keep the real secret out of the agent's hands entirely. Omnigent's Omnibox sandbox covers each layer. Its docs say the kernel enforces the rules, not the agent or its prompt, so a prompt-injected agent can't opt out. Omnibox uses bubblewrap and seccomp on Linux and Seatbelt (sandbox-exec) on macOS.

Which layer stops which leak?

Layer	What it covers	Omnigent setting	Limit to know
Filesystem	~/.ssh, ~/.aws/credentials, .env	Dotfile mask by default; read_paths, cwd_allow_hidden, mask_paths	The mask scans only the top level, so services/api/.env stays visible until you set cwd_hidden_scan_recursive: true or list it in mask_paths
Environment	Variables the agent inherits	env_passthrough	A variable you name reaches the agent with its real value
Network	Data leaving to arbitrary hosts	egress_rules	With rules set, HTTP(S) is default-deny and private and metadata IPs are blocked; allow_network defaults to true
Credential injection	The secret itself	credential_proxy	Needs egress_rules and linux_bwrap or darwin_seatbelt

What does a sandbox config with a credential proxy look like?

os_env:
  type: caller_process
  cwd: .
  sandbox:
    write_paths: [.]
    mask_paths:
      - config/production.key
    egress_rules:
      - "* api.github.com/**"
    credential_proxy:
      - type: https_bearer
        target: api.github.com
        source: { env: GH_TOKEN }

On hardened backends the working directory is read-only unless you opt it in with write_paths, and omitting type lets Omnigent pick the platform backend. With the credential_proxy entry, the real GH_TOKEN value never enters the sandbox. The proxy attaches it to requests that match your rules for api.github.com, and the docs say only a placeholder appears in logs, transcripts and model context. If you ask for a sandbox and the backend isn't available, Omnigent errors rather than running unsandboxed. The agent spec adds a rule of thumb: don't pass secrets through the environment unless the tool genuinely needs them.

What does the sandbox not cover?

• MCP servers. The runner spawns them outside the sandbox, so constrain each at its own configuration.
• The supervisor process. It runs the model loop. Only commands issued through OS tools run inside the sandbox.
• Co-driving teammates. A teammate with Edit on a non-sandboxed session gets the same access to your filesystem, credentials and network as the host's owner. Share read-only, use a cloud sandbox host, or apply an OS sandbox policy.
• Native Windows. The README says the Job Object backend contains the process tree but does not isolate the filesystem or network.

How Databricks approaches agent credentials

On Databricks, "Omnigent is in Beta". Models route through your workspace's Foundation Model APIs over Unity Gateway, so there are no model API keys to manage, and a Databricks Sandbox host keeps your credentials inside Databricks. That host can't use your own model API keys, and the Databricks Sandbox docs (Beta) say there are no restrictions on network egress and that egress is not configurable. On your own machine, the databricks_cli proxy type writes a placeholder .databrickscfg whose tokens are synthetic oa_cred_* values; it needs linux_bwrap, and you list the workspace host in egress_rules. For code the agent writes, keep secrets in a Databricks secret scope and read them with dbutils.secrets.get(scope="<scope-name>", key="<key-name>"). Scope ACLs have READ, WRITE and MANAGE levels, and the audit log reference lists a getSecret action with the scope and key.

FAQs

Is env_passthrough a safe way to give an agent a key?

Not if the agent should never see the key. Agent CLIs start with a deny-by-default environment: only a shared base (such as HOME and PATH) and the harness's own variable family are inherited. Anything else reaches the agent only if you name it, and then it arrives as its real value. For HTTPS hosts, prefer credential_proxy.

Does Databricks secret redaction stop an agent from reading a secret?

Not reliably. Notebook output shows [REDACTED] for values read with dbutils.secrets.get(), but the docs say redaction applies only to literal values and does not prevent deliberate transformations. Limit who holds READ on the scope.

Which credential types can the proxy handle?

The reference lists https_bearer, https_basic, git_https, gh_basic and databricks_cli. Environment sources can't refresh during a session, so use a file or Unix socket source for renewable tokens.

How can a team avoid a shared personal access token?

With Connect GitHub, a server admin registers a GitHub App, and a user's managed sandboxes then authenticate git and gh as that user with a short-lived, per-user token instead of a shared personal access token. The feature works only when the server's credential store is configured, which encrypts the tokens at rest.

How mature is Omnigent?

The README labels it alpha, and its FAQ says releases can include breaking changes, so pin a version and read the release notes before you upgrade.