Scylla
Sign InDownload

Support

Managed Policy

Apply an organization authority ceiling that developers can tighten but not weaken.

Managed Policy lets a Scylla Team organization establish an authority baseline for Agent operations.

The governing principle is:

A developer may tighten an organization rule, but may not weaken an organization-enforced restriction.

This lets teams deploy powerful Agent capabilities without turning every developer workstation into an independently governed security model.

Managed Policy is an authority ceiling

Suppose the organization defines:

Git push        ASK
Force push      BLOCK
Database read   ALLOW
Database write  ASK
Database admin  BLOCK

A developer can choose to be stricter:

Git push        BLOCK
Database read   ASK

But the developer cannot locally change:

Force push      BLOCK

into:

Force push      ALLOW

if the organization restriction is enforced.

Managed Policy is not remote control of the whole workstation

Scylla is not an operating-system sandbox or endpoint-management product.

Managed Policy governs Scylla-controlled operations and supported capability paths. It does not replace:

  • Windows permissions;
  • Git provider permissions;
  • database permissions;
  • SSH/server permissions;
  • cloud IAM;
  • endpoint-management software.

Those systems continue to enforce their own authority.

Policy domains

The exact rules available depend on the current Scylla build and enabled capabilities.

Common domains include:

  • filesystem;
  • Git;
  • database;
  • shell;
  • MCP/external tools.

Do not create a Managed Policy rule for a capability that the organization does not actually use simply to make the matrix look complete.

Publish authoritative Policy

Organization Policy should have a clear authoritative state.

If the Team console supports draft and publish behavior:

  1. Edit the desired verdicts.
  2. Review the changed rules.
  3. Publish the Policy.
  4. Confirm the server-reported Policy version/state.
  5. Let desktops refresh the managed state.

Do not infer a new version number only from local UI state.

Effective Policy

The useful question for a developer is not only:

What did the organization configure?

It is:

What verdict actually applies to me for this operation?

Scylla should resolve the effective rule from the applicable organization and local constraints.

A Member may see an organization-enforced verdict without receiving editing controls.

Managed Policy and local Policy

Keep the roles clear:

Managed Policy

Organization-level ceiling.

Local Policy

Developer/project configuration that may remain equal or become more restrictive.

Hard safety / capability constraints

Rules Scylla will not weaken merely because either Policy layer says ALLOW.

Managed Policy and Agent Providers

Provider permissions are subordinate to Scylla authority.

If a provider presents its own "always allow" or durable permission option, that option cannot be used to weaken an organization-enforced Scylla rule.

Provider capability describes what the provider can request. Managed Policy still decides what Scylla will authorize through its controlled path.

Managed Policy and connections

A Connection being configured does not imply its operations are allowed.

For example, the organization can permit a production database Connection to exist while keeping database writes at ASK or BLOCK.

This separation is intentional.

What happens when Team services are unavailable

A hosted service outage must not silently widen authority.

If Scylla cannot refresh managed state, it should follow the product's safe cached/offline behavior rather than interpreting "could not reach Team" as "no Team restrictions exist."

For a new Team:

  1. Start from the operations the organization already understands.
  2. Keep destructive/administrative operations at BLOCK.
  3. Put consequential but common operations at ASK.
  4. Use ALLOW for routine low-risk reads and operations that do not need interruption.
  5. Test with a small group before broad deployment.
  6. Review where ASK is genuinely useful versus merely noisy.

The goal is not to maximize prompts. The goal is to put human attention at meaningful boundaries.

Audit and change control

When the Team console provides Policy history, use it to answer:

  • what changed;
  • when it changed;
  • who published it;
  • which version is current.

Do not rely on screenshots as the sole record of Policy state.

Common problems

A member says a rule is locked

Check whether the rule is enforced by the organization.

A developer tightened a rule but wants to undo it

They can normally return to the organization ceiling, but cannot become less restrictive than it.

Provider says an action is permitted but Scylla blocks it

Provider permission and Scylla Policy are different layers. Scylla's effective authority still applies.

Team Policy appears missing on desktop

Confirm the user is signed into the correct Scylla Account/organization and that Team account state is healthy.