From PARC to ARC: Policies Without People
Modern access control thinking has revolved around PARC — Principal, Action, Resource, Context. It’s a tidy acronym: start with a principal (a person, service, or device), define the action they want to take, specify the resource they want to touch, and evaluate policies in a given context. From RBAC to ABAC to ReBAC, the principal — the identity of a subject — has been the starting point for nearly every decision.
But what if we don’t need a principal at all?
In a true capabilities model, the focus shifts from who is asking to what can be done — and it’s a critical evolution for modern enterprises where the identity-centric worldview can’t handle our current AI requirements.
The Trouble with Principals
My recent article Venn of Access Control Taxonomies explains how roles, attributes, and relationships overlap and why RBAC is still around despite decades of attempts to replace it. All these models share a hidden assumption: the authorization engine must know who the requester is. Policies are written around subjects — usernames, group memberships, device IDs. Even when tokens stand in for people, the mental model is the same: resolve identity first, decide second.
That assumption breaks down in several ways:
- Delegation and Agency — AI agents, background jobs, and ephemeral workloads often act on behalf of users — or on behalf of other agents. Who is the “real” principal?
- Over disclosure — The lack of precision and difficulty updating identity data, despite years of work on tools that do “access governance” — frequently leads to people having more capabilities then they should. Hence the acknowledgement that “Zero Standing Priviledge” is preferable, which is sort of a concession that the “identity management” approach has failed.
- Token Explosion — In a multi-issuer world, requests arrive with collections of tokens (access, ID, purpose, verifiable credentials). Each may assert partial truths. Which one defines the principal?
In short, “principal” introduces ambiguity and reduces the expressiveness of policies exactly when we need crisp, deterministic rules.
What is a Capability?
A capability binds a specific action to a specific resource, creating a precise unit of permission. For example, unlock-car and drive-car both involve the same resource (“car”), but they carry very different risk profiles. A capability makes that distinction explicit, and allows different policies for each.
From PARC to ARC
The Cedarling is implementing a new interface where you don’t need to specify the principal. A collection of tokens are presented, and policies are authored to map capabilities to the claims of the tokens and other contextual data (e.g. from a risk assessment module).
- Action — What operation is being attempted? (read, transferFunds, launchAgent)
- Resource — What object is affected? (document::123, account::456)
- Context — What environmental facts matter? (tokens, time of day, transaction risk score, regulatory region)
Notice what’s missing: principal.
In ARC, policies might look like:
permit(
principal,
action in [“download”, “view”],
resource is Photo:1234
) when {
context has tokens.access_token &&
context.tokens.access_token.hasTag("location") &&
context.tokens.access_token.getTag("location").contains("miami")
};The policy doesn’t care whether the caller is Alice, Bob, or a swarm of AI agents. It only cares that a trusted token carries the required claims and that contextual conditions hold true.
This design has several advantages:
- Deterministic Inputs — Multiple issuers and token types can coexist without creating subject ambiguity.
- Least Disclosure — Decisions can be made with minimal personal data, reducing privacy risk.
- Composable Governance — Capabilities can be delegated, revoked, or combined without rewriting identity-centric rules.
Rethinking Enterprise Catalogs
My recent article proposes a TBAC Registry — an enterprise-wide catalog of capabilities and tokens. Instead of mapping users to roles, organizations maintain a registry of the capabilities their systems recognize and the tokens that provide the required evidence to allow. Developers publish capabilities the way APIs publish endpoints. Security teams analyze these capabilities and can centrally manage risk.
This registry becomes the backbone for dynamic, multi-issuer authorization: microservices, SaaS platforms, and AI agents all speak the same language of capabilities, not principals.
The Future of Access Control
Moving from PARC to ARC isn’t merely a syntax change. It’s a mental shift:
Stop asking “Who are you?” Start asking “Do you present a valid credential to do this, here, now?”
In a world of federated identities, transient agents, and privacy mandates, ARC offers a cleaner, safer path. By dropping the principal, we gain a model that is:
- Scalable — Works across domains and issuers.
- Analyzable — Policies are static artifacts, easy to test and reason about.
- Privacy-preserving — Decisions require only the evidence of capability.
The ARC model isn’t an incremental improvement; it’s about taking a different door to secure the enterprise. It’s hard to detox after years of enterprise thinking that identity is the center, or identity is the perimeter, and I wrote a book with that title… so it took me a long time too.
Conclusion
Roles won’t disappear, and principals will still matter. But for real-time authorization, the future belongs to capabilities. By embracing ARC and leaving the principal behind, enterprises can design systems that are both simpler and more secure — exactly what the next generation of identity and access demands.
