agentleFS
aiappsgbbaiappsgbb/awesome-gbb/skills/foundry-rbac-audit/SKILL.md

foundry-rbac-audit

Skill8 starsChanged 12 days agoMITView on GitHub

Probes Azure RBAC role assignments at a resource-group scope for privilege-escalation risks (Owner, User Access Administrator, RBAC Administrator). Returns a spec §4.3.1 sibling-skill dict with finding_id "IAM-101", observations, remediation hints, confidence, and never raises. USE FOR: threadlight IAM-101 sibling-skill flip, rbac audit on a Foundry-adjacent resource group, least privilege review before spoke onboarding, over-privileged detection after team offboarding, role assignment audit for spoke security probe, scheduled CI security check on a Foundry project RG. DO NOT USE FOR: granting or revoking roles — use az role assignment create/delete instead; DO NOT USE FOR: Foundry-internal agent identity or per-agent-instance MI RBAC — use foundry-agt; DO NOT USE FOR: hub-side Citadel security checks — use citadel-spoke-onboarding probe_hub_contract.

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Only RG scope is supported.

    line 144

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

foundry-rbac-audit

Peer skill that probes Azure RBAC assignments at a resource-group scope for privilege-escalation risks, returning a structured IAM-101 finding. It wraps AuthorizationManagementClient via DefaultAzureCredential and never raises — errors are captured in the returned dict. Threadlight v0.5.3+ consumes this as the IAM-101 sibling-skill check in its threadlight-production-ready SEC-301 gate.

When to use

  • Threadlight IAM-101 sibling-skill flip — threadlight's apply-plan reasoner calls probe() directly to satisfy the SEC-301 → IAM-101 check.
  • Pre-pilot security review of a Foundry-adjacent resource group before spoke onboarding — confirms no over-privileged principals hold Owner or equivalent roles.
  • Scheduled CI check after team offboarding — detects residual privilege assignments; orphan-principal detection (deleted Entra IDs) is explicitly out of scope for v1.0.0.

When NOT to use

  • Granting or revoking role assignments — use az role assignment create / az role assignment delete directly.
  • Foundry-internal agent identity or per-agent-instance MI RBAC — use the foundry-agt skill for identity lifecycle on hosted agents.
  • Hub-side Citadel checks — use citadel-spoke-onboarding and its probe_hub_contract for APIM/hub-scope governance.

Probe contract

The probe returns a dict matching the design spec §4.3.1 sibling-skill contract. Signature and shape are stable across 1.x releases:

FieldTypeNotes
finding_idstrAlways literal "IAM-101"
scopedict (sub_id, rg)Nested; not a string
resultenum ok / needs_attention / erroredNever anything else
observationslist[dict]Empty when result == "ok"
remediation_hintslist[str]Empty when observations empty
confidence0.0 / 0.5 / 1.0See Confidence heuristic below
probed_atISO-8601 UTC with Ztz-aware
errorstr | NoneNone on success; "<Type>: <msg>" on errored

Never raises. Any Azure exception is caught and surfaced via result["error"] with result["result"] = "errored" and confidence = 0.0.

Confidence heuristic

The catalog-wide §4.3.1 confidence convention (documented here so threadlight's apply-plan reasoning is reproducible):

  • 1.0 — probe completed AND at least one role assignment matched the principal-type filter (whether or not any were privilege-escalation).
  • 0.5 — probe completed but no assignments matched the filter (ambiguous: empty RG vs Reader-masked enumeration).
  • 0.0 — probe raised internally and was caught.

Observation rows

Each observation row has these keys (all populated on every row):

FieldNotes
principal_idThe assignee object ID
role_definition_idFull SDK resource path
role_nameFriendly name (e.g. "Owner")
principal_typeSDK raw value (e.g. "User")
severity"critical" or "high"
scopeThe assignment's scope as reported by Azure

The probe currently flags assignments at three privilege-escalation roles:

Role GUIDFriendly nameSeverity
8e3af657-a8ff-443c-a75c-2fe8c4bcb635Ownercritical
18d7d88d-d35e-4fb5-a5c3-7773c20a72d9User Access Administratorcritical
f58310d9-a9f6-439a-9e8d-f62e7b41a168Role Based Access Control Administratorhigh

Probe Reference

MUST: Read the canonical probe at references/python/probe.py. Do NOT re-paste its body here — the validator enforces single-source-of-truth.

CLI

cd skills/foundry-rbac-audit/references/python
mkdir -p out
python __main__.py \
    --subscription-id <sub-id> \
    --resource-group <rg> \
    --target-principal-types user,service_principal

Result is printed to stdout as JSON. The manifest is also written to out/IAM-101.json (relative to CWD). Same-finding-ID writes overwrite the prior manifest by design (threadlight reads the file by literal finding-id name).

Authentication uses DefaultAzureCredential. The caller must hold Microsoft.Authorization/roleAssignments/read and Microsoft.Authorization/roleDefinitions/read at the target RG scope.

Threadlight integration

Threadlight v0.5.3+ consumes this probe for the IAM-101 sibling-skill flip (kind: sibling-skill). It calls probe() directly (no CLI subprocess) with target_principal_types passed by keyword. The manifest file at out/IAM-101.json is the cross-process handoff for threadlight's apply-plan reasoner.

Known limitations (v1.0.0)

This elevated-role audit is not the hosted exact-permission preflight. It does not certify invoke, version-read, response-read, source access or repository-scoped pull. Use the actual caller/pull/runtime/result-reader identities and operation-specific evidence; do not treat an ok here as permission to proceed with those operations.

  • Orphan principal detection (assignments to deleted Entra IDs) is out of scope for v1. Threadlight has not requested it.
  • Only RG scope is supported. Subscription scope and management-group audits are intentionally excluded — the threadlight use case is spoke-RG-bounded.
  • The privilege-escalation role list is hard-coded (3 GUIDs). Custom roles equivalent to Owner are NOT detected. A v1.1.0 release can add a custom_role_guids: list[str] kwarg if a customer asks.

See also

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.