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

# Credential policies

> Control which operations agents can perform with each connected credential.

Credential policies let you define fine-grained access rules that the runtime enforces before any request reaches the external service. Limiting what each agent can do with a credential reduces the impact when something goes wrong.

## How policies work

A credential policy is a list of rules. The runtime evaluates each rule against the incoming request. If a matching `DENY` rule exists, the runtime blocks the request regardless of any `ALLOW` rules. If no rule matches, the runtime denies the request by default.

```yaml theme={null}
github:
  - decision: ALLOW
    operations: [pulls_list, pulls_get, issues_list_for_repo, issues_get]
```

Each rule has a `decision` and one or more conditions. When a rule omits a condition field, that field matches unconditionally.

### Rule fields

| Field        | Type              | Description                                                                     |
| ------------ | ----------------- | ------------------------------------------------------------------------------- |
| `decision`   | `ALLOW` \| `DENY` | Whether to permit or block the request when this rule matches.                  |
| `operations` | list of strings   | Operation names or patterns this rule applies to. Omit to match all operations. |

## Operations field

The `operations` field specifies which operations a rule applies to. The runtime matches each entry against the incoming operation name.

Values support glob-style wildcard patterns using [`fnmatch`](https://docs.python.org/3/library/fnmatch.html) syntax:

| Pattern     | Matches                              |
| ----------- | ------------------------------------ |
| `pulls_get` | Only the exact operation `pulls_get` |
| `pulls_*`   | Any operation starting with `pulls_` |
| `*_list`    | Any operation ending with `_list`    |
| `*`         | Any operation                        |

Patterns are case-sensitive. A `null` operation never matches any pattern, including `*`.

### Exact names

To allow a specific set of operations, list them by name:

```yaml theme={null}
github:
  - decision: ALLOW
    operations: [issues_get, issues_list_for_repo, pulls_get, pulls_list]
```

### Wildcard patterns

To target a group of related operations, use a pattern. This example allows all `issues_` and `pulls_` operations without listing each one individually:

```yaml theme={null}
github:
  - decision: ALLOW
    operations: [issues_*, pulls_*]
```

A bare `*` matches every operation:

```yaml theme={null}
github:
  - decision: ALLOW
    operations: [*]
```

<Note>
  Wildcards follow Python's `fnmatch` case-sensitive matching. The pattern `get_*` matches `get_issue` and `get_pull` but not `Get_issue`.
</Note>

## DENY and ALLOW precedence

`DENY` rules take precedence over `ALLOW` rules. If any rule with `DENY` matches an operation, the runtime blocks the request even when a separate `ALLOW` rule also matches.

To block specific operations while permitting everything else, add a targeted `DENY` rule alongside a catch-all `ALLOW`:

```yaml theme={null}
github:
  - decision: DENY
    operations: [repos_delete, repos_delete_release]
  - decision: ALLOW
    operations: [*]
```

Wildcard patterns work the same way in `DENY` rules. To block all deletion-style operations by pattern:

```yaml theme={null}
github:
  - decision: DENY
    operations: [*_delete, repos_delete_*]
  - decision: ALLOW
    operations: [*]
```

<Warning>
  A `DENY` rule with a wildcard pattern blocks every matching operation regardless of any `ALLOW` rules. Verify your patterns before deploying to production.
</Warning>