BASIC Security Model in AI & Cloud
- BASIC Security Model is a dual-purpose framework, serving as a specific five-part runtime model for agentic AI and as a foundational security approach in cloud and research software contexts.
- It employs five key components—Behavior certificates, Authenticated prompts, Security boundaries, In-context defenses, and Codified policies—to maintain context window integrity and combat prompt injection.
- The model emphasizes runtime security, agent self-defense, and self-sufficiency while addressing challenges like token overhead and potential security misconfiguration risks.
The term BASIC Security Model is used in more than one way across the cited literature. Its most explicit named use appears in work on agentic AI and LLM-powered applications, where BASIC denotes Behavior certificates, Authenticated prompts, Security boundaries, In-context defenses, and Codified policies, and functions as the foundation of the A2AS runtime security framework (Neelou et al., 8 Oct 2025). In other contexts, however, “basic security model” refers more generically to a foundational cloud-security framework organized around SaaS, PaaS, IaaS, integrated Security and IdAM, and the confidentiality, integrity, and availability objectives (Shah et al., 2013), or to a baseline maturity-oriented understanding of research software security rather than a fixed formal rubric (Heiland et al., 2013). The phrase therefore has both a specific acronymic meaning and a broader foundational one.
1. Terminological scope and conceptual range
In the A2AS paper, BASIC is a compact acronym and a security model in its own right. The paper defines it as a set of security primitives for behavior certification, context window integrity, and secure model reasoning, and treats A2AS as an implementation of that model (Neelou et al., 8 Oct 2025). This is the clearest instance in the cited corpus where BASIC Security Model is introduced as a named framework.
Other papers use the expression differently. In cloud computing, the phrase “basic security model” is not presented as a formally named standalone model with a mathematical definition, but as a foundational cloud architecture structured by SaaS, PaaS, and IaaS, with a cross-cutting Security and IdAM layer evaluated through confidentiality, integrity, and availability (Shah et al., 2013). In research software security, the position paper does not define a formal “BASIC Security Model,” but argues that security is “not a binary, all-or-nothing attribute, but a range of practices and requirements depending on how the software is expected to be deployed and used,” and that a maturity model should “lay out levels of security requirements and the software engineering and maintenance practices that meet those requirements” (Heiland et al., 2013).
This suggests that the term has two distinct encyclopedic uses. In one use, BASIC is a specific five-part runtime model for AI agents. In the other, “basic security model” denotes a baseline or foundational security framework whose content depends on the domain.
2. BASIC as the foundation of A2AS
Within agentic AI, the BASIC Security Model is introduced to address a structural weakness: LLMs process trusted internal instructions and untrusted outside content in a unified context window without clear security boundaries (Neelou et al., 8 Oct 2025). The paper treats this as the core reason that modern LLM systems are intrinsically vulnerable, and argues that the problem becomes more severe when the model can use tools, call APIs, read files, send messages, and coordinate with other agents.
The model is grounded in three pillars: runtime, self-defense, and self-sufficiency. “Runtime” means that security must apply during execution and in the runtime environment. “Self-defense” means that the model’s own reasoning should be used to understand security rules and boundaries natively in the context window. “Self-sufficiency” means that the security architecture should avoid complex orchestration and dependence on external models or tools (Neelou et al., 8 Oct 2025).
The A2AS paper repeatedly compares its framework to HTTPS securing HTTP. In that analogy, BASIC defines the essential runtime controls, while A2AS supplies the operational layer that enforces certified behavior, activates model self-defense, and ensures context window integrity (Neelou et al., 8 Oct 2025). The paper also frames the model as avoiding latency overhead, external dependencies, architectural changes, model retraining, and operational complexity, although these are stated as properties of the framework rather than established through benchmark tables in the text (Neelou et al., 8 Oct 2025).
3. The five components
The BASIC acronym expands into five runtime controls (Neelou et al., 8 Oct 2025).
| Component | Security function | A2AS module |
|---|---|---|
| B | Behavior certificates enable behavior enforcement | a2as.behavior |
| A | Authenticated prompts enable context window integrity | a2as.integrity |
| S | Security boundaries enable untrusted input isolation | a2as.boundary |
| I | In-context defenses enable secure model reasoning | a2as.defense |
| C | Codified policies enable application-specific rules | a2as.policy |
Behavior certificates define and enforce what an agent is allowed to do. They provide action permissions and operational constraints for tools, files, functions, and other resources. The paper describes them as enabling developers to declare operational boundaries and capabilities, and also as a kind of “bill of materials for AI agents.” Enforcement occurs through function-level controls that inspect tool-calling parameters, resource access requests, and other system operations in the runtime environment (Neelou et al., 8 Oct 2025).
Authenticated prompts are intended to validate external inputs for integrity and authenticity before the model processes them. The a2as.integrity module computes integrity hashes using prompt-specific information such as origin, content, and metadata, and prompt records can carry hash-like identifiers directly in the prompt structure (Neelou et al., 8 Oct 2025).
Security boundaries isolate untrusted external inputs from trusted system instructions within the context window. The a2as.boundary module wraps external inputs in tags such as <a2as:user:...> and <a2as:tool:...>, indicating origin and trust level. The paper treats this segmentation as foundational to the other controls (Neelou et al., 8 Oct 2025).
In-context defenses use the model’s own reasoning to perform self-protection. The a2as.defense module inserts meta-instructions telling the model that content inside <a2as:user> and <a2as:tool> tags is untrusted, that instructions from tools or agents should not be followed by default, and that prompt injections, jailbreaks, and unsafe requests should be prevented (Neelou et al., 8 Oct 2025).
Codified policies provide application-specific rules that align model and agent behavior with business, legal, or domain requirements. The a2as.policy module defines policies with rules, states, and behaviors, and these policies can be written in a domain-specific language or in natural language. The paper presents them as policy-as-code, supporting versioning, testing, transparency, and updates across environments without changing the underlying model or architecture (Neelou et al., 8 Oct 2025).
4. Threat model and enforcement architecture
The A2AS paper centers its threat model on prompt injection, understood as exploitation of the fact that trusted system instructions and untrusted external inputs coexist in the same context window without clear security boundaries (Neelou et al., 8 Oct 2025). It also emphasizes untrusted input isolation, context window integrity, agentic behavior control, and certified behavior as the primary security problems.
Three concrete attack classes are given. In a user-to-agent scenario, malicious invoice content can alter bank-account details and create risk of fraudulent transfers. In an agent-to-tool scenario, a malicious email can attempt to induce the assistant to extract CRM data and email it out. In an agent-to-agent scenario, a malicious payload in logs can propagate between agents and create prompt-infection or ransomware-like effects (Neelou et al., 8 Oct 2025).
The enforcement architecture is divided into two layers. Function-level controls act in source code and runtime, inspecting tool-call parameters, resource access requests, and other system operations. These controls are most strongly associated with Behavior certificates. Context-level controls act through prompt instrumentation and ensure context window integrity and secure model reasoning (Neelou et al., 8 Oct 2025).
Within context-level controls, the paper distinguishes prompt-bound controls and context-wide controls. Prompt-bound controls are Authenticated prompts and Security boundaries; context-wide controls are In-context defenses and Codified policies. The managed prompt template can include <a2as:user>, <a2as:tool>, <a2as:hash>, <a2as:defense>, and <a2as:policy> elements, so that provenance, segmentation, defensive instructions, and application rules are all represented in the context itself (Neelou et al., 8 Oct 2025).
5. Broader uses of “basic security model”
Outside agentic AI, the phrase usually denotes a foundational security architecture rather than the BASIC acronym. In cloud computing, the “basic security model” consists of a layered cloud architecture with Software, Platform, and Infrastructure, a cross-cutting Security and IdAM layer, and evaluation through confidentiality, integrity, and availability (Shah et al., 2013). The cloud paper explicitly treats confidentiality as a prime constraint, integrity as applying both to storage and computation, and availability as the “most important concern” for users (Shah et al., 2013).
In research software security, the phrase points toward a baseline maturity level rather than a fixed technical stack. The position paper argues that software “intended to be run as a service on production infrastructure” should meet a higher bar than a one-off prototype, and that a maturity model should provide a well-defined taxonomy, a roadmap, and requirements that are specific, measurable, and reasonable (Heiland et al., 2013). A plausible implication is that “basic” in this literature names an entry point in a progression rather than a terminal security state.
Foundational formal security-model literature provides another related sense of “basic.” Bell–LaPadula is presented as the first formal model of a secure system, centered on confidentiality-preserving access control, security labels, and state invariants such as the security condition and the -property (Cristia et al., 2020). A later paper argues that Bell–LaPadula was originally based on a partial order among labels rather than on full lattice theory, and that many real access-control and data-flow policies are naturally partial orders but not lattices (Logrippo, 12 Sep 2025). This suggests that, in formal methods, “basic security model” often refers to the minimal mathematical structure needed to govern secure flow.
A related foundational direction appears in the Security Capability Model, which abstracts the basic concepts related to rules, conditions, actions, events, policies, default actions, evaluation, and resolution strategies in order to capture what security controls can do (Basile et al., 2024). Here again, “basic” refers to primitive policy-building blocks rather than to the BASIC acronym.
6. Limitations, ambiguities, and open directions
The A2AS paper explicitly lists several limitations of the BASIC Security Model as currently presented: token usage overhead, security reasoning drift, capacity-constrained reasoning, security misconfiguration risk, and a multimodal coverage gap (Neelou et al., 8 Oct 2025). It also states that the paper contains very little formal mathematical notation and does not provide formal proofs, algorithms, state machines, or security-property theorems in the usual academic sense (Neelou et al., 8 Oct 2025). The framework is therefore presented as a runtime security architecture and set of primitives, not as a theoremized security calculus.
The broader literature shows similar ambiguity. The cloud-computing paper says that its “basic security model” is not introduced as a formally named standalone model with a mathematical definition (Shah et al., 2013). The research-software paper is a position paper, not a fully specified model (Heiland et al., 2013). Even in the more formal traditions, foundational models such as Bell–LaPadula or partial-order confidentiality models are not presented under the BASIC acronym (Cristia et al., 2020).
At the same time, the A2AS paper advances a clear standardization ambition. It presents A2AS as architected toward an open and universal AI runtime security layer and behavior certification standard, with likely standardization targets including behavior certification schemas, prompt authentication format, security boundary namespaces and tags, policy representation, and runtime enforcement semantics (Neelou et al., 8 Oct 2025). A plausible implication is that the term BASIC Security Model may increasingly stabilize around the agentic-AI meaning if that standardization effort succeeds. Until then, the phrase remains context-dependent: in AI it names a specific five-part runtime model, while in other domains it denotes a baseline or foundational security construction rather than a single canonical theory.