Skip to main content

Policy Profiles

Policy profiles are built-in, named presets that write a curated .rules bundle into your machine-wide ~/.sigmashake/policy/profiles/ directory and record the profile name in ~/.sigmashake/policy/manifest.toml. They are complementary to project-level .sigmashake/rules/ files — profile rules load alongside project rules on every eval, regardless of which directory you work in.

How profiles are loaded​

The policy layer is evaluated in this priority order (highest priority overrides lower):

  1. Session rules (~/.sigmashake/policy/session/ — temporary, in-session overrides)
  2. Project rules (.sigmashake/rules/ in the current working directory)
  3. Active profile rules (~/.sigmashake/policy/profiles/)
  4. User-global rules (~/.sigmashake/policy/user/)

Within each layer, rule priority values determine which rule fires first. First match wins.

Available profiles​

There are six built-in profiles. Run ssg policy profile list to see which are currently active (an asterisk marks active profiles).

cost-efficient-agent​

Gates expensive, network-heavy dependency inspection commands with ASK so the agent must pause and get approval before querying the package registry.

Asks before: commands like npm audit, npm outdated, and cargo search.

Use when: You want to constrain autonomous agents from making many API calls to package registries without asking.

ssg policy profile use cost-efficient-agent

deploy-guard​

Requires human approval before any deployment-impacting infrastructure command executes.

Asks before: terraform apply, kubectl apply, helm upgrade

Use when: You run infrastructure-as-code and want every apply to require a human acknowledgement, even when the agent has full shell access.

ssg policy profile use deploy-guard

no-network​

Blocks all direct outbound network fetches from shell commands. Useful in air-gapped development environments or when you need to prevent an agent from making unexpected outbound connections.

Blocks: shell commands that invoke common network transfer tools.

Use when: You want to prevent agents from pulling content from the internet during a sensitive coding session.

ssg policy profile use no-network

paranoid-git​

Prevents destructive git history rewrites (decision: block) and asks for approval before potentially data-losing cleanup commands (decision: ask).

Blocks: force-push variants (--force / -f flags on git push)

Asks before: hard resets and working-tree wipe commands

Use when: You work on shared branches and want an absolute guarantee that autonomous agents can never force-push or wipe your working tree without explicit approval.

ssg policy profile use paranoid-git

safe-coding​

Requires approval before any package manager installs a new dependency. Applies to npm, pnpm, yarn, and bun.

Asks before: npm install, pnpm add, yarn add, bun add

Use when: You want an agent to code and test freely, but not silently alter your dependency tree.

ssg policy profile use safe-coding

strict-secrets​

Blocks all file writes to common secret-bearing paths. No agent can overwrite a .env, .pem, or .key file unless a higher-priority project rule explicitly allows it.

Blocks writes to: files ending in .env, paths containing .pem, paths containing .key

Use when: You want a machine-wide, project-agnostic backstop to prevent any agent from writing credentials, regardless of what project rules say.

ssg policy profile use strict-secrets

Commands​

# See all available profiles and which are active
ssg policy profile list

# Activate a profile machine-wide
ssg policy profile use <name>

# Deactivate a profile
ssg policy profile unuse <name>

# Show the full active policy stack (profiles + user rules + project rules)
ssg policy status

# List every effective rule with its origin (which profile or file it came from)
ssg policy list

# Machine-readable JSON output for any of the above
ssg policy profile list --json
ssg policy status --json
ssg policy list --json

Combining profiles​

Multiple profiles can be active simultaneously. If two profiles define rules with overlapping conditions, the higher priority value wins. Inspect the merged, deduped effective rule set with:

ssg policy list

How profiles are stored​

Each active profile writes a <name>.rules file into ~/.sigmashake/policy/profiles/. The active profile names are tracked in ~/.sigmashake/policy/manifest.toml:

[policy]
active_profiles = ["paranoid-git", "safe-coding"]
default_scope = "user-global"

[session]
enabled = true

[compat]
import_legacy_global_db = true

Profile rules are managed by ssg. Do not hand-edit files in ~/.sigmashake/policy/profiles/. If you need to customize a profile's rules, deactivate it and add your own rules to ~/.sigmashake/policy/user/ instead.

See also​

The built-in sleep-at-night preset is a special case: it is managed entirely by the "Sleep at Night" feature, not the normal profile activation flow. See Spending Limits and Sleep at Night.