Skip to main content
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.
Each rule has a decision and one or more conditions. When a rule omits a condition field, that field matches unconditionally.

​
Rule fields

​
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 syntax: 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:

​
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:
A bare * matches every operation:
Wildcards follow Python’s fnmatch case-sensitive matching. The pattern get_* matches get_issue and get_pull but not Get_issue.

​
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:
Wildcard patterns work the same way in DENY rules. To block all deletion-style operations by pattern:
A DENY rule with a wildcard pattern blocks every matching operation regardless of any ALLOW rules. Verify your patterns before deploying to production.