Security

gdc drives an agent that can read files, run commands, and edit code. That power is useful — and worth handling with care, especially when you run gdc as a shared or remote server. This page collects the practices that keep a deployment safe.

Permissions are your primary control

gdc's permission system is the front line:

• It fails closed — anything uncertain is denied, never allowed by default.
• Deny always wins over allow, so you can't accidentally permit something the baseline forbids.
• Reads are free; anything that changes the system is gated.

Harden it for a deployment by pre-denying sensitive commands and paths in configuration:

[permissions.bash]
deny = ["curl", "wget", "ssh", "scp"]

[permissions.path]
deny = ["~/.ssh/**", "~/.aws/**", "**/.env", "/etc/**"]

You can also cap the whole tool set with a restrictive profile — for example a read-only review profile with no command execution at all.

Protecting API keys

• gdc never prints your API key in help output or error messages, so it won't leak into logs or scrollback.
• Prefer the GDC_API_KEY environment variable over writing the key into a project config file that might be shared or committed.

Exposing a server safely

The server binds to loopback by default. Before binding it anywhere else:

• Add authentication. The API and connection layer don't authenticate on their own — put an authenticating reverse proxy in front.
• Encrypt the transport. Terminate TLS.
• Limit reach. Restrict the port with a firewall or a private network.
• Isolate the process. Run it as a dedicated, low-privilege user, or inside a container, so a mistake is contained.

Never expose an unauthenticated server publicly

A gdc server can run commands on its host. Binding it to a public address without authentication is equivalent to handing out a remote shell.

Trust for extensions

Extensions run code or reach external services, so treat trust deliberately:

• MCP servers and plugins are un-trusted by default — the agent must get approval before using them. Mark something trusted only when you're comfortable letting the agent use it freely.
• Hooks run your code on agent events; review any hook you didn't write.

The sandbox

Experimental

The sandbox is an evolving, defense-in-depth layer whose behavior may change.

gdc includes an additional protective layer that limits what the agent can reach, on top of the permission system. Its options live under [sandbox] in configuration. Treat it as an extra safety net, not a replacement for the permission and deployment practices above.

A durable audit trail

Every message and every action is saved as it happens. That record is also a security asset — you can review exactly what the agent did in any session:

gdc sessions show <id>

Pair it with an audit hook to log commands to a central place as they run.