> ## Documentation Index
> Fetch the complete documentation index at: https://docs.symbioticsec.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Security modes

> Configure security modes for Symbiotic Code

Symbiotic Code can automatically check the code it writes for security issues. Security Modes let you control how thorough that checking is, so you can balance speed and safety depending on what you're working on.

There are three modes: **Permissive**, **Balanced** (default), and **Strict**.

Each mode changes the security workflow the agent is instructed to follow and whether Symbiotic Code enforces security tooling when files are modified. Security instructions are only added for agents that can edit files (for example, not for the read-only `ask` agent).

## How to switch modes

| Method        | How                                                                                                    |
| ------------- | ------------------------------------------------------------------------------------------------------ |
| Keybind (TUI) | The configurable `security_mode_cycle` keybind (default: `Ctrl+S`) cycles through the three modes      |
| TUI command   | Run `/security-mode` to choose a mode                                                                  |
| CLI flag      | `symbiotic run --security-mode permissive\|balanced\|strict` for non-interactive runs                  |
| Agent config  | Set `security_mode` on an [agent](/code/customize/custom_agents) definition to give it a fixed default |

The current mode is shown below the prompt in the TUI and is remembered across restarts. You can change it at any point mid-conversation; it applies from the next message onward.

When you switch to an agent that has `security_mode` set, the TUI uses that agent's mode. Switching back to an agent without one restores the mode you last selected.

```json symbiotic.json theme={null}
{
  "agent": {
    "payments": {
      "security_mode": "strict"
    }
  }
}
```

If an invalid or missing value is ever encountered, the system falls back to **`balanced`**.

***

## Permissive — fast iteration, security opt-in

**Best for:** prototyping, throwaway scripts, demos, or early exploration where you just want to move fast.

* The agent still writes reasonably secure code by default (input validation, no hardcoded secrets, etc.), but it won't stop to run security checks or scans on its own.
* Security reviews only happen if you explicitly ask for one (e.g., "can you check this for vulnerabilities?").
* Nothing will interrupt your flow to run extra checks.

> **Keep in mind:** Since checks aren't automatic, issues could slip through unless you ask for a review before shipping.

***

## Balanced — recommended default

**Best for:** everyday development. This is the mode you'll use most of the time.

* The agent thinks about security while planning your feature, not just after the fact.
* After meaningful code changes, it automatically runs a security review — but skips it for things like documentation updates or purely cosmetic changes, so you're not slowed down unnecessarily.
* If something serious is found (critical/high severity) in code it just wrote, it fixes it right away.
* For less urgent findings, or issues in code it didn't just write, it will ask you what you'd like to do before making changes.

> **Trade-off:** Good balance of safety and speed for typical feature work; trivial changes aren't slowed down by scanning.

***

## Strict — maximum protection, every change checked

**Best for:** sensitive projects — authentication, payments, personal data, infrastructure, or anything under compliance requirements.

* Security design tasks are planned upfront, before any code is written.
* Every file change, no matter how small, triggers a full security review.
* Low-confidence scanner findings are sent to the `triage` subagent to filter out false positives.
* Critical, high, and medium severity issues are fixed immediately and re-checked to confirm resolution.
* Low-severity issues are flagged and you're asked whether you want them addressed.
* Switching to Strict mode mid-session also applies the stricter workflow to security findings from earlier turns in the current session.

> **Keep in mind:** This is the most thorough option — expect more security-related steps and occasional questions as you work.

***

## Enforcement

In Balanced and Strict modes, Symbiotic Code doesn't rely only on the agent following instructions:

* **Forced security turn:** if the agent tries to finish after modifying files (other than documentation, images, and similar non-code files) without running both `securityscan` and `securitycheck`, it's given one extra turn with a reminder to run them.
* **Automatic scan fallback:** if the agent still finishes without running `securityscan`, Symbiotic Code scans the modified files itself and shows an error if critical or high severity issues are found. This requires you to be logged in to Symbiotic.

Neither happens in Permissive mode.

***

## Quick comparison

| Behavior                                        | Permissive                 | Balanced (default)                                  | Strict                                     |
| ----------------------------------------------- | -------------------------- | --------------------------------------------------- | ------------------------------------------ |
| Security-design planning tasks                  | Not added                  | Added before implementation tasks                   | Mandatory, before all implementation tasks |
| `securitycheck`                                 | Opt-in only                | Only for security-relevant changes                  | Every feature implementation               |
| `securityscan`                                  | Opt-in only                | After feature implementations (skips docs/cosmetic) | After **every** file edit                  |
| Guardrail compliance check                      | Skipped unless requested   | Checked for security-relevant files                 | Always checked                             |
| Forced extra turn if security tools weren't run | No                         | Yes                                                 | Yes                                        |
| Automatic scan fallback                         | No                         | Yes                                                 | Yes                                        |
| Critical/high findings in new code              | Reported only if you ask   | Auto-fixed                                          | Auto-fixed, blocks progress                |
| Medium findings in new code                     | Not surfaced automatically | Asks user                                           | Auto-fixed                                 |
| Low findings in new code                        | Not surfaced automatically | Asks user                                           | Asks user                                  |
| Pre-existing (untouched) code findings          | Not surfaced automatically | Asks user, never auto-fixes                         | Asks user, never auto-fixes                |
| Relative speed                                  | Fastest                    | Moderate                                            | Slowest                                    |

## Which mode should I use?

| Situation                                                                | Recommended mode   |
| ------------------------------------------------------------------------ | ------------------ |
| Quick experiment, demo, or scratch code                                  | Permissive         |
| Normal day-to-day feature work                                           | Balanced (default) |
| Auth, payments, personal data, infrastructure, compliance-sensitive work | Strict             |

**Tip:** If you start something in Permissive mode and decide to ship it, switch to Balanced or Strict and ask for a full review before merging — this ensures nothing gets missed just because you were moving fast earlier.