Permission Systems & Safety Boundary Enforcement

• Permission System and Safety Boundary Enforcement is a mechanism that defines and restricts which principals can perform specific operations on resources using formal models and explicit tokens.
• It integrates compile-time enforcement, dynamic runtime control, and cryptographic protocols to prevent accidental or malicious privilege escalation.
• Applications span OSes, distributed protocols, serverless platforms, and AI systems, utilizing techniques like capability-based access, proxy interception, and formal verification to ensure robust security.

A permission system is a formal or engineered mechanism that mediates which principals (subjects, code, processes, agents, or modules) may perform which operations over which resources, under what conditions, in a computing system. Safety boundary enforcement is the set of guarantees that restrict code (or agents) to only those operations for which permission has explicitly been granted, preventing both accidental and malicious privilege escalation, resource abuse, and violation of isolation properties. Permission systems and safety boundary enforcement occur at all layers of modern software infrastructure: programming language type systems, OS APIs, distributed protocols, serverless platforms, multi-agent AI control frameworks, and web applications.

1. Formal Models: Permission Matrices, Capabilities, and Policy Enforcement

The foundational model for permission systems is the access control matrix $M$, which maps $(\text{subject}, \text{object})$ pairs to a set of rights:

$M: S \times O \to 2^{R}$

where $S$ is the set of subjects, $O$ of objects (resources/APIs), and $R$ of rights (such as call, read, write, exec). Real-world systems instantiate $S$ variously: OS processes, functions, code modules, or user tasks.

Capability-based approaches instantiate matrix cells as unforgeable tokens (capabilities) handed to subjects; to perform an action, the subject must present the token at use time. This principle frames recent permission system designs:

• PermRust encodes each library-level permission as a zero-sized Rust type. Only trusted “anchors” (standard libraries) may mint permission tokens (unforgeable due to Rust’s visibility rules), and the type system ensures only functions passed the appropriate token can invoke I/O or other privileged operations. The access matrix becomes $M: F \times O \to \{\emptyset, \{\text{call}\}\}$ where $F$ are functions and $O$ are I/O entry points (Gehring et al., 13 Jun 2025).

Other systems, such as HCAP, model the policy as security automata or finite state machines, where permissions may be exercised only following certain sequences (enforcing "history-based" constraints) (Tandon et al., 2018). Distributed authorization systems extend this, cryptographically encoding permission sequences that must be honored even across multiple servers (Li et al., 2022).

Enforcement is realized by embedding the matrix/capability into language type systems, runtime call wrappers, container sandboxes, or OS kernel primitives. The ideal property is a strictly local check: an action is permitted if and only if the appropriate token, capability, or matching policy entry is present and valid.

2. In-language Enforcement: Type Systems, Static Analysis, and Zero-Cost Abstractions

Several recent permission systems achieve fine-grained, compile- or load-time enforcement by integrating permissions into the language substrate.

• PermRust achieves per-library safety boundaries by embedding tokens in function signatures. Unforgeability is guaranteed by private constructors and Rust’s module system, while propagation of tokens along the call graph ensures explicit privilege passing. The compiler enforces that only code with explicit access may use I/O APIs (Gehring et al., 13 Jun 2025).
• Permission-dependent type systems further embed permission requirements into information-flow types. For instance, base types are functions from permission sets to security levels: $(\text{subject}, \text{object})$0, for $(\text{subject}, \text{object})$1 the permission set and $(\text{subject}, \text{object})$2 a security lattice. Special merge operators encode cases such as conditional flows based on dynamic permission checks (Chen et al., 2017).
• Node.js Light-permission: By wrapping require and property access at module load time, the Node.js lightweight permission system ensures that no package can import or access resources beyond its declared privilege set. Sandboxing is coarse-grained (per-package), but sufficient to prevent privilege escalation between libraries (Ferreira et al., 2021).
• Serverless function analysis (ALPS): ALPS extracts the minimal permission set needed by a function via context-sensitive static analysis of source code and LLM-based policy generation, inserts enforcement hooks into the function code for runtime checking, and generates vendor-specific IAM policies (Shin et al., 26 Mar 2026).

