Foundational Concepts

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

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

Purpose and status

OSAFIS proposes a vocabulary for describing security failures in intelligent systems and the evidence needed to assess them. Its unit of analysis is a deployed or specified system in an operational setting. A model, an application, a human approval process, and a network of cooperating services can each contribute to the same failure. A useful account must identify their actual relationships rather than attribute every consequence to the model.

The definitions below are conventions of this proposal. They do not establish that its categories are exhaustive, mutually exclusive, or empirically superior to other approaches. Their value depends on whether independent assessors can apply them consistently, produce useful tests, and identify actionable controls. Requirements stated here govern an assessment claiming to apply this draft; they are not claims that any implementation has satisfied them.

Intelligent systems and the assessment boundary

An intelligent system is a computational system that interprets inputs, produces judgments or outputs, or selects actions using learned or explicitly specified inference procedures. It may include models, conventional software, knowledge resources, observations, retained state, planning, tools, humans, and physical devices. It need not possess every function, maintain long term memory, or act autonomously. These characteristics determine assessment scope rather than eligibility by product label.

The system boundary identifies the components and relationships included in a claim. Its environment includes relevant actors, dependencies, resources, and conditions outside that boundary. An external service may be outside implementation control while remaining inside the causal account. Assessors must state who controls each element, which versions and configurations are examined, and which environmental assumptions support the claim. A result obtained from an isolated model endpoint does not automatically characterize a deployed workflow using that model.

The preferred representation is a graph of actual components, humans, shared services, and resources. Nodes may implement several security domains. Edges are typed as observation, information, instruction, authority delegation, action, state synchronization, feedback, or resource dependency. An edge can carry more than one explicitly identified relation. Receiving information does not itself grant authority. Shared nodes must remain visible: drawing a separate copy of one shared memory service for every agent would conceal a common dependency. Some failures concern a group or subgraph rather than one component or pairwise edge.

Security contracts and protected properties

A security property names a kind of obligation, such as Confidentiality or Objective Integrity. A security contract instantiates that obligation for a particular object or relationship. It states the protected object, authorized principals, permitted changes or effects, relevant operating conditions, and an observable criterion for violation. The contract must precede the evaluation result; defining it after seeing an unwanted output invites circular classification.

For example, “the system must be safe” is insufficient. A more assessable contract could require that a document review service disclose records only to the requesting account, use retrieved documents as evidence rather than as authority to change the task, and obtain the designated approver's authorization before sharing a report. Each clause supplies a separate potential failure criterion. The policy owner must specify what counts as an account match, valid task change, and approval.

P01–P23 in Security Properties provide reusable property definitions. They are neither a mandatory checklist of universally applicable functions nor an assertion that all obligations have been identified. Several properties can apply to one contract. A more specific property normally provides a more informative label than generic Integrity; independent failures should still be recorded separately. A property identifier is a reference to a definition, not evidence of protection.

Authorized objectives and contested goals

An authorized objective is a task or outcome established by a principal entitled to set it, within the governing constraints and delegation applicable to that system. Its source must be recorded: for example, a deployment policy issued by the responsible organization, a valid request from an authenticated user, and the limited authority granted to a service acting on that request. The precedence among these sources is a deployment decision that must be made explicit. The framework does not assume a universal ordering of all developers, operators, users, affected people, and external authorities.

Authorization concerns both entitlement and scope. A genuine user's request does not necessarily authorize every means of accomplishing it or every effect on another person's resources. Retrieved content, remembered statements, and another agent's message cannot change an objective merely by claiming urgency or authority. Conversely, a legitimate authorized change is not an integrity failure simply because the task changes.

Goals can conflict or be underspecified. The assessment should record the competing requirements, the designated decision owner, and the permitted resolution procedure. Where a consequential action depends on unresolved authority, the contract should define a pause, escalation, or restricted fallback. Assessors should report an unresolved governance assumption when no such rule exists, rather than inventing the “true” objective. Objective Integrity protects the established authorization relation; it does not certify that an authorized objective is ethical, lawful, or desirable. Those questions require their own substantive criteria and accountable review.

