Permissions

The four permission layers

What data moves through Golden?

The production path is a tool connection, not a promise that every byte stays local. The AI client sends a tool request through Golden to the live customer runtime. The local runtime executes inside the current OS/service boundary, then returns the tool result through Golden to the AI client.

Local data stays local until a requested tool reads or returns it. If a command prints a secret, file contents or other sensitive output, that returned data can travel back to the AI conversation. Transport encryption is not the same thing as hiding tool results from the AI client.

For credentials, prefer references to existing SSH profiles, local credential stores, authenticated CLIs, environment variables or protected files. See Golden Secrets / Secure Input for the current and planned boundary.

Read, write and execute are different risks

Reading state is usually the best first step. Writing files, stopping processes, changing configuration or deploying code changes the environment and should have a clear task boundary.

Administrator access is not automatic

Golden should not silently elevate privileges just because a command would be easier as an administrator. If an operation requires administrator rights, that requirement should be visible and handled through an explicitly approved mechanism appropriate to the operating system and environment.

Prefer narrow access over a permanently privileged agent. A service account, scoped SSH profile or dedicated deployment command is usually easier to reason about than giving every AI operation unrestricted administrator access.

A model request such as “just use sudo” does not itself create permission. The host remains the authority.

What to do with “permission denied”

1. Identify the exact file, directory, process, socket or remote resource that denied access.
2. Check which user or service identity is executing the operation.
3. Inspect current ownership and permissions before changing them.
4. Decide whether access is genuinely required for the task.
5. Use the narrowest explicit fix and verify it.

Avoid recursive permission changes such as broad chmod or chown on a project, home directory or server tree unless the intended ownership model is already known.

Remote services and SSH

When the connected computer already has an SSH profile or authenticated CLI, Golden can use that existing access. The remote server still enforces its own account permissions.

If SSH authentication fails, Golden should report that failure. It should not substitute a different account, key or server unless that alternative is explicitly part of the approved task.

For credentials, see Golden Secrets / Secure Input.

Audit and logging boundary

The customer Account currently exposes bounded operational metadata: tool type, result state, timestamp and recent activity. Raw call rows are retained for 30 days while lifetime aggregate counters remain.

The commercial activity history does not store a persistent copy of command arguments, stdout/stderr or project file contents. Foreground Session Mode can show a sanitized command preview and success/failure locally in the open terminal; that terminal scrollback is local UI, not a new Golden Cloud command-history store.

Operating-system logs, SSH logs, Docker logs and application logs remain separate sources. Golden can inspect them only when the connected execution context is allowed to read them.

A full durable customer command-level audit trail is not implemented today. See Audit & Logging for the exact current behavior and limitations.

A safe permission workflow

• Start read-only when the environment is unfamiliar.
• Name the exact target, project and desired outcome.
• Keep destructive scope smaller than the whole machine.
• Treat permission failures as information, not an obstacle to bypass.
• Prefer existing audited credentials and service identities.
• After any write, verify the resulting file, service or public behavior.
• If an operation may have completed before a timeout, inspect before replaying it.

FAQ

Does Golden Terminal run as root?

Golden operations use the configured execution context. Do not assume administrator privileges. The host permissions remain authoritative.

Can the AI bypass a file permission error?

It should not. The AI can inspect the cause and propose an explicit permission change, but the boundary should remain visible.

Can Golden silently use another machine if one target fails?

No. Customer execution should fail closed rather than silently falling back to the Golden server or an unrelated target.

Why does a command work for me in Terminal but fail through the agent?

The processes may have different environment variables, working directories, PATH values, login shells or OS permissions. Compare those contexts before changing access.