Security

Sudo is an AI assistant with write access to your workspace configuration, so it is worth being precise about what he can reach, what he cannot, and what is recorded.

Who can reach him

• The chat pane and its floating toggle only exist inside the admin interface, and only for system administrators.
• Every route behind him requires system-admin authorization, with the write-level check on anything that applies or discards a change.
• A session is a chat. A chat that does not belong to the administrator asking for it answers "not found" rather than "forbidden", so one administrator cannot enumerate another's sessions.
• Sessions are keyed by chat, so two administrators never share a working directory, an uncommitted edit or a staged commit.

The boundaries

Boundary	How it holds
Cannot apply a change	commit stages a diff and stops. Applying happens only from an administrator's approval, and the approval is bound to the commit id they were shown.
Cannot escape the sandbox	No host filesystem, no process spawning, no PATH. Every command is a managed implementation running in-process.
Cannot reach the network	The networking command names are withheld, so they are absent rather than refusing. Nothing in the sandbox can make an outbound request.
Cannot write outside /workspace and /tmp	Every other mount refuses writes, and only a /workspace write is a change to the workspace.
Cannot write your data	graph and query are read paths. There is no command that creates, edits or deletes a node.
Cannot read data the admin cannot	Reads run under the chatting administrator's own permissions, so access groups apply exactly as they do in the interface.
Cannot read internal node types	Node types marked as never returned to clients are dropped from graph, from query, and from every emitted section.
Cannot read a secret value	Secrets are declared by name in config/secrets/. The value is never in the file, never in the export, and has no read path from the sandbox.
Cannot manage identity	Creating a user, changing a role, resetting a password or changing group membership are not reachable. He can read access groups and reference one from a definition.
Cannot install packages, back up, restore, restart, or touch licensing	None of these has a command.
Cannot run unbounded	Wall clock, command count, output size, loop iterations, recursion depth and parser fuel are all capped, and a cap that is reached raises.

What Sudo can see

Configuration, runtime state, and the data an administrator could already read:

• every file under /workspace, which is the configuration export;
• generated documentation and the code-reference extract;
• live runtime state under /proc: exceptions, metrics, the configuration audit trail, connectors, indexes, embeddings, scheduled tasks, migrations, access groups and the tail of the server log;
• graph reads through graph and query, under the chatting administrator's permissions;
• files uploaded to the private Stage area, as their extracted text.

The server log and the exception list can contain application data in a message. Both are already readable by a system administrator in the admin pages, so this is not new exposure, but it is worth knowing when deciding who gets the administrator role.

What is recorded

• Every applied change is one commit in the configuration git history, attributed to the administrator who approved it and readable at /proc/audit and under Manage / Access / Audit log.
• Every code surface additionally keeps its own code history, so a change made through Sudo can be reviewed and rolled back exactly like one made by hand.
• Every shell call is metered into the workspace's metrics under an Admin Agent bucket, separately from ordinary chat tools, and each session tracks its own call count, error count and duration.
• The command history of a session is stored on the session, so what he ran is reviewable in the terminal window, and the chat transcript keeps the tool call for every command.

Sudo's chats are exempt from chat policies: the policies exist to constrain what end users may say and be told, and an administrator configuring their own workspace is not that conversation.

Practical guidance

• Read the diff, not the summary. The approval card is the security control. A change described in prose and a change in a file are not the same artifact, and only one of them is applied.
• Leave Allow changes off for exploration. It costs nothing: he still reads everything and drafts in his own copy, and you can flip it on when there is something worth applying.
• Watch for widened access. An endpoint's access mode, an AI tool's reachability and a node type's visibility are the lines worth reading closely in any diff, because they change who can reach what.
• Use secrets, not literals. If a change needs a credential, the correct outcome is a secret declaration plus code that reads it. A key pasted into a file would be exported, committed to the configuration repository, and visible to anyone who can read it.
• Prefer a migration to a bulk edit. Sudo cannot write your data, and that is deliberate. Data changes should go through a reviewed migration task that you approve and then run, so the change is recorded and repeatable.
• Keep house rules in a skill. A convention stated in one conversation applies to one conversation. The same convention in a skill applies to every future session, and is itself reviewable.

Read next

• Reviewing and approving — the control that stops everything else.
• The sandbox — why the boundaries are structural.
• Access control model — who gets to be an administrator.