Threats vulnerabilities attacks and incidents

A threat is an actor capability, condition, event, or circumstance that could defeat a security contract. A threat model identifies who can influence what, what they know, what access they possess, and what constraints limit them. It can also describe nonadversarial disturbances relevant to the same contract. An attacker is not presumed merely because a failure occurred.

A vulnerability is a weakness in a component, configuration, process, or relationship that permits a security contract to be violated under stated conditions. Evidence must connect the weakness to the violation or establish a sufficiently supported feasible path. Unusual text, an incorrect answer, and a dangerous possibility are not by themselves vulnerability demonstrations. A quality defect concerns failure against a performance expectation; it can also be a security weakness when it defeats a defined protection. A hazard is a condition with the potential to cause harm. An incident is an actual event with security relevance or impact. These categories can overlap without becoming synonyms.

An attack technique is a method of exercising influence to exploit a weakness. An exploit is a concrete execution or implementation of such a technique against a specified target. A mechanism describes how the influence operates at a useful level of abstraction. Attack Taxonomy separates mechanisms, families, techniques, and modifiers; the M01–M12 identifiers retain their canonical meanings. Naming a mechanism does not establish the existence, novelty, or exploitability of a vulnerability.

A benign fault can demonstrate a contract failure without establishing an adversarial exploit. For example, a delayed authorization update can expose a stale permission check even if nobody intentionally caused the delay. The assessment must distinguish the observed trigger from any hypothesized attacker capability to reproduce it. This permits security and safety evidence to inform one another without fabricating an adversary.

Domains dimensions lifecycle and impact

The legacy term “layer” is retained in identifiers L1–L9, but denotes a provisional analytical security domain. A domain groups protected objects, functions, or relationships with related contracts. The domains are Models & Computation; Software & Infrastructure; Data & Knowledge; Perception & World Representation; Interpretation & Objectives; Memory & State Continuity; Planning & Action; Human–System Interaction; and Collective & Systemic Interaction.

These domains are not execution steps, severity levels, or a progression of consequence scope. Nine is a working partition to be evaluated. Functional applicability matters: a text based agent can estimate a changing digital environment, while a multimodal application may have no retained operational memory. An assessor may assign several domains to a component or leave a classification unresolved with a reason. Security Layers gives boundaries and discriminating questions.

A cross cutting dimension is a perspective that can inform contracts in several domains. D1 is Identity, Trust & Authorization; D2 Governance & Accountability; D3 Supply Chain & Provenance; D4 Privacy & Safety; D5 Lifecycle & Change Management; D6 Observability, Logging & Auditability; and D7 Resilience & Recovery. Applicability and evidence vary by context. Dimensions neither replace domain classification nor constitute additional layers.

Lifecycle phase and impact scope are separate descriptors. A weakness introduced during training may be triggered during operation and discovered during retirement. Its consequences may affect an individual, an organization, interconnected services, or a wider population. Large impact does not, by itself, establish L9: that domain requires a distinct collective interaction contract and a specified coupling mechanism. A compromised shared model can have broad consequences while its demonstrated failed contract remains in L1.

Causal paths and composition

An attack path connects an initial influence to a security consequence through observed or hypothesized transitions. A causal failure path is the broader term when malicious intent is absent or unknown. The record should separate entry point, failed contracts, intermediate propagation, controls encountered, and resulting impact. An edge traversed without violating its contract is part of propagation, not an additional vulnerability.

Paths need not be linear. Feedback loops, delayed state, parallel requests, and shared dependencies may require a subgraph with a timeline. Several independent contract failures can contribute to one incident. Selecting one primary domain for indexing is optional and must not suppress other supported failures. Conversely, applying several labels to the same obligation should not multiply the number of findings.