Critically, these approaches provide zero-cost abstractions in the sense established by PermRust: tokens are zero-sized (costless at runtime), checks are resolved at compile or load time, and no runtime checks need to execute in production binaries, yielding no performance penalty beyond marginal compile-time increases.

3. Dynamic and Runtime Control: Interception, Task-Scoped Policies, and Fine-Grained Mediation

Not all permission boundaries can be resolved statically. Many systems require dynamic, task-, step-, or action-scoped policies:

• AgentSentry: For AI and GUI automation agents, persistent or broad permissions enable instruction injection attacks. AgentSentry dynamically generates a task-scoped policy $(\text{subject}, \text{object})$3 for every user-authorized task $(\text{subject}, \text{object})$4, specifying for each action whether it is allowed or denied, with default-deny as the baseline. Enforcement intercepts every operation at the Policy Enforcement Point (PEP), querying the Policy Decision Point (PDP) to decide allow or deny according to $(\text{subject}, \text{object})$5. Policies are scoped and revoked at task end, providing a minimal window of privilege and significantly constraining the attack surface (Cai et al., 30 Oct 2025). Legitimate and malicious actions are shown to be precisely separated by this dynamic mediation.
• Granite: For authoritative workflows (GitHub Actions), fine-grained runtime mediation is achieved by proxy-based network interception; all outgoing HTTP(S) requests made by actions are dynamically checked against per-step (not just per-job) policies mapped to API scope and required access level, providing least-privilege enforcement and preventing supply-chain permission misuse (Moazen et al., 12 Dec 2025).
• Claude Code auto mode: AI coding agent permission gates distinguish between safe (read-only), in-project file edits (assumed “reviewable”), and high-risk operations (shell, external API) which are subject to ML-gated classification. The safety boundary—i.e., the transition from trusted to classified action—is shown to have empirical coverage gaps, with significant risks when agents achieve privileged state modification via unclassified channels (e.g., file edits) (Ji et al., 4 Apr 2026).
• AgentSpec: For LLM-driven agents, AgentSpec interposes at runtime between plan and execution. Permission and safety boundaries are enforced via rules with explicit triggers, predicates, and enforcement actions defined in a DSL, covering both code and embodied or autonomous agents. The framework guarantees—empirically tested—high precision, recall, and compliance at millisecond-level overhead (Wang et al., 24 Mar 2025).

4. Distributed and Cryptographic Protocols: Capability Transfer, Context, and Formal Guarantees

Distributed systems employ cryptographically encoded permission tokens to enforce safety boundaries across trust domains:

• HCAP: In IoT, history-based capability systems cryptographically encode finite automata into distributed tickets (capabilities), which specify precisely which permissions a client may exercise and in which sequence, supporting revocation, update, and baton passing. Resource servers enforce the automaton locally, without needing to know the global policy, and formal invariants (the effective automaton state) provably prevent privilege escalation or replay attacks (Tandon et al., 2018).
• Context-aware permission sequences: Complex cross-domain workflows are enforced by encoding the entire permission sequence (and per-step contextual predicates) into the master capability, with resource servers and environmental oracles checking order and context at each access. The safety property—the distributed protocol simulates a centralized, strictly sequential monitor—is established by a formal induction (Li et al., 2022).
• Permission Voucher Protocol: In high-assurance environments, formal models and symbolic verification (e.g., Tamarin Prover) are employed to evaluate and prove authentication, mutual authentication, replay-resistance, and confidentiality as enforcing cryptographic safety boundaries. Security lemmas directly encode required event order and single-use constraints (Reaz et al., 2024).

5. Reference Architectures: Operating Systems, Mobile Platforms, and Web Applications

Large-scale OS and application platforms implement multi-layered permission and boundary-enforcement architectures:

