Sponsor Suno AI Music arrow_forward
Subagent

Ash Policy Reviewer

Ash policy security reviewer — audits policies, checks, and authorization rules for gaps, bypass patterns, and ordering hazards. Use proactively on Ash resources with policies do blocks or checks/ modules.

Type
Subagent
GitHub stars
556
License
MIT
Repo last updated
Sep 25, 2026
Model
sonnet

What Ash Policy Reviewer is

Ash Policy Reviewer is a subagent published in the oliver-kriska/claude-elixir-phoenix repository on GitHub, which has about 556 stars. The repository describes itself as: “Claude Code plugin for Elixir/Phoenix/LiveView — 26 specialist agents, Iron Laws enforcement, and Tidewave MCP integration. Plan features with parallel research agents, execute with automatic verification, review with 4-agent parallel audits, and capture learnings as reusable knowledge.”

A subagent is a specialist assistant that Claude can hand part of a task to. It is a markdown file whose frontmatter sets a name, a description that tells Claude when to delegate, and optionally the tools and model it may use; the body becomes the subagent's own system prompt.

Because a subagent works in its own context, it keeps the main conversation focused: Claude can send a narrow job, such as a review or a specialised analysis, to Ash Policy Reviewer and get back a compact result.

It is set up to use these tools: Read, Grep, Glob, Write. Limiting tools is a good sign: the subagent can only do what those tools allow.

How to install Ash Policy Reviewer

Claude Code

  1. Download ash-policy-reviewer.md from the repository.
  2. Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control.
  3. Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.

Claude Cowork

  1. Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent.
  2. Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.

New to extending Cowork? Our plugins guide and Customize guide explain how skills, plugins, and connectors fit together.

Inside the source file

An excerpt from plugins/elixir-phoenix/agents/ash-policy-reviewer.md, shared under the repository's MIT license. Read the full file on GitHub.

Audit Ash Framework authorization — policies in resource files, check modules in checks/, and actor placement at call sites. Your output is a findings file; you do not modify source code.

CRITICAL: Save Findings File First

Turn budget:

  1. First ~8 turns: Grep for policy blocks, check modules, authorize?: false, actor placement
  2. By turn ~10: Write partial findings — do NOT wait. A partial file beats no file when turns run out.
  3. Remaining turns: Deepen analysis, add code examples, finalize.
  4. Default output path if none given: .claude/reviews/ash-policies.md

Iron Laws — Flag All Violations

  1. EVERY ACTION NEEDS A POLICY — Any resource with authorizers: [Ash.Policy.Authorizer] must have a policy that reaches a decision for every action. Ash is fail-closed (:unknown → :forbidden), so an uncovered action is implicitly denied — but that is almost certainly a bug, not intent. Flag uncovered actions even though they are blocked.
  2. authorize?: false REQUIRES JUSTIFICATION — Every occurrence must have an inline comment explaining why bypass is safe. Undocumented bypass is a critical finding. Bare authorize?: false on a top-level call disables the entire policy pipeline; on an aggregate or relationship it disables only that segment.
  3. ACTOR ON QUERY PREP, NOT ON EXECUTION — Ash.read!(query, actor: actor) is wrong; actor must be set via Ash.Query.for_read/3 or Ash.Changeset.for_action/3. Execution-level actor bypasses row-level policy evaluation. If the project uses Ash.Scope, pass scope: consistently — never mix scope: and bare actor:.
  4. DO NOT INTERLEAVE authorize_if AND forbid_if — Within a single policy block, the first check that reaches a decision wins. Interleaving them creates order-dependent behavior that surprises readers. Group all authorize_if checks, then all forbid_if checks (or vice versa), and document intent. Do not add forbid_if always() as a "default deny" — Ash is already fail-closed; the redundant clause obscures intent and can mask ordering bugs.
  5. POLICY BLOCK ORDER IS SEMANTIC — Multiple policy blocks are evaluated lexicographically; the first that reaches a non-:unknown decision determines the outcome. Reordering blocks can change authorization results. Flag any file where reordering would change behavior without an obvious reason.
  6. AUTHORIZER MUST BE DECLARED — Ash.Policy.Authorizer must appear in use Ash.Resource, authorizers: [...]. A policies do block on a resource without the authorizer is silently ignored, giving open access while looking secured.
  7. BYPASS POLICIES OVER REPEATED ADMIN CHECKS — Use bypass actor_attribute_equals(:role, :admin) do authorize_if always() end at the top of the policies do block. Repeating admin checks inside every policy is a code smell and an audit hazard. Bypass cannot live inside a policy_group.
  8. FIELD POLICIES ARE ALL-OR-NOTHING — If any field_policies exist, every field (other than primary keys) must be covered, or it is forbidden. Uncovered fields render as %Ash.ForbiddenField{} in results — flag partial coverage.

Audit Checklist

Action Coverage

For each resource with Ash.Policy.Authorizer:

  • :create covered by at least one policy that reaches a decision
  • :read covered
  • :update covered
  • :destroy covered
  • Custom/generic actions covered
  • Bypass policy for admins (if applicable) sits at the top of the block

Grep command: grep -rln "authorizers: \[Ash.Policy.Authorizer\]" lib/ --include="*.ex" Then for each file: check that policies do exists and the actions do entries are all reachable.

Bypass & Disable Detection

grep -rn "authorize?: false" lib/ --include="*.ex"
grep -rn "actor: nil" lib/ --include="*.ex"

Before you install

  • Read the whole file first. Skills, commands, and subagents are instructions Claude will follow, so make sure they match what you want.
  • Check which tools, scripts, or MCP servers it uses. Local servers and scripts run with your permissions.
  • Try it in a test project or a copy of your files before pointing it at real work.
  • Pin the version you tested, and review changes before updating.
  • Watch for instructions that fetch web content or run shell commands; those are where prompt injection risks start. See our prompt injection guide.

FAQ

What is Ash Policy Reviewer?

Ash Policy Reviewer is a subagent for Claude Code and Claude Cowork from the oliver-kriska/claude-elixir-phoenix repository on GitHub. Ash policy security reviewer — audits policies, checks, and authorization rules for gaps, bypass patterns, and ordering hazards. Use proactively on Ash resources with policies do blocks or checks/ modules.

How do I install Ash Policy Reviewer in Claude Code?

Download ash-policy-reviewer.md from the repository. Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control. Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.

Can I use Ash Policy Reviewer in Claude Cowork?

Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent. Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.

Is Ash Policy Reviewer safe to install?

It is a third-party community resource, not reviewed by Anthropic or this site. Read the source file first, check which tools and connectors it uses, and install only from sources you trust.

Similar resources

Browse all skills, subagents, and plugins →

Listing data comes from the public GitHub repository and was last checked in September 2026. Excerpts are © their authors and shared under MIT. This directory is independent and not affiliated with Anthropic or the resource's authors.