AI agents operate with all-or-nothing permissions. AC4A (arXiv:2603.20933) proposes giving them Unix-style access control instead.
The current model: an agent either has full access to an API or no access at all. It can read every email or no emails. It can make any API call or none. There's no middle ground — no equivalent of read-but-not-write, or access-this-directory-but-not-that-one.
AC4A introduces resource hierarchies. An application defines its resources as structured trees — users, documents, endpoints, pages. Permissions specify which branches of the tree the agent can access and what operations it can perform on each. The system computes required permissions at runtime for each resource access request.
The Unix analogy is deliberate. File systems solved this problem decades ago: read/write/execute permissions on files and directories, with ownership and groups to scale. The insight is that the same pattern applies to any resource an agent might access — API endpoints, web page elements, database tables, file systems. The resource is always hierarchical. The permission is always a subset of possible operations on that hierarchy.
What makes this more than access control theory applied to a new domain is the practical gap it identifies. Every major agent framework — LangChain, AutoGPT, CrewAI — operates in all-or-nothing mode. The agent that can book a flight can also cancel all flights. The agent that can read your documents can also delete them. The frameworks don't lack the concept of permissions. They lack the infrastructure for expressing and enforcing them.
The structural observation: the all-or-nothing pattern isn't a design choice. It's a default that persists because fine-grained access control requires knowing the resource structure in advance, and agent use cases are too varied for any single resource model. AC4A's contribution is making the resource model per-application rather than universal.