Action Policy for Ruby and Rails Authorization

Action Policy's Resource-Centric Authorization Model

Action Policy addresses authorization decisions in Ruby applications, particularly Rails controllers and views. It does not perform authentication or validate object attributes. Its role is to decide whether the current user may perform an action against a particular record, such as updating that user's own post or allowing an administrator to update any post.

The framework organizes these decisions in resource-specific policy classes. `PostPolicy`, for example, defines `show?` and `update?` methods rather than placing conditional checks throughout controllers. Each rule has a named location tied to the protected resource. Reviewing access to posts therefore starts with the policy for posts instead of requiring a search through every controller path that changes them.

The intended audience is a Ruby or Rails team that wants authorization logic separated from request handling while retaining ordinary Ruby methods. The README also links to non-Rails documentation for adding `authorize!` to a Ruby project. However, it does not show that integration in its installation and usage sections, so its setup and context handling cannot be inferred from the main example.

How Post Policy Rules Receive Context

A policy inherits from `ApplicationPolicy`, which itself inherits from `ActionPolicy::Base`. The README presents `ApplicationPolicy` as the place for global configuration shared by resource policies. That supports behavior common to the application, although the example does not define a shared method or a named configuration option.

Inside a resource policy, rules access two contextual objects. The documentation identifies `user` as the performing subject and `record` as the target object. In `PostPolicy#update?`, `user.admin?` permits administrators, while `user.id == record.user_id` limits other users to posts associated with their account. The method returns the authorization result directly.

This design keeps permission logic executable as Ruby. Rules can depend on domain attributes and methods available on the subject and record. The trade-off is that authorization remains distributed across ordinary policy methods. A large policy set still needs consistent naming, ownership, and tests. The README does not document a declarative condition language or a configuration-only rule format, so the documented approach centers on explicit Ruby code.

Installing Action Policy and Generating Policies

The README instructs users to add `action_policy` to the application's `Gemfile`. RubyGems dependencies are then installed through Bundler.

gem "action_policy"

Add that entry to the application's dependency list, then install the bundle. The documented command does not pin a version, so resolution depends on the application's dependency constraints and compatible releases available to Bundler.

bundle install

For a Rails application, the project provides an installer generator for the base policy class:

rails generate action_policy:install

This generates the application-specific `ApplicationPolicy`, which the README says can contain global configuration. The command is Rails-specific and is not presented as a plain Ruby installer.

A resource policy can be generated with the resource name:

rails generate action_policy:policy Post

The project also documents an explicit alternative parent:

rails generate action_policy:policy Post --parent=BasePolicy

That option makes the generated policy inherit from `BasePolicy`. The README does not explain whether the installer changes an existing `ApplicationPolicy`, so an existing definition should be reviewed before running the generator over it.

Enforcing Post Updates with authorize!

Authorization is applied after the controller loads the post and before it attempts the update. The README's `PostsController` example calls `authorize! @post`, then proceeds to `@post.update(post_params)`.

class PostsController < ApplicationController
  def update
    @post = Post.find(params[:id])
    authorize! @post

    if @post.update(post_params)
      redirect_to @post
    else
      render :edit
    end
  end
end

The example does not pass an action argument to `authorize!`, while the policy defines `update?`. The main README does not explain action inference in detail, so the versioned documentation should be checked before relying on omitted actions elsewhere.

`authorize!` uses exceptions for enforcement. According to the README, it does nothing beyond continuing when the matching rule returns `true`. When authorization fails, it raises `ActionPolicy::Unauthorized`. That behavior suits mutation paths where continuing would perform an unauthorized operation and the application handles the exception at an appropriate boundary.

The ordering also matters. `Post.find(params[:id])` runs first, so record lookup occurs before policy enforcement. The example does not document exception rendering, response status codes, logging, or customized denial responses. Those application-level behaviors require separate configuration or rescue behavior outside the shown policy.

Conditional Links with allowed_to? in Rails Views

Action Policy also provides `allowed_to?`, which returns `true` or `false`. The README presents it for conditional interface content, including links that should appear only when the current user may edit a post.

<% @posts.each do |post| %>
  <li><%= post.title %>
    <% if allowed_to?(:edit?, post) %>
      <%= link_to post, "Edit" %>
    <% end %>
  </li>
<% end %>

This example passes an explicit action symbol, `:edit?`, and the target post. Unlike `authorize!`, the method does not use an exception to represent a false result. A false value omits the edit link, making the method suitable for a presentation decision.

A hidden link is not enforcement. The update controller must still deny an unauthorized request before accepting changes. Using only `allowed_to?` for a mutation would leave the controller responsible for access control. The documented example instead pairs the view check with `authorize!` in the mutation path.

The README does not identify the context source used by `allowed_to?`, such as a current-user helper or a Rails view helper. It also does not describe handling for an unknown action. Application tests should therefore cover both interface visibility and server-side enforcement.

Pundit Comparison and Non-Rails Boundaries

The README names Pundit as an alternative and says that Action Policy uses resource-specific policy classes "just like Pundit." The README explicitly compares Action Policy's resource-specific policy classes with Pundit.

The main README links to a separate guide for comparing Action Policy with existing solutions, but does not reproduce its arguments. It would therefore be inaccurate to claim a deeper behavioral advantage. Based on the documented interface, Action Policy exposes `authorize!`, which raises `ActionPolicy::Unauthorized` after denial, and `allowed_to?`, which returns a Boolean. The README does not describe equivalent Pundit interfaces, so their behavior should not be compared without Pundit's own documentation.

Action Policy is also a poor fit when the requirement is specifically configuration-only authorization with no Ruby policy methods. Its documented core is a class per resource with predicate methods. It may fit a plain Ruby service, but the linked non-Rails guide must supply the context and integration details absent from the main README.

Separate repositories provide integrations for GraphQL Ruby and Graphiti. The README names `action_policy-graphql` and `action_policy-graphiti`, but does not document their installation, release compatibility, or ownership. Those packages must be reviewed directly rather than assumed to be included with the main gem.

Release Cadence, Repository Checks, and MIT Terms

The repository is not archived. Its last push was on 2026-09-03, which is the newest maintenance fact available from the repository metadata. The latest listed release is `v0.7.0`, dated 2024-06-20. Earlier listed releases are `v0.6.0` from 2021-09-02 and `v0.5.0` from 2020-09-29.

Repository activity and release age are separate signals. A recent push does not establish a new release, compatibility with a particular Ruby or Rails version, or the maintenance status of optional integration gems. The listed gemspec file can provide dependency information for a selected release, but the README does not enumerate supported Ruby and Rails versions.

The repository includes a `Makefile` with test, lint, and release targets. Its default target runs tests, while `lint` invokes RuboCop. The release target depends on testing and linting, then invokes `gem release -t`. These are repository-maintainer workflows rather than installation steps for an application user.

The gem uses the MIT License. The README describes it as open source under those terms. An organization should review `LICENSE.txt` for its notice and compliance process. The main gem's license also does not automatically settle the terms of the separately listed GraphQL Ruby and Graphiti integrations.

Editorial conclusion

Adopt Action Policy when a Ruby or Rails application can keep authorization decisions in resource-specific policy classes and the team values explicit rules with both exception-based and boolean checks. Do not select it for non-Rails service authorization or GraphQL use without checking the integration path first. The main README lists separate integrations for those contexts rather than documenting them here. Before adoption, verify that `ApplicationPolicy`, generated resource policies, controller calls to `authorize!`, and view checks with `allowed_to?` fit the application's structure.

Frequently asked questions

Official sources

1. License: MIT
2. palkan/action_policy on GitHub
3. Project website
4. README
5. Releases