Consider an illustrative, unexecuted scenario: a retrieved report contains a false instruction to change the recipient of a summary. The report enters as information; the interpreter treats it as authority; a proposed send operation passes an inadequate recipient check. The entry point is the report. The potential instruction authority failure is in L5, and the independently inadequate action check is in L7. Merely retrieving and conveying the report does not prove an L3 failure. A valid recipient check would interrupt the path even if the interpretation failure remained.

Evidence and assessment claims

Evidence consists of observations, artifacts, and reasoning supporting a specified claim. Sources may include inspection, controlled experiments, incident records, reproductions, and independent replication. Each supports different conclusions. An observed failure may establish that a path is possible without estimating its frequency; a plausible architectural argument may justify testing without demonstrating exploitation. Evidence must preserve the relevant configuration, inputs, state, expected condition, actual observation, and limitations sufficiently for independent review where feasible.

An oracle is a rule or observation used to decide whether a contract was violated. A test should state its oracle, baseline, threat capabilities, negative controls, and stopping conditions. Negative controls help distinguish the proposed mechanism from ordinary task variability or an unrelated weakness. Instrumentation should observe decisions and effects needed for the claim without assuming access to reliable private reasoning. Tests proposed in this corpus are illustrative and unexecuted unless accompanied by a separate execution record.

Confidence describes how strongly the evidence supports a claim. Reproducibility concerns recurrence under specified conditions; repeatability in one setup is narrower than independent replication. Coverage describes the portions of a defined threat and operating space examined. None is interchangeable with severity, and no finite evaluation establishes zero risk. Assessment Methodology specifies the study record; Vulnerability Registry specifies the claim and review record.

Risk severity reversibility and controls

Risk concerns the possibility and consequences of a security loss in a specified context and time horizon. It depends on exposure, threat capability, system behavior, controls, and uncertainty. Severity describes the consequence of a specified successful failure under stated assumptions. A severe possible consequence may have weak supporting evidence or limited exposure. These facts must remain separately visible; this draft does not prescribe a universal scalar or multiplication of ordinal labels.

Reversibility concerns an action's effects under particular recovery conditions. Restoration, containment, and compensation are distinct: restoring a file does not undo its disclosure, and paying compensation does not restore an injured person. Recovery can be partial and time limited. Assessors should identify the point at which the relevant effect becomes irreversible, who can intervene before it, and what remains recoverable afterward.

Probabilistic evidence remains meaningful for irreversible harm. Irreversibility changes acceptable decision rules and the need for containment; it does not make likelihood meaningless or imply that estimating a rate accepts the harm. Rare or catastrophic outcomes require particular caution about sparse observations, dependence, distribution change, and unobserved paths. Tests should use simulation, inert substitutes, or contained environments where actual effects would be unacceptable.

A security control is a technical, procedural, organizational, or operational measure intended to preserve a contract or detect and limit its violation. A mitigation reduces exposure, likelihood, propagation, or impact without necessarily eliminating the weakness. Controls need their own assumptions and verification; a documented approval requirement is not evidence that execution is gated by approval. Residual risk and displaced failure paths remain part of the assessment.

Evolution and citation

An emerging vulnerability class is a candidate grouping whose protected obligation or mechanism is not adequately represented by existing definitions. A proposal should explain the classification difficulty, compare neighboring categories, present evidence, and allow independent challenge. Ambiguous cases are useful evidence about the framework's boundaries; they should not be forced into a familiar label to preserve apparent completeness.

Every classification must cite the framework version and stable identifiers. Versioning and Identifiers governs changes and migration. The source corpus labeled 1.0 supplies the historical baseline; that label does not establish public release. This revision changes domain boundaries and therefore requires human review of affected prior classifications. Scientific value depends on preserving what the evidence actually supports, including uncertainty, rather than on preserving the appearance of a complete taxonomy.