SECDISPATCH / RATS Sripad Internet-Draft AegisFS Project Intended status: Informational 28 August 2026 Expires: 1 March 2027 AegisFS: AI-Driven Programmable Secure File Runtime and Intelligent Workspace Architecture with Octal OpCode Processing and Policy-Driven Language Architecture draft-aegisfs-secdispatch-rats-00 Abstract This document specifies AegisFS, a programmable secure file and folder runtime that transforms ordinary filesystem objects into intelligent, policy-driven, state-aware, execution-aware, and behavior-aware security objects. This draft introduces two novel technical contributions: 1. The Octal to OpCode (OtO) Framework: a real-time processing model wherein all file operations, state transitions, and intent declarations are compiled into a structured 9-bit octal instruction set enabling hardware-accelerated, microsecond- latency policy enforcement in the runtime kernel. 2. The Aegis Policy Language (APL): a next-generation, policy-driven programming architecture featuring custom-defined keywords, strongly typed identifiers, and syntax-based operation analysis where the policy definition IS the executable architecture. An operation that cannot be expressed in valid APL syntax cannot produce a valid OtO opcode and therefore cannot execute. This document is submitted for consideration by the SECDISPATCH and RATS Working Groups of the IETF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Sripad Expires 1 March 2027 [Page 1] Internet-Draft AegisFS Architecture August 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation and Problem Statement . . . . . . . . . . . . 4 1.2. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . 4 1.3. Working Group Dispatch Rationale . . . . . . . . . . . . 5 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 3. High-Level Architecture . . . . . . . . . . . . . . . . . . . 6 3.1. System Layers . . . . . . . . . . . . . . . . . . . . . . 6 3.2. The Intelligent File Object Model . . . . . . . . . . . . 7 3.3. Workspace Folder Structure . . . . . . . . . . . . . . . 7 4. Octal to OpCode (OtO) Framework . . . . . . . . . . . . . . . 8 4.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 8 4.2. OpCode Bit Field Structure . . . . . . . . . . . . . . . 9 4.3. Domain Codes (X Field) . . . . . . . . . . . . . . . . . 9 4.4. Object State Codes (Y Field) . . . . . . . . . . . . . . 10 4.5. Operation Intent Codes (Z Field) . . . . . . . . . . . . 10 4.6. OpCode Encoding Examples . . . . . . . . . . . . . . . . 11 4.7. Real-Time Execution Pipeline . . . . . . . . . . . . . . 11 4.8. OpCode Fault Handling . . . . . . . . . . . . . . . . . . 12 5. Aegis Policy Language (APL) — Policy-Driven Architecture . . 12 5.1. Language Design Philosophy . . . . . . . . . . . . . . . 12 5.2. Custom Keywords . . . . . . . . . . . . . . . . . . . . . 13 5.3. Custom Identifiers and Types . . . . . . . . . . . . . . 13 5.4. APL Compilation Model . . . . . . . . . . . . . . . . . . 14 5.5. APL to OtO OpCode Translation . . . . . . . . . . . . . . 15 5.6. Full APL Example . . . . . . . . . . . . . . . . . . . . 16 Sripad Expires 1 March 2027 [Page 2] Internet-Draft AegisFS Architecture August 2026 6. Identity and Context Engine . . . . . . . . . . . . . . . . . 18 6.1. Multi-Dimensional Identity Chain . . . . . . . . . . . . 18 6.2. Context Evaluation Attributes . . . . . . . . . . . . . . 18 6.3. Decision Outcomes . . . . . . . . . . . . . . . . . . . . 19 7. Dynamic Contextual ACL Engine . . . . . . . . . . . . . . . . 19 8. Capability Engine . . . . . . . . . . . . . . . . . . . . . . 20 9. Intent-Based File Operations . . . . . . . . . . . . . . . . 21 10. Object Lifecycle State Machine . . . . . . . . . . . . . . . 21 11. Transaction and Versioning Engine . . . . . . . . . . . . . . 22 12. File Provenance Graph . . . . . . . . . . . . . . . . . . . . 22 13. Dependency Graph Engine . . . . . . . . . . . . . . . . . . . 22 14. Metadata Engine . . . . . . . . . . . . . . . . . . . . . . . 23 15. Resource Governance Engine . . . . . . . . . . . . . . . . . 23 16. Process and Execution Awareness Engine . . . . . . . . . . . 24 17. SCSWP Collaborative Workspace Engine . . . . . . . . . . . . 24 18. Data Classification and Flow Control . . . . . . . . . . . . 24 19. Immutable Security Zones . . . . . . . . . . . . . . . . . . 24 20. Secure Object Identity . . . . . . . . . . . . . . . . . . . 25 21. Digital Twin Engine . . . . . . . . . . . . . . . . . . . . . 25 22. AI Intelligence Layer . . . . . . . . . . . . . . . . . . . . 25 22.1. Static Analysis Module . . . . . . . . . . . . . . . . . 25 22.2. Dynamic Behavioral Analysis Module . . . . . . . . . . . 26 22.3. Predictive Impact Engine . . . . . . . . . . . . . . . . 26 22.4. Behavioral Risk Engine . . . . . . . . . . . . . . . . . 26 23. Deception and Canary Object Framework . . . . . . . . . . . . 26 24. Autonomous Incident Response Engine . . . . . . . . . . . . . 26 25. Forensics and Audit Engine . . . . . . . . . . . . . . . . . 27 26. Snapshot and Recovery Engine . . . . . . . . . . . . . . . . 27 27. Secure Web Access Gateway . . . . . . . . . . . . . . . . . . 27 28. Complete End-to-End Operational Lifecycle . . . . . . . . . . 27 29. Security Considerations . . . . . . . . . . . . . . . . . . . 28 29.1. Policy Engine Attack Surface . . . . . . . . . . . . . . 28 29.2. OtO OpCode Injection . . . . . . . . . . . . . . . . . . 29 29.3. AI Risk Score Manipulation . . . . . . . . . . . . . . . 29 29.4. Capability Token Theft . . . . . . . . . . . . . . . . . 29 29.5. Ransomware and Mass Encryption Defense . . . . . . . . . 29 30. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 31. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 32. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 32.1. Normative References . . . . . . . . . . . . . . . . . . 30 32.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A: Full OtO OpCode Table (Representative Entries) . . . 31 Appendix B: APL Grammar (ABNF per RFC 5234) . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 Sripad Expires 1 March 2027 [Page 3] Internet-Draft AegisFS Architecture August 2026 1. Introduction 1.1. Motivation and Problem Statement Modern computing environments demand security primitives that go far beyond traditional discretionary or mandatory access control. Existing filesystem security models treat files and directories as passive, path-identified storage to which permissions are applied statically. This model is fundamentally inadequate for the following reasons: a. Identity is not context-aware. A permission granted to a user applies regardless of device, application, network state, or risk context. b. Access decisions are static. Permissions do not respond to behavioral anomalies, ransomware-pattern writes, or data exfiltration flows. c. Operations are opaque. The filesystem has no concept of the intent behind a write or delete operation. d. Files have no relationships. Dependencies, provenance, and data flow relationships are invisible to the security model. e. There is no execution-level governance. A binary placed in a directory can be executed without analysis or sandboxing. AegisFS addresses all of these gaps by replacing the passive file abstraction with a governed, intelligent object model where every file and folder is a first-class security principal. 1.2. Goals and Non-Goals Goals: * Define a portable, extensible model for intelligent file objects. * Specify the Octal to OpCode (OtO) framework for real-time policy enforcement with minimal latency overhead. * Define the Aegis Policy Language (APL) as a policy-driven programming architecture where policy syntax defines executable behavior. * Specify lifecycle, transaction, provenance, dependency, resource, collaborative, and AI behavioral models for filesystem objects. Sripad Expires 1 March 2027 [Page 4] Internet-Draft AegisFS Architecture August 2026 Non-Goals: * This document does not specify a general-purpose filesystem protocol such as an NFS or SMB extension. * This document does not specify cryptographic algorithm suites. * This document does not address cloud storage APIs directly. 1.3. Working Group Dispatch Rationale *SECDISPATCH:* AegisFS introduces a broad, multi-domain security architecture touching access control, behavioral analysis, attestation, and policy enforcement. SECDISPATCH is the appropriate initial venue to evaluate which sub-components should be advanced to dedicated Working Groups such as SACM, RATS, OAUTH, or a potential new WG. *RATS (Remote ATtestation procedureS):* The AegisFS Identity and Context Engine relies on device trust attestation and application identity verification that align directly with the RATS architecture [RFC9334]. The Secure Object Identity model, contextual access chain, and capability token attestation are strong candidates for alignment with RATS Entity Attestation Tokens (EAT). 2. Terminology and Conventions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. AegisFS Object (AFO): A file or folder registered with the AegisFS runtime and elevated from a passive storage item to a governed security object with identity, policy, lifecycle state, and behavioral profile. Octal to OpCode (OtO) Framework: The real-time instruction encoding system used by AegisFS to compile all operations, state transitions, and intents into a 9-bit octal instruction for hardware-accelerated processing. Aegis Policy Language (APL): The policy-driven DSL used to define workspace security boundaries, access rules, resource limits, execution constraints, and lifecycle governance. APL is the primary programming interface for AegisFS. Policy-Driven Architecture (PDA): An architectural model in which Sripad Expires 1 March 2027 [Page 5] Internet-Draft AegisFS Architecture August 2026 the policy definition, expressed in APL, is compiled directly into executable runtime behavior. No operation can execute unless a valid APL policy permits it. Capability Token (CT): A short-lived, cryptographically bound permission artifact granting a specific principal the right to perform a specific operation on a specific object for a constrained duration. Digital Twin: A runtime model of the expected structural and behavioral state of a workspace or file object, used for anomaly detection by comparing expected state against observed state. SCSWP: Secure Collaborative Staging Workspace Protocol — the sub- protocol managing multi-user collaborative access to protected workspaces through controlled staging areas. Lifecycle State: One of eight defined states in the AegisFS object state machine: CREATED, STAGING, ANALYZING, APPROVED, ACTIVE, QUARANTINED, ARCHIVED, DESTROYED. Intent Declaration: A structured, pre-operation declaration by a principal indicating the intended operation category, expected file scope, and expected behavioral profile. 3. High-Level Architecture 3.1. System Layers The AegisFS system is organized into four horizontal layers: 1. *Application / Web UI Layer:* The user-facing interface. Never directly exposed to the filesystem. 2. *Secure Access Gateway:* Handles authentication, session management, secure HTTPS/TLS API, and tunnel management. 3. *AegisFS Runtime:* Contains the Programmable Folder Engine, Identity Engine, Policy/ACL Engine, Capability Engine, Resource Engine, Transaction Engine, Dependency Engine, Data Flow Engine, Collaboration/SCSWP Engine, Provenance Engine, AI Intelligence Layer, Decision Engine, and the OtO OpCode Execution Bus. 4. *OS / Filesystem Adapter:* Interfaces with the underlying OS security primitives, storage, and filesystem. Sripad Expires 1 March 2027 [Page 6] Internet-Draft AegisFS Architecture August 2026 3.2. The Intelligent File Object Model Every file registered with AegisFS is elevated to an Intelligent File Object (IFO). Unlike a traditional file which is identified only by path, an IFO carries the following mandatory attributes: * Object ID (UUID v7, immutable from creation) * Structured Metadata block * Verified Owner identity * Dynamic Contextual ACL * Active Capability Token rules * Security Classification (PUBLIC through CRITICAL) * Lifecycle State (from the 8-state FSM) * Content Integrity Hash (SHA-256 or SHA-3-256) * Immutable Version History chain * Provenance lineage graph * Dependency map * Resource consumption profile * Behavioral baseline profile * Data Flow Policy * AI Risk Profile (score 0-100) * Append-only Audit History 3.3. Workspace Folder Structure A conformant AegisFS workspace MUST maintain the following logical structure: Sripad Expires 1 March 2027 [Page 7] Internet-Draft AegisFS Architecture August 2026 /project | +-- .aegis/ | +-- metadata/ (Object metadata store) | +-- policies/ (Compiled APL policy bundles) | +-- acl/ (ACL definitions) | +-- capabilities/ (Active capability tokens) | +-- lifecycle/ (State machine state records) | +-- transactions/ (Transaction journals) | +-- provenance/ (Provenance graphs) | +-- dependencies/ (Dependency maps) | +-- snapshots/ (Pre-operation snapshots) | +-- intelligence/ (AI model outputs, risk profiles) | +-- audit/ (Append-only tamper-evident log) | +-- staging/ | +-- user_A/ | +-- user_B/ | +-- active/ +-- immutable/ +-- quarantine/ +-- archive/ 4. Octal to OpCode (OtO) Framework 4.1. Design Rationale String-based or JSON-based intent descriptions impose unacceptable latency in high-throughput real-time security enforcement. Parsing a JSON intent descriptor may take hundreds of microseconds; policy enforcement decisions MUST complete in microseconds to avoid becoming a denial-of-service vector. The OtO Framework solves this by compiling all intents, states, and domain contexts into a single 9-bit octal integer at policy compile time. The runtime processes all enforcement decisions using bitwise operations on this compact opcode, leveraging hardware-level instruction pipelines and CPU branch predictors with O(1) jump-table dispatch. OtO opcodes are immutable once compiled. A change in policy requires recompilation and re-issuance of all affected opcodes, providing a strong auditability boundary. Sripad Expires 1 March 2027 [Page 8] Internet-Draft AegisFS Architecture August 2026 4.2. OpCode Bit Field Structure The OtO OpCode is a 9-bit value expressed in octal notation with three 3-bit fields: Bit positions: [8 7 6] [5 4 3] [2 1 0] ------- ------- ------- DOMAIN STATE INTENT Octal notation: 0o X Y Z Where: X = Domain field (bits 8:6) -- What engine is acting Y = State field (bits 5:3) -- Current object lifecycle state Z = Intent field (bits 2:0) -- Operation being requested Maximum representable operations: 8 x 8 x 8 = 512 unique opcodes. Example: 0o241 X = 2 (Policy/ACL Domain) Y = 4 (ACTIVE lifecycle state) Z = 1 (WRITE intent) --> Policy engine evaluating a WRITE on an ACTIVE object. 4.3. Domain Codes (X Field) +=======+====================+====================================+ | Code | Domain Name | Description | +=======+====================+====================================+ | 0o0xx | KERNEL / SYSTEM | Kernel-level and OS primitives | +-------+--------------------+------------------------------------+ | 0o1xx | METADATA | Metadata read/write operations | +-------+--------------------+------------------------------------+ | 0o2xx | POLICY / ACL | Policy evaluation and ACL checks | +-------+--------------------+------------------------------------+ | 0o3xx | TRANSACTION ENGINE | Commit, rollback, stage operations | +-------+--------------------+------------------------------------+ | 0o4xx | CAPABILITY ENGINE | Token issue, validate, revoke | +-------+--------------------+------------------------------------+ | 0o5xx | AI / INTELLIGENCE | Static, dynamic, behavioral ops | +-------+--------------------+------------------------------------+ | 0o6xx | PROVENANCE / | Graph reads and writes | | | DEPENDENCY | | +-------+--------------------+------------------------------------+ | 0o7xx | FORENSICS / AUDIT | Audit log writes and queries | +-------+--------------------+------------------------------------+ Table 1 Sripad Expires 1 March 2027 [Page 9] Internet-Draft AegisFS Architecture August 2026 4.4. Object State Codes (Y Field) +=======+=============+=============================================+ | Code | State Name | Description | +=======+=============+=============================================+ | 0ox0x | CREATED | Object registered, not yet staged | +-------+-------------+---------------------------------------------+ | 0ox1x | STAGING | In staging workspace, unvalidated | +-------+-------------+---------------------------------------------+ | 0ox2x | ANALYZING | Under static or AI analysis | +-------+-------------+---------------------------------------------+ | 0ox3x | APPROVED | Analysis passed, pending activation | +-------+-------------+---------------------------------------------+ | 0ox4x | ACTIVE | In production, fully governed | +-------+-------------+---------------------------------------------+ | 0ox5x | QUARANTINED | Restricted due to anomaly or policy | | | | failure | +-------+-------------+---------------------------------------------+ | 0ox6x | ARCHIVED | Read-only, end-of-life | +-------+-------------+---------------------------------------------+ | 0ox7x | DESTROYED | Scheduled for cryptographic erasure | +-------+-------------+---------------------------------------------+ Table 2 4.5. Operation Intent Codes (Z Field) +=======+=============+==========================================+ | Code | Intent Name | Description | +=======+=============+==========================================+ | 0oxx0 | READ | Content or metadata read operation | +-------+-------------+------------------------------------------+ | 0oxx1 | WRITE | Content modification | +-------+-------------+------------------------------------------+ | 0oxx2 | LOCK | Shared, exclusive, or transaction lock | +-------+-------------+------------------------------------------+ | 0oxx3 | SNAPSHOT | Point-in-time snapshot creation | +-------+-------------+------------------------------------------+ | 0oxx4 | ROLLBACK | Restore to prior snapshot or version | +-------+-------------+------------------------------------------+ | 0oxx5 | COMMIT | Finalize and promote a transaction | +-------+-------------+------------------------------------------+ | 0oxx6 | ELEVATE | Privilege escalation request | +-------+-------------+------------------------------------------+ | 0oxx7 | DESTROY | Secure deletion or cryptographic erasure | +-------+-------------+------------------------------------------+ Table 3 Sripad Expires 1 March 2027 [Page 10] Internet-Draft AegisFS Architecture August 2026 4.6. OpCode Encoding Examples +========+======================================+==================+ | OpCode | Scenario Description | Decision Route | +========+======================================+==================+ | 0o241 | Policy engine WRITE on ACTIVE object | ACL + Capability | | | | check | +--------+--------------------------------------+------------------+ | 0o340 | Transaction engine READ in STAGING | Staging read | | | | handler | +--------+--------------------------------------+------------------+ | 0o355 | Transaction COMMIT in QUARANTINE | DENY (invalid | | | | state) | +--------+--------------------------------------+------------------+ | 0o520 | AI READ on ANALYZING object | Analysis | | | | pipeline | +--------+--------------------------------------+------------------+ | 0o471 | Capability engine WRITE on ACTIVE | Token validation | +--------+--------------------------------------+------------------+ | 0o100 | Metadata READ on CREATED object | Always permitted | +--------+--------------------------------------+------------------+ | 0o047 | Kernel DESTROY on ARCHIVED object | Policy + Human | | | | Approval | +--------+--------------------------------------+------------------+ | 0o700 | Forensics READ (audit query) | Audit chain | | | | required | +--------+--------------------------------------+------------------+ Table 4 4.7. Real-Time Execution Pipeline When a principal requests an operation, the OtO pipeline executes the following steps: 1. *CONTEXT CAPTURE:* Capture principal identity, device attestation, session token, application identity, and timestamp. 2. *OPCODE RESOLUTION:* Resolve domain from operation type, query current object state from lifecycle engine, encode intent. Construct: 0o[D][S][I]. 3. *OPCODE DISPATCH:* Feed opcode to jump table in O(1) time. The jump table routes to the appropriate enforcement handler. 4. *POLICY EVALUATION:* Handler evaluates dynamic ACL conditions, capability tokens, resource budgets, and AI risk scores against the compiled APL policy bundle. Sripad Expires 1 March 2027 [Page 11] Internet-Draft AegisFS Architecture August 2026 5. *DECISION EMIT:* One of: ALLOW | RESTRICT | STAGE | SANDBOX | QUARANTINE | DENY | REQUIRE_APPROVAL. 6. *AUDIT RECORD:* Write atomic audit record regardless of decision outcome: {timestamp, opcode, principal_id, object_id, decision}. 4.8. OpCode Fault Handling If an opcode corresponds to a state transition that is invalid per the lifecycle state machine (e.g., 0o355 — COMMIT while QUARANTINED), the OtO pipeline MUST: a. Immediately return DENY without further evaluation. b. Write a fault audit record with the malformed opcode. c. Increment the principal's anomaly score. d. Notify the behavioral risk engine. 5. Aegis Policy Language (APL) — Policy-Driven Architecture 5.1. Language Design Philosophy APL is a next-generation, statically typed, declarative policy programming language. It is NOT a configuration format — it is a programming language where the source code defines the complete operational and security architecture of a workspace. *Core Principle:* An operation that does not have a valid, syntactically correct APL expression granting it permission cannot produce a valid OtO opcode. Policy definition IS execution authorization. APL has the following design properties: a. *Declarative:* Policies express WHAT is permitted, not HOW to enforce it. The runtime translates declarations to OtO opcodes. b. *Strongly typed:* All identifiers have declared types; type mismatches are compilation errors, not runtime failures. c. *Deterministic:* Given the same policy and context, APL MUST always produce the same OtO opcode and enforcement decision. d. *Non-Turing-complete:* APL deliberately excludes loops and arbitrary computation. All policies terminate in bounded time. Sripad Expires 1 March 2027 [Page 12] Internet-Draft AegisFS Architecture August 2026 e. *Auditable:* Every APL compilation event MUST be logged with the policy hash, compiler version, and resulting opcode set. 5.2. Custom Keywords APL defines the following reserved keywords that MUST NOT be used as identifiers: *Primary Structural Keywords:* workspace, domain, group, object, intent *Configuration Block Keywords:* classification, storage, access, resources, execution, lifecycle, dataflow, capability, ai *Condition Keywords:* if, unless, when, requires, permits, denies, elevates *Value Constants:* true, false, null, required, conditional, optional, critical, restricted, confidential, internal, public, allow, deny, stage, sandbox, quarantine, restrict, read, write, execute, audit, lock, snapshot, commit, rollback, destroy, approve, reject 5.3. Custom Identifiers and Types +================+===============================+ | Type Name | Description | +================+===============================+ | Principal | A human user, service | | | account, or device identity | +----------------+-------------------------------+ | PrincipalGroup | A named collection of | | | Principals | +----------------+-------------------------------+ | FileObject | An AegisFS-governed file or | | | directory | +----------------+-------------------------------+ | Classification | An enumerated data | | | sensitivity level | +----------------+-------------------------------+ | Permission | An enumerated operation type | +----------------+-------------------------------+ | Capability | A time-bound, scoped | | | permission token definition | +----------------+-------------------------------+ | ResourceLimit | A quantified resource | | | constraint | +----------------+-------------------------------+ Sripad Expires 1 March 2027 [Page 13] Internet-Draft AegisFS Architecture August 2026 | LifecycleState | An enumerated lifecycle state | | | value | +----------------+-------------------------------+ | RiskThreshold | An integer 0-100 representing | | | an AI risk score | +----------------+-------------------------------+ | Duration | A time duration (e.g., 10m, | | | 1h, 30d) | +----------------+-------------------------------+ | Extension | A file extension string | | | (e.g., ".c", ".json") | +----------------+-------------------------------+ | OpCode | A compiled 9-bit octal opcode | | | reference | +----------------+-------------------------------+ Table 5 5.4. APL Compilation Model APL source MUST be compiled before deployment. The compilation pipeline: Sripad Expires 1 March 2027 [Page 14] Internet-Draft AegisFS Architecture August 2026 APL Source File | v [LEXER] Tokenizes source into keyword/identifier/literal stream. Rejects: unknown keywords, type mismatches. | v [PARSER] Builds Abstract Syntax Tree (AST). Validates: grammar rules, block nesting, required fields. | v [SEMANTIC ANALYZER] Validates: type correctness, group references, resource limit units, risk score ranges (0-100). | v [OPCODE EMITTER] Translates each policy permission into the set of OtO opcodes that it authorizes. | v [POLICY BUNDLE] Cryptographically signed {AST + OpCode Authorization Table}. Written to .aegis/policies/ Compilation MUST fail with a descriptive error if: * A keyword is used in an invalid syntactic position. * A PrincipalGroup is referenced but not defined. * A resource limit value has an ambiguous or missing unit. * An intent block references a permission not granted in the parent access block. * A capability expires before its minimum use count can be reached. 5.5. APL to OtO OpCode Translation The APL compiler generates an opcode authorization table during compilation. Each table entry maps: Sripad Expires 1 March 2027 [Page 15] Internet-Draft AegisFS Architecture August 2026 (PrincipalGroup, ObjectPattern, Permission, StateConstraint) --> set of authorized OtO opcodes Example: APL rule: access { developers = [read, write] if file_state = active } Compiled to authorized opcodes: {0o240, 0o241} (Policy domain, ACTIVE state, READ + WRITE) At runtime, developer requests WRITE on ACTIVE object: Requested opcode : 0o241 Table lookup : 0o241 in {0o240, 0o241} -> MATCH -> ALLOW 5.6. Full APL Example The following is a complete, production-grade APL workspace policy: workspace Banking_Project { classification = critical storage { allowed_extensions = [".c", ".h", ".json", ".toml"] max_file_size = 100MB max_workspace_size = 20GB immutable = false } access { developers = [read, write] security_team = [read, audit] admin = [read, write, execute, approve] ci_system = [read, execute] when device_trusted = true when session_valid = true } resources { max_memory = 2GB max_cpu = 40% max_io = 200MBps max_network = 50MBps max_processes = 20 max_handles = 500 Sripad Expires 1 March 2027 [Page 16] Internet-Draft AegisFS Architecture August 2026 } execution { static_analysis = required dynamic_analysis = conditional sandbox_on_risk = true risk_threshold = 60 approved_apps = [AegisEditor, AegisCompiler, AegisBuild] } lifecycle { staging_required = true approval_required = true auto_archive = 365d auto_destroy = 2555d } dataflow { permits = [AegisWorkspace, SecureExport] denies = [ExternalDrive, PublicCloud, Email] } ai { behavioral_baseline = required anomaly_threshold = 75 digital_twin = enabled } capability write_cap { grants = [write] on_object = "active/*" expires = 10m max_uses = 5 principal = developers } object "immutable/security/*" { access { admin = [read, approve] } intent SECURE_UPDATE { permits = [read, snapshot, write, commit] requires = [approval, integrity_check, staging] } } } Sripad Expires 1 March 2027 [Page 17] Internet-Draft AegisFS Architecture August 2026 6. Identity and Context Engine 6.1. Multi-Dimensional Identity Chain AegisFS does not rely on a flat user-to-permission mapping. Access decisions are computed from a multi-dimensional identity chain: Principal (User) | v Device (attested via RATS EAT token [RFC9334]) | v Application / Process (code identity, signature) | v Runtime Context (session state, network zone, time window) | v File Object (classification, lifecycle state, risk score) 6.2. Context Evaluation Attributes An access decision MUST evaluate ALL of the following: Sripad Expires 1 March 2027 [Page 18] Internet-Draft AegisFS Architecture August 2026 +==========================+======================================+ | Attribute | Source | +==========================+======================================+ | Principal Identity | Authenticated credential (OIDC/SAML) | +--------------------------+--------------------------------------+ | Authentication Strength | MFA factor level | +--------------------------+--------------------------------------+ | Device Trust Level | RATS attestation token | +--------------------------+--------------------------------------+ | Application Identity | Code signing certificate | +--------------------------+--------------------------------------+ | Process Context | PID, parent process, arguments | +--------------------------+--------------------------------------+ | Current APL Policy Match | Compiled policy bundle | +--------------------------+--------------------------------------+ | Object Lifecycle State | State machine current state | +--------------------------+--------------------------------------+ | Object AI Risk Score | Most recent risk engine output | +--------------------------+--------------------------------------+ | Session Validity | Session token expiry and integrity | +--------------------------+--------------------------------------+ | Network Zone | Internal/external/VPN status | +--------------------------+--------------------------------------+ Table 6 6.3. Decision Outcomes The Identity Engine emits one of: * *ALLOW* — All conditions satisfied; proceed. * *RESTRICT* — Allow with reduced permissions or rate limits. * *REQUIRE_APPROVAL* — Valid but needs human approval. * *DENY* — One or more mandatory conditions not satisfied. 7. Dynamic Contextual ACL Engine Unlike traditional static ACLs, AegisFS implements Dynamic Contextual ACLs (DCALs). A DCAL entry takes the form: PERMIT ON WHEN AND ... AND All conditions are evaluated at the moment of each access request. A permission valid at time T is not assumed valid at T+1. Sripad Expires 1 March 2027 [Page 19] Internet-Draft AegisFS Architecture August 2026 ACL evaluation follows a DENY-by-default model: a. If no PERMIT rule matches the current context, DENY. b. If a DENY rule explicitly matches, DENY (overrides PERMIT). c. If multiple PERMIT rules match, grant the union of permissions ONLY IF no DENY rule conflicts. d. All evaluations are logged regardless of outcome. 8. Capability Engine *ACL answers:* "Who MAY access this object in principle?" *Capability Tokens answer:* "What access is authorized RIGHT NOW?" A Capability Token MUST contain: +======================+=======================================+ | Field | Description | +======================+=======================================+ | token_id | UUID v7 unique token identifier | +----------------------+---------------------------------------+ | issuer | AegisFS Capability Engine instance ID | +----------------------+---------------------------------------+ | principal | Bound principal identity (non- | | | transferable) | +----------------------+---------------------------------------+ | object_id | Target file object UUID | +----------------------+---------------------------------------+ | permitted_opcodes | Set of authorized OtO opcodes | +----------------------+---------------------------------------+ | issued_at | Unix timestamp (UTC) | +----------------------+---------------------------------------+ | expires_at | Unix timestamp (UTC) | +----------------------+---------------------------------------+ | max_uses | Maximum permitted invocations | +----------------------+---------------------------------------+ | use_count | Current invocation count | +----------------------+---------------------------------------+ | approved_application | Bound application identity | +----------------------+---------------------------------------+ | signature | ECDSA-P256 signature over all above | | | fields | +----------------------+---------------------------------------+ Table 7 Sripad Expires 1 March 2027 [Page 20] Internet-Draft AegisFS Architecture August 2026 Revocation MUST be propagated to all runtime nodes within 100ms. A revoked token presented to the engine MUST be rejected and generate a security alert event. 9. Intent-Based File Operations For sensitive or classified objects, principals MUST declare an Intent before initiating a complex operation. The runtime monitors the actual OtO opcode stream against the declared intent: DECLARED INTENT | v EXPECTED OPERATION MODEL (from APL intent block) | v REAL EXECUTION (monitored via OtO opcode stream) | v COMPARE | +-- MATCH --> Continue; update audit log. +-- DEVIATION --> INTENT VIOLATION Actions: RESTRICT, REVOKE CAPABILITY, QUARANTINE OBJECT, GENERATE ALERT, REQUIRE HUMAN APPROVAL 10. Object Lifecycle State Machine Every AegisFS File Object MUST exist in exactly one of eight lifecycle states. Valid transitions are: CREATED --> STAGING (registration complete) STAGING --> ANALYZING (validation triggered) ANALYZING --> APPROVED (analysis passed) ANALYZING --> QUARANTINED (analysis failed or risk exceeded) APPROVED --> ACTIVE (admin approval granted) ACTIVE --> STAGING (modification initiated; re-staging) ACTIVE --> QUARANTINED (anomaly detected at runtime) ACTIVE --> ARCHIVED (lifecycle auto-archive policy) QUARANTINED--> STAGING (manual admin recovery initiated) QUARANTINED--> DESTROYED (policy: destroy on quarantine) ARCHIVED --> DESTROYED (retention policy expired) All other transitions MUST be rejected by the OtO pipeline. Sripad Expires 1 March 2027 [Page 21] Internet-Draft AegisFS Architecture August 2026 11. Transaction and Versioning Engine Modifications to objects MUST be performed within an atomic transaction: BEGIN TRANSACTION (acquire TRANSACTION LOCK: 0o342) | +-- Create pre-modification SNAPSHOT (0o343) +-- Perform operations (WRITE: 0o341, etc.) | v VALIDATE +-- Integrity: Verify content hash of each modified object +-- Permissions: Re-evaluate ACL for all touched objects +-- Dependencies: Check no dependency constraints violated +-- Policies: Re-evaluate APL rules post-modification | v COMMIT (0o3x5) --> New version record created, lock released OR ROLLBACK (0o3x4) --> Snapshot restored, lock released Each COMMIT produces an immutable, hash-linked Version Record. Tampering with any record breaks the chain and MUST generate a critical forensics alert. 12. File Provenance Graph AegisFS maintains a directed provenance graph where nodes represent Principals, Processes, and File Objects; and edges represent Created, Modified, Derived-From, and Used-By relationships. The provenance engine MUST support: * ANCESTORS(object_id): All upstream principals and processes. * DESCENDANTS(object_id): All downstream derived objects. * IMPACT(process_id): All objects touched by a process. * LINEAGE(object_id, version_id): Full creation-to-state chain. 13. Dependency Graph Engine When a modification is requested on any object, the engine MUST: a. Query the dependency graph for all objects consuming or referencing the target. Sripad Expires 1 March 2027 [Page 22] Internet-Draft AegisFS Architecture August 2026 b. Compute the full transitive impact set. c. Report the impact set to the principal before permitting modification. d. Evaluate whether dependent objects' policies require revalidation, testing, or approval before the change commits. 14. Metadata Engine Every AegisFS File Object carries a mandatory metadata block: typedef struct AegisObjectMetadata { char object_id[64]; /* UUID v7 string */ char owner_id[64]; /* Principal UUID */ uint64_t creation_time; /* Unix timestamp (UTC) */ uint64_t modification_time; /* Unix timestamp (UTC) */ uint64_t file_size; /* Bytes */ uint64_t version; /* Monotonic version number */ uint32_t permissions; /* Encoded ACL bitmask */ uint8_t integrity_hash[32]; /* SHA-256 content hash */ uint8_t classification; /* 0=PUBLIC .. 4=CRITICAL */ uint8_t lifecycle_state; /* 0=CREATED .. 7=DESTROYED */ uint32_t ai_risk_score; /* 0-100 */ uint8_t metadata_hash[32]; /* SHA-256 of this struct */ } AegisObjectMetadata; Any modification to metadata MUST occur within a transaction, recompute the metadata_hash, and log the change event. 15. Resource Governance Engine Each workspace is assigned a hard resource budget enforced by the Resource Governance Engine. Exceeding any limit MUST result in throttling, a governance audit event, notification to the AI behavioral engine, and potential escalation to QUARANTINE state if the pattern is sustained. AegisFS provides tracked memory allocation APIs for runtime modules: ag_malloc(), ag_calloc(), ag_realloc(), ag_free(). Every allocation is tracked with: Allocation ID, Context ID, Size, Owner application, Timestamp, and Declared lifetime. Sripad Expires 1 March 2027 [Page 23] Internet-Draft AegisFS Architecture August 2026 16. Process and Execution Awareness Engine For any application accessing AegisFS objects, the runtime constructs an Execution Context tracking: files accessed, resources consumed, child processes spawned, network activity, and OS interaction profile. AegisFS implements Adaptive Locking that dynamically selects the locking strategy — ALLOW CONCURRENT, WAIT, STAGE COPY, MERGE LATER, or DENY — based on current context and risk level, avoiding unnecessary hard locking in collaborative environments. 17. SCSWP Collaborative Workspace Engine The Secure Collaborative Staging Workspace Protocol (SCSWP) governs multi-user collaboration. Users NEVER directly access the protected production source. All collaboration occurs in policy-controlled staging areas. Conflicts (structural, dependency, or policy) MUST be resolved explicitly before commit. 18. Data Classification and Flow Control AegisFS defines five classification levels: * 0 = PUBLIC: Freely sharable. * 1 = INTERNAL: Internal use only; no external export. * 2 = CONFIDENTIAL: Restricted distribution; encryption required. * 3 = RESTRICTED: Very limited distribution; approval required. * 4 = CRITICAL: Maximum protection; all controls mandatory. Classification MUST be propagated to derived objects. The Data Flow Engine evaluates all data movement operations against the APL dataflow block and intercepts unauthorized transfers to unapproved destinations, cloud endpoints, external storage, or clipboard. 19. Immutable Security Zones Objects in immutable zones require an authorized request, a staging version, integrity validation, policy approval, and a new signed version before any write commits. Direct writes that bypass this workflow MUST be rejected at the OtO pipeline level with a CRITICAL audit event. The previous version MUST be retained indefinitely for recovery. Sripad Expires 1 March 2027 [Page 24] Internet-Draft AegisFS Architecture August 2026 20. Secure Object Identity An AegisFS File Object MUST NOT be identified by filesystem path alone. Object identity is composed of: OBJECT IDENTITY = { object_id : UUID v7 (immutable from creation) content_hash: SHA-256 of current content version_id : Current version integer owner_id : Creating principal UUID signature : ECDSA-P256 signature by the issuing AegisFS node } If a file is renamed, its object_id and identity remain unchanged. This model aligns with the RATS [RFC9334] concept of stable Endorsement targets whose identity persists across environment changes. 21. Digital Twin Engine The Digital Twin Engine maintains a runtime model of the expected structural and behavioral state of each workspace and file object, including: structure model, file relationships, dependency graph, access patterns, resource patterns, behavioral baseline, and security state. On HIGH ANOMALY detection (e.g., mass write rates exceeding baseline by orders of magnitude — a ransomware indicator), the engine MUST: immediately freeze writes, create an emergency snapshot, elevate the object to QUARANTINED state, revoke all active capability tokens for the workspace, and notify the Forensics and Incident Response Engine. 22. AI Intelligence Layer 22.1. Static Analysis Module Before any object transitions from ANALYZING to APPROVED, the static analysis module performs type detection, content inspection, dependency enumeration, Control Flow Graph (CFG) construction, Call Graph construction, and Data Flow Graph construction to produce a STATIC RISK PROFILE (score 0-100). Sripad Expires 1 March 2027 [Page 25] Internet-Draft AegisFS Architecture August 2026 22.2. Dynamic Behavioral Analysis Module During sandboxed execution, the module monitors file activity, resource consumption, memory behavior, network connections, child processes, and system calls. Expected (from static analysis) is compared against Actual. Discrepancies elevate the dynamic risk score. 22.3. Predictive Impact Engine Before execution, a pre-flight impact report is generated with estimated memory, CPU, disk I/O, network usage, number of files affected, and an overall risk score. Decision routing: * 0-30 (LOW): ALLOW * 31-60 (MEDIUM): ALLOW WITH RESOURCE LIMITS * 61-80 (HIGH): SANDBOX REQUIRED * 81-100 (CRITICAL): DENY or QUARANTINE For CRITICAL objects, deterministic policy limits MUST take precedence over probabilistic AI estimates. 22.4. Behavioral Risk Engine Every file object develops a behavioral baseline. The risk engine monitors for deviations: mass write bursts (ransomware pattern), mass rename operations (encryption attack pattern), off-hours access (credential compromise indicator). On detection: freeze writes, snapshot, restrict session, move to QUARANTINED state, generate CRITICAL alert, require human approval to resume. 23. Deception and Canary Object Framework Canary Objects are decoy files that appear legitimate but trigger immediate incident response upon access. They MUST NOT contain real sensitive data and MUST log every access attempt. Any access by a non-audit principal generates a CRITICAL alert. The mere attempt to access a canary object is treated as a high- confidence indicator of unauthorized access or threat actor presence. 24. Autonomous Incident Response Engine The engine executes bounded, policy-defined automated responses: LOG, ALERT, RESTRICT, REVOKE_CAPABILITY, FREEZE_WRITES, SNAPSHOT, QUARANTINE, REQUIRE_APPROVAL. Sripad Expires 1 March 2027 [Page 26] Internet-Draft AegisFS Architecture August 2026 Destructive response actions (DESTROY, WIPE) MUST require explicit human approval regardless of the AI risk score or anomaly severity. Autonomous destruction of data is NOT permitted. 25. Forensics and Audit Engine Every significant operation MUST produce an audit event written to an append-only, integrity-protected log. Each event contains: event_id, timestamp (nanosecond UTC), principal_id, device_id, application_id, object_id, opcode (e.g., 0o241), operation, intent_id, decision, policy_bundle_hash, integrity_reference, and chain_hash (SHA-256 of event_id concatenated with prev_chain_hash). The chain_hash field creates a tamper-evident audit chain. Any gap or hash mismatch MUST trigger an immediate forensics alert. 26. Snapshot and Recovery Engine Before high-risk operations, the engine MUST create a snapshot capturing: files, metadata, ACL, capabilities, policies, dependency state, provenance state, and transaction state. Snapshots MUST be: stored in an integrity-protected location outside the workspace; indexed by (object_id, transaction_id, timestamp); retained for a minimum period defined in the APL lifecycle block; and verifiable via their own integrity hash chain. 27. Secure Web Access Gateway The AegisFS web interface MUST NEVER expose the filesystem directly. All access flows through the AegisFS Access Gateway which performs: authentication (OIDC/SAML), session control (JWT with short TTL), authorization (ACL + Capability check), object policy check (APL evaluation), and pre-response audit logging. CORS configuration restricts which web origins may call the API, but CORS is NOT a security boundary — it is a browser enforcement hint only. The authentication and authorization layer MUST be the primary security control. Internal tunneling MUST be explicitly authorized in APL policy and logged for its full duration. 28. Complete End-to-End Operational Lifecycle The following describes the complete lifecycle of a single protected file operation request across 25 steps: Sripad Expires 1 March 2027 [Page 27] Internet-Draft AegisFS Architecture August 2026 STEP 01: USER / APPLICATION REQUEST STEP 02: IDENTITY VALIDATION (OIDC/SAML + RATS attestation) STEP 03: CONTEXT VALIDATION (device, session, network zone) STEP 04: APL POLICY + DCAL CHECK (syntax match + condition eval) STEP 05: CAPABILITY TOKEN VALIDATION (scope, expiry, use count) STEP 06: OtO OPCODE GENERATION (domain + state + intent encoding) STEP 07: OBJECT STATE CHECK (lifecycle state machine query) STEP 08: INTENT DECLARATION (for sensitive/critical objects) STEP 09: DEPENDENCY ANALYSIS (impact set computation) STEP 10: RESOURCE AVAILABILITY CHECK (budget enforcement) STEP 11: AI STATIC/PREDICTIVE ANALYSIS (if required by APL) STEP 12: DECISION ENGINE | +-----+-----+ | | | ALLOW STAGE SANDBOX | v STEP 13: TRANSACTION BEGIN + PRE-OPERATION SNAPSHOT STEP 14: EXECUTION / FILE OPERATION STEP 15: RUNTIME BEHAVIORAL MONITORING (digital twin comparison) STEP 16: INTENT VERIFICATION (expected vs. actual opcode stream) STEP 17: INTEGRITY + DATA FLOW VALIDATION STEP 18: TRANSACTION VALIDATION | +-----+------+ | | COMMIT ROLLBACK | | v v STEP 19: VERSION RECORD CREATION | SNAPSHOT RESTORE STEP 20: DIGITAL TWIN UPDATE STEP 21: PROVENANCE GRAPH UPDATE STEP 22: DEPENDENCY GRAPH UPDATE STEP 23: AUDIT EVENT WRITE (chain hash update) STEP 24: CAPABILITY TOKEN USE COUNT INCREMENT STEP 25: FINAL STATE NOTIFICATION TO PRINCIPAL 29. Security Considerations 29.1. Policy Engine Attack Surface The Policy Engine and APL compiler are the highest-value attack targets. Implementations MUST: run the APL compiler in an isolated sandboxed process; validate all policy bundles with ECDSA signatures before loading; reject any policy bundle that does not chain to a trusted root; and log all policy compilation and loading events to the audit chain. Sripad Expires 1 March 2027 [Page 28] Internet-Draft AegisFS Architecture August 2026 29.2. OtO OpCode Injection Malformed or spoofed OtO opcodes MUST NOT be accepted from external or untrusted sources. All opcodes MUST be generated internally by the AegisFS runtime. External opcode injection attempts MUST generate a CRITICAL forensics event. 29.3. AI Risk Score Manipulation Adversaries may attempt to slowly train the behavioral baseline to accept anomalous behavior (slow-walk attacks). Implementations SHOULD: maintain multiple rolling baseline windows (1h, 24h, 30d); require anomaly scores to decrease gradually; and flag rapid baseline shifts as anomalies in themselves. 29.4. Capability Token Theft Capability Tokens MUST be bound to the specific principal, device, and application. Tokens MUST be non-transferable. Implementations MUST verify the full binding context on every token presentation, not only the signature and expiry. 29.5. Ransomware and Mass Encryption Defense The Digital Twin mass-write detection and Behavioral Risk Engine's ransomware pattern detection provide structural defenses. Thresholds MUST be set conservatively and tested explicitly, as false-negative failures have catastrophic consequences. 30. Privacy Considerations The audit log, provenance graph, and behavioral profiles contain detailed records of user activity. Implementations MUST: apply data minimization; enforce access control on audit and provenance data; define and enforce retention periods; comply with applicable data protection regulations (e.g., GDPR); and ensure AI behavioral profiles cannot be used to infer sensitive personal attributes beyond the stated security purpose. 31. IANA Considerations This document requests no immediate IANA actions. Future versions MAY request: * A registry for AegisFS OtO Domain Codes. * A registry for AegisFS OtO Intent Codes. Sripad Expires 1 March 2027 [Page 29] Internet-Draft AegisFS Architecture August 2026 * A media type registration for APL source files (text/x-apl). * A media type registration for APL policy bundles (application/x- aegisfs-policy). * A well-known URI suffix for AegisFS Access Gateways. 32. References 32.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC9334] Birkholz, H., Thaler, D., and M. Richardson, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . 32.2. Informative References [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007, . [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, May 2015, . Sripad Expires 1 March 2027 [Page 30] Internet-Draft AegisFS Architecture August 2026 Appendix A: Full OtO OpCode Table (Representative Entries) +========+========+=============+==========+==================+ | OpCode | Domain | State | Intent | Notes | +========+========+=============+==========+==================+ | 0o000 | KERNEL | CREATED | READ | Permitted | +--------+--------+-------------+----------+------------------+ | 0o041 | KERNEL | ACTIVE | WRITE | Kernel write on | | | | | | active obj | +--------+--------+-------------+----------+------------------+ | 0o100 | META | CREATED | READ | Always permitted | +--------+--------+-------------+----------+------------------+ | 0o141 | META | ACTIVE | WRITE | Metadata write | +--------+--------+-------------+----------+------------------+ | 0o240 | POLICY | ACTIVE | READ | Policy-evaluated | | | | | | read | +--------+--------+-------------+----------+------------------+ | 0o241 | POLICY | ACTIVE | WRITE | Policy-evaluated | | | | | | write | +--------+--------+-------------+----------+------------------+ | 0o255 | POLICY | QUARANTINED | COMMIT | INVALID — DENY | +--------+--------+-------------+----------+------------------+ | 0o340 | TRANS | ACTIVE | READ | Transaction read | +--------+--------+-------------+----------+------------------+ | 0o343 | TRANS | ACTIVE | SNAPSHOT | Pre-op snapshot | +--------+--------+-------------+----------+------------------+ | 0o344 | TRANS | ACTIVE | ROLLBACK | Transaction | | | | | | rollback | +--------+--------+-------------+----------+------------------+ | 0o345 | TRANS | ACTIVE | COMMIT | Transaction | | | | | | commit | +--------+--------+-------------+----------+------------------+ | 0o440 | CAP | ACTIVE | READ | Capability-gated | | | | | | read | +--------+--------+-------------+----------+------------------+ | 0o471 | CAP | DESTROYED | WRITE | INVALID — DENY | +--------+--------+-------------+----------+------------------+ | 0o520 | AI | ANALYZING | READ | Analysis | | | | | | pipeline read | +--------+--------+-------------+----------+------------------+ | 0o541 | AI | ACTIVE | WRITE | AI-governed | | | | | | write | +--------+--------+-------------+----------+------------------+ | 0o640 | PROV | ACTIVE | READ | Provenance graph | | | | | | read | +--------+--------+-------------+----------+------------------+ | 0o700 | AUDIT | CREATED | READ | Audit query | +--------+--------+-------------+----------+------------------+ Sripad Expires 1 March 2027 [Page 31] Internet-Draft AegisFS Architecture August 2026 | 0o747 | AUDIT | ACTIVE | DESTROY | Requires human | | | | | | approval | +--------+--------+-------------+----------+------------------+ Table 8 Opcodes involving QUARANTINED (Y=5) or DESTROYED (Y=7) states with WRITE, COMMIT, or ELEVATE intents MUST be treated as INVALID and MUST cause the OtO pipeline to emit DENY without further evaluation. Appendix B: APL Grammar (ABNF per RFC 5234) apl-document = 1*workspace-decl workspace-decl = "workspace" SP identifier SP "{" NL workspace-body "}" NL workspace-body = classification-stmt [storage-block] [access-block] [resource-block] [execution-block] [lifecycle-block] [dataflow-block] *capability-block [ai-block] *object-block classification-stmt = "classification" SP "=" SP class-value NL class-value = "public" / "internal" / "confidential" / "restricted" / "critical" storage-block = "storage" SP "{" NL *storage-stmt "}" NL storage-stmt = ext-list-stmt / size-stmt / bool-stmt access-block = "access" SP "{" NL *access-stmt *condition-stmt "}" NL access-stmt = identifier SP "=" SP "[" perm-list "]" NL perm-list = permission *("," SP permission) permission = "read" / "write" / "execute" / "audit" / "approve" / "lock" / "snapshot" / "commit" / "rollback" / "destroy" condition-stmt = ("when" / "if" / "unless") SP condition-expr NL condition-expr = identifier SP ("=" / "!=" / "<" / ">") SP value / condition-expr SP "and" SP condition-expr / condition-expr SP "or" SP condition-expr resource-block = "resources" SP "{" NL *resource-stmt "}" NL Sripad Expires 1 March 2027 [Page 32] Internet-Draft AegisFS Architecture August 2026 resource-stmt = identifier SP "=" SP resource-value NL resource-value = integer ("GB" / "MB" / "KB" / "%" / "MBps" / "") execution-block = "execution" SP "{" NL *execution-stmt "}" NL execution-stmt = "static_analysis" SP "=" SP analysis-level NL / "dynamic_analysis" SP "=" SP analysis-level NL / "sandbox_on_risk" SP "=" SP bool-value NL / "risk_threshold" SP "=" SP integer NL / "approved_apps" SP "=" SP "[" id-list "]" NL analysis-level = "required" / "conditional" / "disabled" lifecycle-block = "lifecycle" SP "{" NL *lifecycle-stmt "}" NL lifecycle-stmt = bool-stmt / duration-stmt capability-block = "capability" SP identifier SP "{" NL *cap-stmt "}" NL cap-stmt = "grants" SP "=" SP "[" perm-list "]" NL / "on_object" SP "=" SP quoted-string NL / "expires" SP "=" SP duration NL / "max_uses" SP "=" SP integer NL / "principal" SP "=" SP identifier NL object-block = "object" SP quoted-string SP "{" NL [access-block] *intent-block "}" NL intent-block = "intent" SP identifier SP "{" NL *intent-stmt "}" NL intent-stmt = "permits" SP "=" SP "[" perm-list "]" NL / "requires" SP "=" SP "[" req-list "]" NL req-list = identifier *("," SP identifier) ai-block = "ai" SP "{" NL *ai-stmt "}" NL ai-stmt = bool-stmt / integer-stmt / level-stmt identifier = ALPHA *( ALPHA / DIGIT / "_" / "-" ) quoted-string = DQUOTE *(%x20-21 / %x23-7E) DQUOTE bool-value = "true" / "false" bool-stmt = identifier SP "=" SP bool-value NL duration = integer ("d" / "h" / "m" / "s") duration-stmt = identifier SP "=" SP duration NL integer = 1*DIGIT integer-stmt = identifier SP "=" SP integer NL id-list = identifier *("," SP identifier) ext-list-stmt = identifier SP "=" SP "[" quoted-string *("," SP quoted-string) "]" NL size-stmt = identifier SP "=" SP resource-value NL level-stmt = identifier SP "=" SP ("enabled" / "disabled" / "required") NL Sripad Expires 1 March 2027 [Page 33] Internet-Draft AegisFS Architecture August 2026 Author's Address Sripad AegisFS Project Email: sripadkarthik@gmail.com Sripad Expires 1 March 2027 [Page 34]