• Android Permission System: Android composes static manifest declarations, package manager mappings, Binder IPC-level checks, and Linux kernel/Selinux enforcement, forming a multi-tier trust pipeline. Extensions include context-dependent (foregroundApp, etc.) and temporal (time-limited) grants, all formally modeled as state machines with invariants proved via model-checking (Sayyadabdi, 2022).
• Feature-based and Multi-level models: To modularize and reduce over-privilege, Android’s feature-based permission model auto-generates permission requests strictly corresponding to features, minimizing attack surface. Multi-level (MLS) dynamic frameworks combine kernel and framework hooks with machine-enforced policy databases (Birendra, 2016, Luo et al., 2017).
• PWAs and browser permissions: Progressive Web Application permission boundaries are inconsistently scoped (origin vs. app-specific), leading to formal leakage conditions and practical attacks. Proposed unified models introduce app-centric scoping and manifest-declared permissions to rectify safety boundary ambiguities (Wang et al., 16 Sep 2025).

6. Security Guarantees, Formal Verification, and Empirical Evaluation

Many modern systems explicitly state and, where feasible, formally verify their safety properties:

• PermRust: The safety invariants—permission-respecting and privilege-escalation-free call graphs—are checked at compile time, with unforgeability, enforced by the type system, ensuring zero runtime risk (Gehring et al., 13 Jun 2025).
• HCAP, Permission Voucher Protocols: Machine-checked theorems prove that no client can exercise permissions out-of-sequence or bypass context constraints, even under adversarial attempts (Tandon et al., 2018, Reaz et al., 2024, Li et al., 2022).
• Empirical analysis: Systems such as AgentSentry, ALPS, Granite, and Claude Code auto mode report real-world evaluations of attack block rates, policy-generation coverage, overhead, and false positive/negative rates (Cai et al., 30 Oct 2025, Shin et al., 26 Mar 2026, Moazen et al., 12 Dec 2025, Ji et al., 4 Apr 2026).

The following table summarizes selected key systems, their enforcement granularity, and main guarantees.

System	Granularity	Safety Property/Guarantee
PermRust (Gehring et al., 13 Jun 2025)	Function/library	Compile-time token enforcement, no-priv.
AgentSentry (Cai et al., 30 Oct 2025)	Task/action	Task-scoped, runtime PEP/PDP, zero-preemption
ALPS (Shin et al., 26 Mar 2026)	Serverless/function	Static analysis + runtime, least-privilege
Granite (Moazen et al., 12 Dec 2025)	CI step/API-call	Proxy-intercepted, step-level policies
AgentSpec (Wang et al., 24 Mar 2025)	Agent action/state	DSL-ruled runtime guard, high compliance
Capability-seq (Li et al., 2022)	Distributed/service	Sequence+context, simulation safety proof

7. Implications, Limitations, and Future Directions

Permission system research is converging on principled, least-privilege, minimal-grant, and context-aware models supported by either formal semantics or dynamic runtime enforcement. Outstanding challenges include:

• Automating policy/minimal permission inference at massive scale and over evolving APIs (Shin et al., 26 Mar 2026, Cai et al., 30 Oct 2025).
• Ensuring accuracy of task or feature inference to match human intent, as evidenced by the limitations in reasoning-blind or ambiguity-sensitive gates (Cai et al., 30 Oct 2025, Ji et al., 4 Apr 2026).
• Addressing cross-layer or inter-language gaps (e.g., between managed and native code bases (Li et al., 2021)).
• Extending formal verification of safety boundary theorems beyond crypto protocols to the full stack, including dynamic, machine-learning–driven policies (Reaz et al., 2024, Wang et al., 24 Mar 2025).
• Reconciling usability, auditability, and security trade-offs in end-user environments, especially for web and AI-agent systems (Wang et al., 16 Sep 2025, Liu et al., 14 Apr 2026).

These developments delineate the future research agenda on permission system design, formalization, boundary enforcement, and empirical assessment across contemporary software and agentic platforms.