// Use when designing or reviewing an AI agent system that needs policy-based access controls, intent classification, tool-level rate limiting, trust scoring for multi-agent workflows, or append-only audit trails.
Use when Copilot CLI's built-in tools do not cover a service you need — for example PostgreSQL, Redis, Jira, Slack, or an internal API — and you need to add an MCP server beyond the default GitHub MCP. NOT when the built-in tools already cover the task.
Use when auditing an AI agent system against the OWASP Agentic Security Initiative Top 10 — checks tool access, prompt boundaries, memory handling, and operational safeguards across the agent pipeline.
Use when you need to evaluate an LLM pipeline or AI feature systematically — sets up an eval harness with test cases, scoring rubrics, and pass/fail tracking rather than one-off manual spot-checks
Use when reviewing or planning QA strategy for a feature, PR, or release so test coverage, test quality, reliability, and defect reporting are handled as a coherent engineering discipline instead of ad hoc checks.
Use when creating or validating a Git branch name so the branch follows a conventional type/description format, matches the work being done, and starts from the right base branch.
Use when work is changing sessions, agents, or machines and the next pass needs a compact handoff document with current state, open questions, and next steps instead of raw chat history.
| name | agent-governance |
| description | Use when designing or reviewing an AI agent system that needs policy-based access controls, intent classification, tool-level rate limiting, trust scoring for multi-agent workflows, or append-only audit trails. |
| metadata | {"category":"security","agent_type":"general-purpose","origin":"adapted from github/awesome-copilot agent-governance (MIT)"} |
Add explicit policy, trust, and audit controls around agent behavior before "helpful" automation becomes unbounded automation.
| Instead of agent-governance | Use |
|---|---|
| Broad repository security scoring | evaluate-repository |
| OWASP ASI checklist review | agent-owasp-check |
| Architecture-first threat modeling | threat-model-analyst |
Think in this order:
User request -> intent classification -> policy check -> tool execution -> audit log
↓ ↓ ↓
threat signals allow/review/deny trust update
A useful governance layer usually needs five parts:
Start with a serializable policy instead of hardcoding checks across business logic.
Include:
allowed_toolsblocked_toolsblocked_patternsmax_calls_per_requestrequire_human_approvaltool_policiesExample shape:
name: production-agent
allowed_tools:
- search_documents
- query_database
blocked_tools:
- shell_exec
- delete_record
blocked_patterns:
- "(?i)(api[_-]?key|secret|password)\\s*[:=]"
max_calls_per_request: 25
require_human_approval:
- send_email
tool_policies:
shell_exec:
rate_limit: 3/hour
approval: required
justification: ticket-or-incident
query_database:
rate_limit: 30/request
approval: not-required
Use "most restrictive wins" when composing org-wide, team, and agent-specific policies.
When a system supports a ToolPolicy schema, keep rate-limit, approval, and
justification guards in that policy layer instead of scattering them across
prompts, docs, and handler code.
Do not wait until after a tool runs to discover the request was dangerous.
Look for signals such as:
Keep the classifier simple and auditable first:
Every tool call should answer:
Apply the checks at the boundary where the tool is actually invoked, not only in a planner or prompt template.
Multi-agent systems need memory of which delegates are reliable.
Track at least:
Use trust thresholds to choose between:
Trust should decay over time so stale reputation does not behave like permanent trust.
If remote identities, signed delegates, or service-issued agent credentials affect authorization, define the trust boundary before enabling autonomy:
Do not let planner, worker, verifier, and synthesizer roles silently share one flat trust zone when their permissions differ.
For every governed action, log:
allowed, denied, error, review)Export to JSONL or another append-only form that works with later incident review.
| Level | Controls | Good fit |
|---|---|---|
| Open | Audit only | internal experimentation |
| Standard | Allowlist + content filters | general production agents |
| Strict | Standard + approval on sensitive tools | regulated or customer-facing systems |
| Locked | Allowlist only + full audit + no dynamic tools | compliance-critical environments |
As systems mature, separate the governance contract into a few explicit layers:
This keeps tool policy, identity, trust, and audit requirements reviewable instead of burying them in one prose blob.
| Rationalization | Reality |
|---|---|
| "We trust our agent because we wrote it." | Governance is about constraining runtime behavior, not trusting authorship. |
| "The model will probably avoid risky tools on its own." | Tool access without enforcement is a permission model with no guardrails. |
| "We log enough already." | Generic app logs rarely capture policy decisions, denials, or agent-to-agent trust changes. |
agent-owasp-check - audit an existing agent system against OWASP ASI risksthreat-model-analyst - model architecture and trust-boundary risksevaluate-repository - broader repository security and AI governance review