agentic-sdlc-mcp

Workflow Permissions Audit

workflow_permissions_audit

Read-onlyIdempotent

Scan GitHub Actions workflow YAML for permissions declarations and flag least-privilege gaps, write-all grants, and risky pull_request_target scopes.

Instructions

Scan .github/workflows/*.yml for permissions declarations (top-level and per-job) and flag least-privilege gaps.

Required token scope: repo (or public_repo for public-only repos) with read access to repository contents.

Args:

owner, repo: Repository coordinates.
ref: Optional. Branch, tag, or SHA to read workflow files from. Falls back to the repository's default branch.

Flags:

No permissions declared anywhere in the file (workflow or job level) -- relies on the repo/org default token scope instead of an explicit declaration.
permissions: write-all (top-level or per-job) -- grants write access to every scope.
Any scope granted write on a workflow triggered by pull_request_target -- a known injection/exfiltration risk since that trigger runs with the base repo's token against untrusted PR content.

Returns: per-file findings by severity and a least_privilege/needs_review/over_permissioned conclusion.

Input Schema

Name	Required	Description
`ref`	No	Branch, tag, or SHA to read workflow files from. Falls back to the repository's default branch.
`repo`	No	GitHub repo. Falls back to GITHUB_REPO.
`owner`	No	GitHub owner. Falls back to GITHUB_OWNER.

Output Schema

Name	Required	Description	Default
`ref`	Yes
`repo`	Yes
`errors`	Yes
`findings`	Yes
`conclusion`	Yes
`trustBoundary`	No
`workflowsScanned`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.11.0Oct 18, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedv1.9.0Jul 29, 2026

addedOutput schema / properties / trustBoundary

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "callerAndRepositoryContent": {
+      "const": "untrusted",
+      "type": "string"
+    },
+    "instructionHandling": {
+      "const": "never_execute",
+      "type": "string"
+    },
+    "permissionHandling": {
+      "const": "never_expand",
+      "type": "string"
+    },
+    "secretHandling": {
+      "const": "never_reveal",
+      "type": "string"
+    }
+  },
+  "required": [
+    "callerAndRepositoryContent",
+    "instructionHandling",
+    "secretHandling",
+    "permissionHandling"
+  ],
+  "type": "object"
+}

First observedv1.5.0Jul 9, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the required `repo`/`public_repo` token scope with contents read access, the three specific risk flags it detects (including the pull_request_target injection risk), and the severity/conclusion output shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then cleanly sectioned into token scope, args, flags, and returns. The Args block is redundant against the 100%-covered schema, but the Flags section earns its length by explaining what each finding means.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and annotations carry the safety profile, yet the description still supplies the auth scope and the meaning of each flag, which is what an agent needs to invoke and interpret results correctly. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all three parameters with the same fallback behavior. The Args section largely restates the schema ('Optional. Branch, tag, or SHA...'), adding no syntax or format detail beyond it; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource: scanning `.github/workflows/*.yml` for `permissions` declarations and flagging least-privilege gaps. This is clearly distinguishable from siblings like `security_triage` or `branch_protection_status` because it targets workflow-file permissions specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when the tool applies (auditing workflow permissions) and names the required token scope, which functions as a prerequisite. However, it never names an alternative tool or states when NOT to use it, so no sibling routing is offered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server