Capabilities = Risk: rethinking modern enterprise access control

Every API deployed, every mobile app launched, every microservice exposed, every MCP service hosted—each new interface adds new enterprise digital capabilities--and that's a good thing. But with each new capability, there is risk--the attack surface grows.

For decades, enterprises have centered their access decisions around identity: typically not on specific identities, but on the roles, groups, or attributes of "users" (i.e. humans). This makes sense if you think governance = holding people accountable. But for many enterprises, a risk-oriented approach is more efficient for prioritizing investments.

If we think of our enterprise as a building, is it better to calculate the risk by analyzing the people in the building, or the contents of the rooms? This article posits that securing rooms is a better approach to understand risk. And we don't have to sacrifice holding people (or software) accountable.

It’s time to shift to a capabilities-centric approach to access control. But what tools would we need to accomplish this transition?

Why Enterprises Need Capabilities-Centric Access Control

1. More Accurate Risk Mapping Capabilities are directly correlated to business risk. For example, a capability to read a support ticket poses far less risk than a capability to refund a customer or alter a compliance status. Modeling access around capabilities allows risk managers to quantify risk in concrete terms—rather than by trying to imagine the risk of assigning people roles like “Admin” or “Level 3 Support.”
2. Greater Policy Reusability and Composability Capabilities can be reused across services, APIs, and channels. A policy that governs the “delete-user-account” capability should apply whether it’s triggered via the admin dashboard or a backend system. That unification is only possible when policies are capability-scoped, not channel- or identity-scoped.
3. Better Fit for Regulated Environments Regulatory regimes increasingly demand purpose-limited access, least privilege, and context-sensitive decision-making. With a capabilities-first model, organizations can directly enforce these requirements with fine granularity and measurable outcomes.
4. Aligns with Modern Application Development In a microservices and API-first world, development teams are effectively shipping capabilities with every deployment. These capabilities should come with their own access policies, version histories, and enforcement logic—not be retroactively patched with centralized identity plumbing.

What Tools Are Needed for Capabilities-Centric Access?

The shift to a capabilities-centric model demands new types of infrastructure. This isn’t just a new IAM mindset—it’s a new set of control planes.

1. Capability Registry and Discovery

Enterprises need a central inventory of capabilities: what they are, where they live, what policies govern them, and who owns them. This registry should be queryable, human-readable, and integrated into the software development lifecycle ("SDLC"). Developers should be able to register new capabilities as part of their continuous development workflow.

2. Policy Authoring and Governance

Tools are needed to author, test, and validate policies that control capabilities. These tools should:

• Offer templates for common policies to encourage re-usability
• Provide prompt-driven development of policies to customize templates for specific business requirements
• Offer publication mechanisms--how are policies and schema reviewed by the business and approved for consumption by enteprise systems?

Critically, policies must travel with the code—policies should be versioned with the application that exposes the capability.

3. Policy Distribution and Versioning

Just like application binaries, policies should be distributed through controlled pipelines. A policy should have lifecycle management: draft → validated → deployed → retired. Tooling should ensure that no capability is exposed without an attached policy, and that version mismatches don’t cause inconsistencies in enforcement.

4. Context-Aware Policy Evaluation

Capabilities should be governed not just by who is calling them, but by when, why, and under what conditions. Policies should be able to inspect:

• JWT token contents (claims, scopes) to identify software, humans and platforms--which are still important input to policies.
• Request context (network address, time of day, geolocation, fraud scores...)
• Resource (i.e. "asset") purpose restrictions and obligations

Policy evaluation needs to be fast and determistic--given the same input (defined according to a consistent schema), we should always get the same policy decision. And policy execution must be safe--the policy evaluation engine should never fail.

5. Decision Logging and Audit

Every policy decision must be logged with full fidelity. Enterprises should be able to ask questions like:

• What capabilities were exercised in the last four hours?
• Which were denied?
• Who tried to use a sensitive capability outside their job function?

These logs are essential for breach investigations, compliance audits, and AI-assisted anomaly detection.

Why the Time Is Right

Several industry trends are converging to make capabilities-centric access not only viable, but urgent:

• API-first design: Modern systems expose everything via APIs. APIs are units of capability.
• Zero trust architectures: “Never trust, always verify” mandates fine-grain control and contextual evaluation.
• Compliance pressure: Regulations like GDPR, HIPAA, and CCPA are requiring stricter controls on what data is used and for what purpose—something that role-based models struggle to enforce.
• Workforce decentralization: With distributed teams, contractors, AI agents, and bots, identity becomes increasingly hard to model—but capabilities remain fixed and known.

Closing Thoughts

Capabilities are the real atomic units of enterprise risk. Shifting access control from identities to capabilities represents a profound evolution in how we govern systems. It brings security decisions closer to where risk originates—in the software itself—and enables enterprises to respond faster, govern smarter, and comply with confidence.

This isn’t just an IAM upgrade. It’s a paradigm shift that aligns security architecture with modern development practices and real-world business risk.

Enterprises that embrace capabilities-centric access will not only reduce exposure—they’ll gain the agility and clarity needed to navigate the next decade of digital transformation.