Configure Policy

Scylla Policy defines what consequential operations an Agent may perform through Scylla-controlled paths.

The core model is intentionally small:

ALLOW
ASK
BLOCK

Prompts express intent. Policy defines authority.

The three verdicts

ALLOW

Scylla may permit the operation without stopping for a Policy approval prompt, assuming every other required boundary also passes.

ALLOW does not override:

• Workspace Scope;
• Knowledge Scope;
• operating-system permissions;
• missing credentials;
• Team-managed restrictions;
• connection restrictions;
• hard safety checks;
• provider limitations.

ASK

Scylla pauses at the operation boundary and asks for approval.

ASK is useful for operations that are legitimate but consequential, such as a Git push, project deletion, write query, package installation, or external mutation.

Approval applies to the request Scylla presents. It is not a blanket grant for unrelated future work.

BLOCK

Scylla refuses the operation.

BLOCK is appropriate for operations you do not want an Agent to perform through Scylla, even when a prompt asks for them.

Policy domains

The exact operations visible depend on the current Scylla build and enabled capabilities. Typical domains include:

• Filesystem;
• Git;
• database;
• shell/terminal;
• SSH or brokered connections;
• MCP/external tools.

Do not assume every operation in a domain is implemented simply because the Policy surface has a category for it.

A practical starting point

A conservative development Policy often looks like this conceptually:

Use this only as a model. Configure the rules that fit your environment.

Policy is not an OS sandbox

Scylla runs provider tools and approved commands as the signed-in Windows user.

Policy reduces accidental or unwanted operations through Scylla-controlled execution paths. It is not a kernel, VM, or operating-system sandbox for arbitrary untrusted code.

Windows permissions, provider behavior, Git server permissions, database permissions, and remote-service permissions still matter.

Scope and Policy solve different problems

Workspace Scope answers:

Which project folders are active for Scylla and Agents in this session?

Knowledge Scope answers:

Which non-project reference folders are available as Knowledge?

Policy answers:

What operations may an Agent perform through Scylla?

A folder being in Workspace Scope does not mean every operation against it is automatically allowed.

Authentication is not Policy

A connected provider, database, SSH host, or MCP server is not automatically authorized for every action.

For example:

MCP server connected
≠ every MCP tool allowed

Database connection succeeds
≠ schema changes allowed

Git remote authenticated
≠ force push allowed

Scylla intentionally keeps connectivity and authority separate.

Keyring unlock is not Policy

Unlocking the Keyring makes protected values available to Scylla's trusted application paths.

It does not grant an Agent blanket permission to use those values or to perform operations associated with them.

The operation still has to pass the applicable scope, Policy, Broker, and connection rules.

Global and project context

Scylla maintains Policy in the context of the application and active projects. The exact UI and precedence visible in your build may vary as Policy capabilities evolve.

When multiple Policy layers apply, Scylla should resolve to the effective authority rather than assuming a weaker local setting can override a stronger restriction.

For Team organizations, see Managed Policy.

Test your Policy

After making changes, use harmless operations to confirm the result:

1. Ask for a project file read.
2. Ask for Git status.
3. Ask for a small file write.
4. Ask for an operation configured as ASK.
5. Confirm Scylla presents an approval.
6. Ask for an operation configured as BLOCK.
7. Confirm Scylla refuses it.

Do not test destructive rules against production data just to prove that BLOCK works.

Unknown operations

When Scylla cannot confidently classify a consequential operation, the safe outcome should not silently become ALLOW.

If an operation appears under an unknown/unsupported category, review the request rather than weakening Policy to make it run.

Team-managed Policy

A Team organization can establish a managed Policy ceiling.

The central rule is:

Developers may tighten organization policy, but they may not weaken an organization-enforced restriction.

That allows teams to preserve local developer flexibility while keeping important organizational boundaries upstream.

See Managed Policy.

Troubleshooting Policy

If an operation you expect to work is blocked:

• confirm the active project;
• confirm the operation belongs to the Policy rule you think it does;
• check for Team-managed restrictions;
• verify the required Connection exists;
• verify the Keyring is unlocked when needed;
• check whether the provider/runtime actually supports the capability.

If an operation seems allowed but still fails, Policy may not be the failing layer. See Troubleshooting.