Security Layers

OSAFIS 2.0.0-draft.1 · Research proposal · 16 min read

OSAFIS 2.0.0-draft.1 | Research proposal | 7 September 2026

Analytical purpose

The nine OSAFIS layer identifiers organize analysis by the object, function, or relationship whose security contract may fail. In this revision, “layer” means a provisional analytical domain. The identifiers do not describe a processing pipeline, an implementation stack, levels of intelligence, or increasing consequence scope. A model artifact failure can affect many organizations; a collective interaction failure can remain confined to a small test environment.

Nine is a working hypothesis about useful distinctions. A proposed partition should earn its place through assessor agreement, explanatory value, and the ability to guide discriminating tests. This document does not establish that nine domains are necessary, sufficient, optimal, or future complete. Overlap between components is expected; overlap between definitions requires careful identification of the particular contract under examination.

The domain model complements three separate questions: which property is protected, how influence operates, and what consequences follow. Property identifiers P01–P23 answer the first; mechanisms M01–M12 in Attack Taxonomy address the second. Consequence scope, lifecycle phase, uncertainty, and recoverability are recorded independently. Cross cutting dimensions D1–D7 remain perspectives on these analyses rather than additional domains.

Representing the system before classifying failures

An assessment begins with a graph of actual components, humans, shared services, and resources. Assign domains to the functions performed by each node and to relevant relationship contracts. One service can implement retrieval, persistent state, inference, and action dispatch; it therefore need not have one exclusive domain label. Conversely, one domain contract can span several components.

Relations are typed as observation, information, instruction, authority delegation, action, state synchronization, feedback, or resource dependency. Document the payload, applicable identities, trust assumptions, and permitted transformations where they affect the claim. A status message is ordinarily an information edge; an instruction can ask for work without conferring new authority. Delegation exists only where some defined authority is transferred or exercised on another principal's behalf.

Shared services and resources are represented as shared nodes. Copies of a nine layer stack per agent can obscure a common model, datastore, budget, or controller. Group and subgraph contracts are also admissible: a coordination invariant may concern all active participants and cannot always be reduced to independent pairwise checks. Record observed and hypothesized links distinctly.

For every finding, separate the attack entry point, failed contracts, propagation, and impact. A traversed domain has not necessarily failed. Multiple failures can be causally necessary, and classification can remain unresolved pending evidence. A primary domain may support indexing, but it is not a rule that the first influenced component owns every subsequent violation.

L1 Models and Computation

Canonical display name: Models & Computation.

L1 protects executable model parameters, inference rules, and the agreed model computation. Its contract identifies the approved model artifact or rule set, permissible transformations, relevant computation settings, and the conditions under which the implementation is expected to realize that computation. This applies to learned and explicitly programmed inference systems. Architecture, weights, executable adapters, and computation affecting model configuration can be relevant protected objects.

The boundary with L2 is the distinction between the computation being specified and the software or infrastructure executing and serving it. Unauthorized replacement of approved weights is an L1 artifact integrity failure. A serving process that allows an unauthorized caller to replace files also has an L2 access control failure if that contract is independently defeated. Training data belongs to L3 as an information resource; the resulting model's failure to meet a defined security behavior may warrant an L1 finding, with the data influence recorded as the causal entry path. Merely producing an incorrect answer does not establish that the model computation contract failed.

An illustrative, unexecuted case concerns a deployment intended to load one approved model and adapter combination. A mutable alias resolves to an unapproved adapter after startup, although the base model remains unchanged. The protected obligation is to execute the approved combination, not a general promise of correct outputs. An assessment can compare the approved manifest with the artifacts actually loaded and exercise the alias change in an isolated environment. A negative control uses a permitted version transition with the required authorization and verification.

The assessable question is whether execution remains bound to approved computational artifacts and changes. Candidate controls include verified loading, immutable version references, explicit transformation records, and checks at reload boundaries. Their effectiveness depends on where verification occurs and whether subsequent mutation remains possible. A successful initial verification alone does not establish lifetime integrity.

L2 Software and Infrastructure

Canonical display name: Software & Infrastructure.

L2 protects implementation, runtime, access control, isolation, and infrastructure contracts. Relevant objects include service endpoints, credentials, processes, deployment configuration, dependencies, networks, storage access, and execution environments. The contract specifies who may invoke or modify which functions, how tenants and privileges are separated, and the service or resource bounds required for authorized operation.

