Activity-Centric Access Control (ACAC)
- Activity-Centric Access Control (ACAC) is a paradigm that bases access decisions on dynamic, state-driven activities rather than static roles or attributes.
- It enforces policies by evaluating an activity’s state, obligations, environmental conditions, and dependencies across various lifecycle phases.
- ACAC implementations achieve fine-grained, runtime authorization with minimal overhead while addressing challenges like dependency conflicts and policy complexity.
Activity-Centric Access Control (ACAC) defines an authorization paradigm in which policy decisions and runtime enforcement are driven by the state and semantics of ongoing, interdependent activities, rather than static roles, user attributes, or per-object operations. ACAC is especially suited for highly dynamic, smart collaborative environments—such as autonomous agent platforms, IoT deployments, or cyber-physical systems—where devices, agents, or users perform long-lived, compositional tasks whose correctness, safety, and security depend on explicit consideration of runtime state, dependencies, obligations, environmental context, and mutability of controlled activities (Cai et al., 30 Oct 2025, Fleming et al., 13 Oct 2025, Gupta et al., 2021, Mawla et al., 2024, Mawla et al., 2023, Mawla et al., 2022).
1. Core Concepts and Formal Structure
In ACAC, the primary abstraction is the “activity,” defined as a temporally extended function or task performed by a subject (user, agent, device) on an object (device, application, data item), parameterized by a mutable state. Activities may be atomic or composite, persisting over lifecycles that traverse multiple states such as Dormant, Requested, Active, Suspended, Completed, and Aborted (Mawla et al., 2022). ACAC policies make access decisions based on an activity’s current state, declared intent, pre- and ongoing obligations, environmental/attribute conditions, and—crucially—explicit dependencies among multiple concurrent activities.
Formally, an activity can be modeled as a tuple:
where is the source/subject, the object, the operation or intent (e.g., “spray crops”), and the current internal state. State transitions are determined by events and are only permitted if all relevant decision parameters are satisfied.
The ACAC decision function evaluates four orthogonal parameters (Mawla et al., 2022, Mawla et al., 2023):
- A: Authorization—baseline permissions and policies (e.g. role, attribute-based).
- B: Obligations—actions that must be performed before, during, or after the activity.
- C: Conditions—temporal, environmental, or resource constraints.
- D: Dependencies—requirements relating to the state of other, potentially chained, activities.
A requested transition is permitted iff all predicates yield true:
2. Dependency Modeling and Chain Resolution
A defining innovation of ACAC is explicit support for mutable, multi-phase dependency relations among activities. Each activity may declare dependency requirements at multiple phases: pre- (before start), ongoing (during execution), and post- (after completion). Dependencies are formally represented as tuples:
where encodes that, for activity in phase (pre, ongoing, post), activity must be in state (Mawla et al., 2024, Mawla et al., 2023).
Chained dependencies are resolved via recursive update procedures which traverse dependency graphs. Key enforcement steps include detecting unsatisfied dependencies, checking mutability, and, if possible, updating the state of dependent activities (directly or transitively) before permitting or continuing an activity. Conflicts (e.g., diverging desired states from different dependency chains) are handled via locking and conflict detection mechanisms (Mawla et al., 2023).
The life-cycle and dependency enforcement process, as implemented in , with phases and provisional updates, ensures consistent, race-free state management and semantic correctness (Mawla et al., 2024).
3. Policy Specification, Synthesis, and Enforcement
ACAC policy specification frameworks encode these dependencies and stateful authorization criteria using both domain-specific and general-purpose languages. Notable realizations include:
- XACML_AD, an extension of the XACML standard, enables specification of dependency-aware policies for activities, introducing constructs for provisional updates, mutability checks, and chain resolution (Mawla et al., 2024).
- Template-based task policies, as used in AgentSentry, derive minimal, temporary privilege allocations from high-level user or agent intent (task context), synthesizing allow/deny rules covering only those resource-operation pairs needed for the task at hand (Cai et al., 30 Oct 2025).
Runtime enforcement in all ACAC instantiations features active, continuous monitoring by Policy Enforcement Points (PEP) and Policy Decision Points (PDP). For example, AgentSentry automatically generates and revokes fine-grained policies per AI agent task, strictly bounding privilege lifetimes and scopes. Similarly, ACAC_D models implement recursive, depth-first consistency-checking across dependency chains before and during activity execution (Mawla et al., 2023, Mawla et al., 2024).
4. Task- and Risk-Centric Extensions: ACAC in Agentic Systems
Task-Based Access Control (TBAC) and its agentic extensions are specializations of ACAC where tasks (goal-oriented activities) form the basis for permission assignment. In frameworks such as AgentSentry and LLM-Judged TBAC:
- Policies are dynamically synthesized per task context, granting the minimal requisite set of privileges for the duration of the task and revoked upon completion (Cai et al., 30 Oct 2025, Fleming et al., 13 Oct 2025).
- Advanced mechanisms consider risk and epistemic uncertainty. The LLM-Judged TBAC model incorporates both external risk metrics (e.g., resource or API risk) and internal policy-generation uncertainty (e.g., LLM confidence via ensemble or MC-dropout metrics). If risk or uncertainty thresholds are breached, requests are escalated to human review or subject to stricter constraints (Fleming et al., 13 Oct 2025).
This multi-dimensional, just-in-time access management enforces least privilege at the task level and prevents over-privileging endemic in legacy, static permission regimes (e.g., Android apps’ permanent grants) (Cai et al., 30 Oct 2025, Fleming et al., 13 Oct 2025).
5. Comparison to Traditional Access Control Models
ACAC subsumes and generalizes classical models such as RBAC, ABAC, CapBAC, and UCON:
- RBAC/ABAC/CapBAC: Ground decision on static subject, object, role, or attribute relationships and do not natively support runtime, stateful enforcement or cross-device activity dependencies (Gupta et al., 2021, Mawla et al., 2022).
- UCON: Incorporates obligations and mutability but does not model long-lived, interdependent device activities as first-class objects.
- ACAC: Introduces activities as the principal abstraction, enabling continuous, cross-device, and context-sensitive enforcement of policies, including dependency and mutability-driven updates, obligations, and environment constraints (Mawla et al., 2022, Mawla et al., 2023).
A summary table illustrates the key distinctions:
| Model | Decision Parameters | Granularity | Runtime Evaluation |
|---|---|---|---|
| RBAC | roles, perms | subject-object | No |
| ABAC | attributes, policies | subject-object | No |
| CapBAC | capability tokens | subject-object | No |
| ACAC | A,B,C,D,mutability | activity-centric | Yes |
6. Performance, Scalability, and Limitations
Evaluations of ACAC frameworks demonstrate practical efficiency:
- AgentSentry on Android adds a mean 3 ms per UI event, incurring <2% end-to-end overhead; policy mediation completely suppresses instruction injection while allowing legitimate task completion (Cai et al., 30 Oct 2025).
- policy enforcement for activity dependency management achieves 10–12 ms per request, maintaining sub-100 ms performance in chained, multi-activity scenarios (Mawla et al., 2024).
- Python-based prototypes for ACAC_D report chain resolution (10–40 requests) in 30–200 ms ranges (Mawla et al., 2023).
Significant limitations and challenges include:
- Policy complexity and administrative burden in large-scale, federated settings with many interdependent activities.
- Need for robust, possibly AI-assisted, template/intention classification to avoid under- or over-granting privileges (Cai et al., 30 Oct 2025).
- Ensuring safety, absence of conflicting state transitions, and correctness in face of deep dependency chains (Mawla et al., 2023, Mawla et al., 2024).
- Open questions around efficient distributed enforcement (e.g., in edge-cloud IoT) and formal verification of policy coverage.
7. Future Directions and Research Agenda
Current research highlights several axes for further development:
- Policy Languages & Meta-Models: Formalization of ACAC’s algebraic/meta-models (analogous to RBAC/UCON standards), policy composition tools, and high-level DSLs (Gupta et al., 2021, Mawla et al., 2024).
- Automated and AI-Driven Synthesis: Adaptive policy generation, intent extraction and risk/uncertainty calculation using learning techniques (Fleming et al., 13 Oct 2025, Cai et al., 30 Oct 2025).
- Distributed Enforcement: Distributed, resilient architectures supporting continuous, low-latency enforcement over dynamic, resource-constrained devices (Gupta et al., 2021, Mawla et al., 2023).
- Administrative and Safety Models: Extensions for rule delegation, separation of duty, and automated analysis tools for deadlock/conflict/liveness (Mawla et al., 2023).
- Integration with Zero-Trust: Embedding zero-trust principles (continuous verification, least privilege, breach containment) as core ACAC properties (Mawla et al., 2022).
Rigorous real-world deployments, policy composition frameworks, and formal verification techniques remain active areas of investigation. The ACAC paradigm is positioned as the foundational access control model for next-generation, agentic, dynamic, and collaborative ecosystems, enabling both effective least-privilege and intent-aligned security at scale.