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
- Repository
- oliver-kriska/claude-elixir-phoenix
- 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
- 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.
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.
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:
- First ~8 turns: Grep for policy blocks, check modules, authorize?: false, actor placement
- By turn ~10: Write partial findings — do NOT wait. A partial file beats no file when turns run out.
- Remaining turns: Deepen analysis, add code examples, finalize.
- Default output path if none given: .claude/reviews/ash-policies.md
Iron Laws — Flag All Violations
- 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.
- 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.
- 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:.
- 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.
- 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.
- 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.
- 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.
- 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
- Context Supervisor Compresses multi-agent output into consolidated summaries to prevent context exhaustion. Generic — works for any orchestrator. Use after sub-agents complete and before parent synthesis. Subagent · oliver-kriska/claude-elixir-phoenix
- Catchup Runner Does the catch-up fan-out, impact analysis, and brief assembly for /catchup on Sonnet (cheaper/faster than the caller's session). Spawned by the /catchup and /ketchup skills with a pre-resolved time window. Not user-invoked directly. Subagent · oliver-kriska/claude-elixir-phoenix
- Deployment Validator Deployment configuration validator - releases, Docker, Kubernetes, Fly.io. Use proactively before deploying to production. Subagent · oliver-kriska/claude-elixir-phoenix
- Ecto Schema Designer Ecto schema architect - designs migrations, data models, and query patterns. Use proactively when planning database structure for new features. Subagent · oliver-kriska/claude-elixir-phoenix
- Ash Query Optimizer Ash query optimizer — detects N+1 loads, suggests aggregates over load+Enum, identifies calculation vs load tradeoffs. Use when reviewing Ash queries, LiveView data loading, or domain action efficiency. Subagent · oliver-kriska/claude-elixir-phoenix
- Workflow Verifier Goal-backward verification across three layers (existence, substance, connection) Subagent · catlog22/maestro-flow
- Ash Resource Designer Ash resource architect — designs resources the "Ash Way" with built-in changes, validations, types, and policy checks before hand-rolling. Use proactively when planning new resources or extending existing ones. Subagent · oliver-kriska/claude-elixir-phoenix
- Workflow Roadmapper Creates project roadmap with phased milestones from research and requirements Subagent · catlog22/maestro-flow