# Rules and Controls

> Choose repository Rules for actions and Controls for access restrictions.

Source: https://docs.synkro.sh/concepts/rules-and-controls

## Rules check actions

A Rule checks an agent action. Your team keeps it in a TOML file in the repository's Rule package.

Examples:

- Stop a command that deletes a protected directory.
- Ask for approval before adding a dependency.
- Flag an edit that breaks a project requirement.

Use the [Rules guide](/guides/rules) to add and test one.

## Controls restrict access

A Control restricts access for everyone, a user, or a group. For example, it can block calls to a named MCP server.

Controls are not Rule files. An organization owner manages them through an authorized integration; there is no general Control editor command.

## MCP approvals

An MCP approval permits a server/tool coordinate under the project's published
policy. Projects declare approvals or denials in `synkro.toml`; packages supply
approve-only defaults in `synkro-package.toml`. Project exact entries take
precedence over project wildcards, which take precedence over package defaults.

Without approval, observe mode flags the call with a notice; enforce mode blocks
it. Approval removes only that check. It does not override another Rule or
Control and does not grant [one-action consent](/guides/consent).

Use [Approve MCP tools](/guides/mcp-approvals) to review a scope, edit it with the
CLI and verify the next recorded call.

## One does not cancel the other

Allowing an action through a Control does not override a blocking Rule or the setting that blocks unmatched MCP calls.

If an action is refused, inspect its decision to see which check refused it:

```sh
synkro events --type verdict --limit 5 --details
```

Use a Rule for checks specific to a repository. Ask your organization owner about access Controls.