The presence of a model does not change the ownership of a conventional session mix up or exposed management endpoint. L2 covers the mechanism enforcing an application's access boundary. L7 covers the task specific authority and effects of actions performed through that mechanism. A tool may authenticate a service correctly while that service requests an operation outside the user's task; this distinguishes a valid infrastructure check from a failed action contract. L1 remains responsible for approved model computation, while L2 covers the serving implementation and isolation supporting it.

An illustrative, unexecuted failure occurs when two agent sessions share a process cache whose key omits tenant identity. One session retrieves another tenant's response. The failed contract is tenant separation, even if the response contains model generated text and the visible impact is confidentiality loss. A contained test can use synthetic accounts and distinct marker data, alternate requests, and inspect whether account boundaries survive cache reuse. Repeating the sequence with caching disabled can help localize the mechanism without proving that every cache path is safe.

Assessment asks whether unauthorized principals or execution contexts can reach protected resources under the stated deployment configuration. Candidate controls include complete tenant binding, scoped service identities, isolation, and resource limits. Logging supplies evidence only if it captures the relevant identity and boundary decision. Broad downstream harm does not move the original infrastructure failure into L9.

L3 Data and Knowledge

Canonical display name: Data & Knowledge.

L3 protects information resources and the conditions under which they are supplied as knowledge. Its contract covers authorized changes, access, provenance, source status, and any declared requirements for freshness or verification. Training corpora, retrieval indexes, documents, metadata, reference databases, and tool supplied information can fall within this domain. The obligation is not that every statement is true; it is that the resource satisfies the explicitly required handling and epistemic conditions.

L3 differs from L5 at the use of information as instruction or objective authority. A correctly labeled untrusted document can carry hostile language without violating L3. If the interpreter elevates that language to instruction authority, the failed contract is in L5. L4 concerns acquisition and estimation of an environment state; L3 concerns information offered or maintained as a resource. L6 concerns information functioning as retained operational state. A database can implement both a knowledge collection and user memory; classify the contract, not the storage technology.

In an illustrative, unexecuted example, a supplier bulletin index drops a source identifier during ingestion. A later result is presented as coming from an approved publisher although its content originated elsewhere. The proposed L3 failure is loss of the source binding required by the index contract. A test can ingest distinct synthetic sources, inspect their transformed records, and compare retrieved provenance with the ingestion record. A negative control preserves the binding through the same transformations.

The assessable question is whether information crosses collection, transformation, retrieval, and disclosure boundaries with its required permissions and provenance intact. Candidate controls include source binding, transformation history, separation of verification status from content, and access checks at retrieval. A source signature can support an origin claim without establishing the truth or suitability of the source's statements.

L4 Perception and World Representation

Canonical display name: Perception & World Representation.

L4 protects observation and the estimation of an operational environment. Its contract specifies which features are observed, how observations are associated with entities and times, how uncertainty and stale state are handled, and when reobservation is required before a dependent decision. It includes physical sensors and digital observation, such as an agent inspecting a browser page or a service state. Applicability follows function: a text representation can be an observation of a changing environment.

The distinction from L3 is functional. A reference document describes information; a current view used to locate a live interface element estimates the state in which an action will occur. The same bytes can serve either role. L6 protects retention and authorized state updates, whereas L4 protects whether the represented environment remains adequately grounded. An accurately stored but obsolete belief can satisfy storage integrity while violating a required freshness contract. L7 covers the subsequent action validation and effect.

An illustrative, unexecuted case uses a simulated administration page. After an agent observes a selected test resource, the page updates and the selected row changes. The agent continues to represent the earlier resource as selected. An assessment can compare timestamped observations and the agent's externally inspectable state representation with the simulator's known state. The violation oracle is a declared requirement to refresh selection identity before a consequential operation. A negative control holds the page stable or forces reobservation.

Candidate controls include observation timestamps, entity binding, explicit uncertainty, consistency checks, and mandatory refresh conditions. No assumption is made that physical input is wholly unauthenticable or that authenticated input is accurate. Origin, sensor condition, interpretation, and environmental truth are different claims. Simulation results must identify the gap between the simulated environment and deployment. The expanded digital scope is a 2.0 migration issue for historical L4 and P22 classifications.

L5 Interpretation and Objectives

