]> AegisFS Project

sripadkarthik@gmail.com

Security SECDISPATCH / RATS filesystem security policy opcode attestation AI behavioral analysis capability lifecycle provenance 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.

Introduction

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:

1. Identity is not context-aware. A permission granted to a user applies regardless of device, application, network state, or risk context.
2. Access decisions are static. Permissions do not respond to behavioral anomalies, ransomware-pattern writes, or data exfiltration flows.
3. Operations are opaque. The filesystem has no concept of the intent behind a write or delete operation.
4. Files have no relationships. Dependencies, provenance, and data flow relationships are invisible to the security model.
5. 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.

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.

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.

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 . The Secure Object Identity model, contextual access chain, and capability token attestation are strong candidates for alignment with RATS Entity Attestation Tokens (EAT).

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 .

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 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.

High-Level Architecture

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.

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

Workspace Folder Structure A conformant AegisFS workspace MUST maintain the following logical structure:

Octal to OpCode (OtO) Framework

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.

OpCode Bit Field Structure The OtO OpCode is a 9-bit value expressed in octal notation with three 3-bit fields: Policy engine evaluating a WRITE on an ACTIVE object. ]]>

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 / DEPENDENCY	Graph reads and writes
0o7xx	FORENSICS / AUDIT	Audit log writes and queries

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

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

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

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.
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}.

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:

1. Immediately return DENY without further evaluation.
2. Write a fault audit record with the malformed opcode.
3. Increment the principal's anomaly score.
4. Notify the behavioral risk engine.

Aegis Policy Language (APL) — Policy-Driven Architecture

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:

1. Declarative: Policies express WHAT is permitted, not HOW to enforce it. The runtime translates declarations to OtO opcodes.
2. Strongly typed: All identifiers have declared types; type mismatches are compilation errors, not runtime failures.
3. Deterministic: Given the same policy and context, APL MUST always produce the same OtO opcode and enforcement decision.
4. Non-Turing-complete: APL deliberately excludes loops and arbitrary computation. All policies terminate in bounded time.
5. Auditable: Every APL compilation event MUST be logged with the policy hash, compiler version, and resulting opcode set.

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

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
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

APL Compilation Model APL source MUST be compiled before deployment. The compilation pipeline: 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.

APL to OtO OpCode Translation The APL compiler generates an opcode authorization table during compilation. Each table entry maps: 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 ]]>

Full APL Example The following is a complete, production-grade APL workspace policy:

Identity and Context Engine

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:

Context Evaluation Attributes An access decision MUST evaluate ALL of the following:

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

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.

Dynamic Contextual ACL Engine Unlike traditional static ACLs, AegisFS implements Dynamic Contextual ACLs (DCALs). A DCAL entry takes the form: 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. ACL evaluation follows a DENY-by-default model:

1. If no PERMIT rule matches the current context, DENY.
2. If a DENY rule explicitly matches, DENY (overrides PERMIT).
3. If multiple PERMIT rules match, grant the union of permissions ONLY IF no DENY rule conflicts.
4. All evaluations are logged regardless of outcome.

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

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.

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: Continue; update audit log. +-- DEVIATION --> INTENT VIOLATION Actions: RESTRICT, REVOKE CAPABILITY, QUARANTINE OBJECT, GENERATE ALERT, REQUIRE HUMAN APPROVAL ]]>

Object Lifecycle State Machine Every AegisFS File Object MUST exist in exactly one of eight lifecycle states. Valid transitions are: 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. ]]>

Transaction and Versioning Engine Modifications to objects MUST be performed within an atomic transaction: 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.

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.

Dependency Graph Engine When a modification is requested on any object, the engine MUST:

1. Query the dependency graph for all objects consuming or referencing the target.
2. Compute the full transitive impact set.
3. Report the impact set to the principal before permitting modification.
4. Evaluate whether dependent objects' policies require revalidation, testing, or approval before the change commits.

Metadata Engine Every AegisFS File Object carries a mandatory metadata block: Any modification to metadata MUST occur within a transaction, recompute the metadata_hash, and log the change event.

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.

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.

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.

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.

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.

Secure Object Identity An AegisFS File Object MUST NOT be identified by filesystem path alone. Object identity is composed of: If a file is renamed, its object_id and identity remain unchanged. This model aligns with the RATS concept of stable Endorsement targets whose identity persists across environment changes.

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.

AI Intelligence Layer

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).

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.

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.

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.

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.

Autonomous Incident Response Engine The engine executes bounded, policy-defined automated responses: LOG, ALERT, RESTRICT, REVOKE_CAPABILITY, FREEZE_WRITES, SNAPSHOT, QUARANTINE, REQUIRE_APPROVAL. 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.

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.

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.

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.

Complete End-to-End Operational Lifecycle The following describes the complete lifecycle of a single protected file operation request across 25 steps:

Security Considerations

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.

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.

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.

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.

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.

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.

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.
• 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.

References Normative References Informative References

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
0o747	AUDIT	ACTIVE	DESTROY	Requires human approval

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) ") SP value / condition-expr SP "and" SP condition-expr / condition-expr SP "or" SP condition-expr resource-block = "resources" SP "{" NL *resource-stmt "}" NL 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 ]]>