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.

​
Resource constraints

Rules can constrain which resources an operation may touch, not just which operations are allowed. The runtime extracts resource identifiers from each outbound request — the repository from a GitHub API path, the channel from a Slack payload, the hostname from an HTTP request — and matches them against the rule before the request leaves Guild.
This rule lets an agent read issues and pull requests in two named repositories and nothing else — even if the underlying credential can reach every repository in the organization. Use methods to separate read access from mutating access. A rule that allows only GET grants read-only access regardless of which operations it matches.

​
Scoping rules to agents and workspaces

Each rule can be scoped to specific agents, specific workspaces, or both. A rule without scoping applies to every agent and workspace that uses the credential. Scoped rules let you give one agent read-only access to one repository while another agent gets write access to a different one, all on the same connected credential. Configure scoping when creating or editing a policy in the UI, or pass --agents and --workspaces to the CLI:

​
Enforcement

Policies are enforced inside Guild’s credential proxy, before any request reaches the external service. Agents never evaluate policy themselves and cannot bypass it: the credential is injected server-side only after the policy check passes. If no rule allows a request, it is denied by default, and a matching DENY rule always wins over any ALLOW. See Credentials for how server-side credential injection works.