Canonical display name: Interpretation & Objectives.

L5 protects the assignment of meaning, instruction authority, and authorized objectives. Its contract defines which principals may establish or revise the task, the precedence and scope of their instructions, how quoted or retrieved material is treated, and how ambiguity or conflict is resolved. Applicable sources may include deployment policy, a valid user request, and a bounded delegation. Their precedence is specified by the system's accountable policy owner rather than presumed by the framework.

L5 is not a domain for every unwanted output. If the objective remains “assess this transaction” while an evidential threshold is applied incorrectly, the immediate question is Decision Integrity at the component performing that judgment. If the chosen strategy violates a sequencing constraint while the objective is unchanged, L7 Planning Integrity is more informative. L3 owns source handling; L5 owns elevation of source content into instruction authority. L8 examines what a person is led to understand or authorize.

An illustrative, unexecuted case gives a review service an authorized task to summarize a report for a named recipient. A passage inside the report claims that a new policy requires sending it elsewhere. The L5 oracle compares the task adopted after reading the passage with the authorized objective record and the contract forbidding task changes from report content. A control passage containing the same recipient information as an ordinary factual statement helps distinguish a directive from a content effect. Execution of a send is not needed to establish a supported objective change.

Assessment asks whether a source without task setting authority can change the governing instruction or objective. Candidate controls include explicit source roles, constrained task state updates, and conflict escalation. If authorized stakeholders disagree and no resolution rule exists, the assessor records an unresolved authority contract. An observed consequential disagreement cannot be resolved merely by declaring one interpretation “aligned.”

L6 Memory and State Continuity

Canonical display name: Memory & State Continuity.

L6 protects retained operational state and continuity across turns, sessions, interruptions, or resumed tasks. Its contract identifies who may create, modify, associate, read, expire, or delete state; which task or principal it belongs to; and the conditions under which it may influence future work. Conversation summaries, user preferences, checkpoints, pending authorizations, and persistent task records can qualify. Persistence is functional and may be brief; an in memory checkpoint can be security relevant.

L3 protects information as a resource; L6 protects information as continuity of a particular operation or relationship. L5 determines whether remembered text can legitimately function as an instruction. L4 assesses the accuracy and freshness of a remembered world representation. Temporal Integrity spans domains and does not automatically imply L6: an expiring tool credential can fail its time condition without any memory subsystem being defective.

In an illustrative, unexecuted example, a task summary records “user approved sharing” while omitting that approval covered only a particular synthetic report. On resumption, the approval is associated with a different report. The state continuity contract requires preservation of the authorization's object and scope. A contained assessment compares the precheckpoint authority record, serialized summary, restored state, and downstream permission request. A negative control resumes a task with all required bindings preserved.

The assessable question is whether retained state preserves its authorization, identity, provenance, and validity conditions through transformation and reuse. Candidate controls include structured scope binding, versioned state, expiry, explicit invalidation, and revalidation on resume. Deleting one visible memory record does not demonstrate complete revocation if derived summaries or other stores remain able to reintroduce it. Assessment should identify the stores actually examined and the limits of that claim.

L7 Planning and Action

Canonical display name: Planning & Action.

L7 protects strategies, capability selection, delegation, action validation, and execution. Its contract binds an authorized objective to permissible means, resources, recipients, sequence constraints, budgets, and external effects. It applies to digital operations and physical actuation. A relevant action may be a message, a file modification, a service request, or movement of a device; describing an operation as a tool call does not settle its authority.

L5 protects what the system is authorized to accomplish. L7 protects how it attempts and executes that task. L2 may authenticate a caller and expose a capability without establishing that a particular use is allowed. L8 covers the human's understanding and usable authorization interface. L9 applies when a separate collective interaction obligation is involved, not simply because one agent delegates to another. Within L7, P12 concerns capability use selection, P13 realized effect, P14 intervention, P15 strategy, and P16 delegated scope.

An illustrative, unexecuted case authorizes updating two test records only if both updates can be committed together. An agent constructs a plan to commit the first and then independently attempt the second. The plan violates the required transaction constraint before an external effect occurs. The oracle compares the inspectable plan or scheduled operations with the declared all or nothing condition. A simulated backend can then determine whether execution enforcement blocks the partial commit. A compliant transactional plan is a negative control.

