Templates
5
Agent policy guide
Agent policy authoring guide.
Author policies that tell product, engineering, QA, security, and support agents exactly what they may do, which approvals are needed, which actions are blocked, when to escalate, and what audit evidence must exist before work is trusted.
Agent policy guide summary
Scope rules
8
Validation rules
6
Troubleshooting
5
Policy templates
Product, engineering, QA, security, and support agents need separate authority boundaries.
Templates start from job-specific risk. Each one names the owner, scope, approvals, blocked actions, escalation rules, and audit outcomes expected before the agent can execute.
Product lead
Product planning agent
Converts product intent into scoped issues, dependencies, acceptance criteria, and launch notes.
Escalates: Conflicting priorities, Unclear requirements, Launch-blocking gap
Engineering lead
Engineering implementation agent
Implements assigned issues with code, tests, local docs, and review evidence.
Escalates: Failing required tests, Missing context, Unsafe migration, Permission mismatch
QA owner
QA verification agent
Validates browser journeys, acceptance checks, regression risk, and evidence quality.
Escalates: Flaky test, Missing acceptance criteria, Uncovered critical journey
Security owner
Security review agent
Reviews auth, export, token, audit, tenant boundary, and policy exception risk.
Escalates: Data exposure risk, Tenant isolation ambiguity, Missing audit trail, Unreviewed secret path
Support owner
Support triage agent
Routes support intake, severity, account recovery, billing questions, and customer-safe replies.
Escalates: S0 or S1 impact, Legal or security concern, Billing dispute, Unclear requester authority
Scopes and controls
Workspace, project, issue, tool, environment, data, billing, and audit scopes must be explicit.
| Scope | Authoring rule | Validation rule | Audit evidence |
|---|---|---|---|
| Workspace | Name the workspace and role boundary before the agent can act. | Missing workspace or broad all-workspace language blocks activation. | Workspace ID, role, policy version, and author. |
| Project | Limit work to named projects or milestones. | Unknown project, archived project, or cross-workspace reference blocks activation. | Project ID, milestone, and linked issue IDs. |
| Issue | Bind execution to assigned issues and task contracts. | Agents cannot act on unrelated issues without a new approval request. | Issue ID, task contract version, claim, and lease window. |
| Tool | List allowed tools and denied tools separately. | Any requested tool outside the allowlist is rejected before execution. | Tool grant, requested action, denial or approval, and reviewer. |
| Environment | Separate local, preview, staging, and production permissions. | Production action requires explicit environment approval. | Environment, deploy or run ID, approval, and rollback reference. |
| Data | Define safe data classes, redaction, exports, retention, and customer boundaries. | Secrets, payment data, and private workspace content require stricter controls. | Data class, redaction decision, export ID, and retention note. |
| Billing | Name allowed billing reads and blocked billing mutations. | Refunds, plan changes, and invoice changes require human approval. | Stripe object reference, support issue, approver, and summary. |
| Audit | Define which events must be emitted for policy decisions. | Missing audit outcome blocks policy approval. | Event type, actor, policy version, affected resource, and request ID. |
Validation and troubleshooting
Policy validation fails closed until approval gaps, blocked-action conflicts, escalation owners, and audit outcomes are resolved.
Missing owner
Policy has no accountable owner or backup owner.
Fix: Assign a human policy owner before the policy can be used by an agent.
Scope too broad
Policy scope is broader than the workspace role, project, issue, environment, or plan allows.
Fix: Narrow scope to named resources before adding permissions.
Approval gap
Risky action, export, production, billing, or security work lacks required approval.
Fix: Add the required approval owner or block the action until approval exists.
Blocked action conflict
An action appears in both allowed and blocked sections.
Fix: Remove the action from one section and record the decision in audit outcomes.
Escalation missing
A trigger exists without a named human escalation owner.
Fix: Assign the human owner and response expectation before activation.
Audit outcome missing
Policy omits actor, resource, request ID, policy version, or evidence link.
Fix: Add the missing audit field and verify it is emitted by the workflow.
Need help?
Policy support uses task contracts, policy versions, denied tools, approvals, and audit events, not raw secrets or private customer data.
Keep the policy owner, assigned agent, workspace, issue ID, policy version, request ID, and redacted examples available before asking for help.