Security

Syntic Code is an agent that can read files, run shell commands, and reach the network on your behalf, which is exactly what makes it useful and also what makes security matter. The goal of a secure deployment is not to disable the agent’s capabilities but to bound them, so it moves quickly on routine work while it is structurally unable to do the things you never want it to do.

The permission model

The first line of defense is permissions. By default the agent asks before any action that changes files, runs commands, or reaches the network, and you can codify trusted operations in an allow list and forbidden ones in a deny list. A deny rule always beats an allow, and deny rules from every configuration layer are combined so no scope can weaken another’s prohibitions. Keep destructive commands in a committed, ideally server-managed, deny list so every developer and every automated job inherits the same guardrails:

{
  "permissions": {
    "deny": ["Bash(rm -rf:*)", "Bash(curl:*)", "Bash(:* | sh)"]
  }
}

Containment and isolation

Permissions decide what the agent may attempt; sandboxing decides how far a permitted action can reach. Running Syntic Code inside a sandbox or an ephemeral development container means its shell commands act within a confined workspace and cannot touch the host or the wider network beyond what you allow. This matters most for auto mode and automation, where no human is watching, so the container becomes the safety boundary and your permission rules become the policy inside it.

Enforcing policy centrally

Individual developers can configure their own machines, but security controls must not be optional. Distribute the critical rules through server-managed settings, which take precedence over user and project files and cannot be weakened locally. Combine tight permissions, sandboxing, an egress path through a gateway, and centrally enforced settings, and you get defense in depth: several independent controls that each have to fail before anything harmful can happen.