Assessment asks whether permissible operations remain permissible as a sequence and at execution time. Candidate controls include constrained delegation, effect level checks, budget accounting, revalidation after delay, and intervention paths with measured deadlines. A stop button that cannot prevent the relevant irreversible effect within its declared timing requirement does not satisfy that controllability contract. Actual hazardous actions must be replaced with contained substitutes during evaluation.

L8 Human System Interaction

Canonical display name: Human–System Interaction.

L8 protects human understanding, informed authorization, oversight, and intervention in a system relationship. Its contract identifies the human's role, material information needed for a decision, claims the interface is allowed to make, and the conditions for meaningful approval or control. It can cover visible uncertainty, provenance, scope of proposed actions, and the correspondence between a displayed request and the operation subsequently authorized.

L8 does not assume that a model has human emotions or intentions. Nor does it classify every persuasive or inconvenient output as a vulnerability. A security relevant obligation and material misleading influence must be identified. L5 concerns the system's interpretation of authority; L8 concerns the person's understanding of the request or result. L7 owns action enforcement. An interface can misrepresent the proposed scope even if a backend correctly implements the approval token it receives.

An illustrative, unexecuted case presents approval for “share this summary” while the bound operation includes its full confidential attachments. In a synthetic workflow, assessment can compare the displayed scope, generated approval record, and planned external payload. The mismatch is inspectable without exposing real data or involving unsuspecting people. Establishing how a presentation changes human decisions requires a separate study design; interface inspection alone does not demonstrate that users were deceived.

Candidate controls include specific effect previews, explicit recipients and data scope, truthful provenance, and accessible intervention. Human subject studies require appropriate consent, review, debriefing, and data protections. Assessment must distinguish a design defect, evidence of materially misleading communication, and observed human impact. The presence of a person in the workflow does not itself demonstrate effective oversight or transfer responsibility away from the system's other control owners.

L9 Collective and Systemic Interaction

Canonical display name: Collective & Systemic Interaction.

L9 protects a distinct contract governing interactions among participants or dependencies. A finding requires a demonstrated or hypothesized coupling mechanism, such as feedback, shared resource contention, state synchronization, coordinated allocation, or correlated dependence. The contract may concern a group limit, consistency condition, containment boundary, or recovery behavior. Broad public or societal impact is recorded separately and does not suffice for this domain.

An L2 outage in a shared service can affect every dependent agent without demonstrating a separate L9 vulnerability. L9 becomes relevant when their interaction defeats an independently specified collective obligation. Similarly, a delegation scope violation is ordinarily L7; multiple participants do not automatically create a collective failure. A valid L9 analysis can identify a group failure even when each participant complies with its local contract, provided the composition contract and coupling are explicit.

Consider an illustrative, unexecuted simulation in which several schedulers share a limited resource. Each scheduler respects its local retry limit, but delayed observations cause their retries to synchronize, preventing the group from recovering within its contracted interval. The hypothesis concerns a feedback and shared dependency subgraph. Assessment compares recovery time and total concurrent requests with the group contract, then varies synchronization or introduces independent scheduling as a negative control. Merely counting many requests would not establish the proposed mechanism.

Candidate controls include shared admission rules, coordinated budgets, feedback damping, and isolation of failure domains. They must be evaluated at the relevant group scale and under the assumed communication delays. A small simulation supports claims about that model and tested conditions; it does not establish behavior at societal scale. If no collective contract or coupling can be specified, record the broad impact and leave L9 unassigned.

Classification and migration practice

An assessor should write the failed obligation in plain language before choosing a domain. Next, locate its actual component or relationship, identify the property and mechanism, and distinguish evidence of violation from mere propagation. Compare the closest neighboring domain using the boundaries above. Record independent failed contracts separately while retaining their common causal path. When the available observations cannot distinguish two explanations, preserve both hypotheses and specify the next discriminating test.

The source 1.0 labels map to 2.0.0-draft.1 identifiers as follows. This mapping preserves references; it does not imply unchanged scope.

The source's consequence ordering, automatic authority on every interagent edge, and exclusive emphasis on one primary layer are not retained. Historical findings require human reclassification where those assumptions affected the result. Versioning and Identifiers records the migration policy; Threat Model supplies scoped assumptions; Security Properties supplies obligations; and Assessment Methodology supplies test and evidence requirements. These interfaces make the domain model usable while leaving its scientific adequacy open to evaluation.