5.3. OWASP AISVS
TozheBot: A Secure OS for AI Employees
Document Version: 1.0
Date: 2026-10-22
Scope of Assessment: TozheBot platform, agent layer, security layer.
Target Level: L2 across key categories (agentic system with access to tools and sensitive data); L1 where L2 is architecturally redundant.
Status: Active Policy
Control implementation model
In TozheBot, AISVS controls are implemented at three levels; each point below indicates which level it belongs to:
- Platform — A guarantee that TozheBot provides to all clients, regardless of their configuration: project-level isolation, QuarkDash encryption, OGL-Mini input validation, mandatory escalation, key rotation, and logging.
- Tenant — Configuration within the scope of a client project: which tools are provided to an agent, what data is accessible, the level of autonomy, and escalation thresholds. The platform sets an upper limit, and the client makes selections within that framework.
- Platform + Tenant — The control is provided by the platform but requires proper configuration on the client's side, and this must be documented.
This distinction is important for auditing: the answer to the question "how do you ensure isolation?" differs depending on whether you are referring to the platform level or the tenant level.
How to use this document
- Levels AISVS: L1 — basic; L2 — for systems involving sensitive data and operation in a hostile environment; L3 — for critical systems.
- Status: Met — approved with an artifact, Partial — a control exists, but it requires refinement or documentation., Gap — not controlable, N/A — not applicable, with justification.
- For each item, the following are specified: level, implementation model (platform / tenant / shared), evidence, status, and what needs to be added.
Category 0. AI Security Governance and Risk Management
0.1. Documented AI risk assessment methodology.
Level: L1. Model: Platform.
Applicability: Applicable. The documentation, specifically the standards compliance section, outlines how the platform operates in alignment with the NIST AI RMF (Govern, Map, Measure, Manage) framework, starting from the design phase.
Evidence: Internal Risk Register + Compliance and Monitoring section within the tenant-level control panel.
Status: Partial.
Action: A standalone "AI Risk Assessment Methodology" document, including a review process, is currently under development.
0.2. AI security policy, reviewed at least annually.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Internal Information Security Policy, approved on October 10, 2026, by the CTO of Neurosell (Ilya Sergeyevich Rastorguev).
Status: Met.
0.3. Roles and responsibilities for AI security.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Internal Information Security Policy, approved on October 10, 2026, by the CTO of Neurosell (Ilya Sergeyevich Rastorguev).
Status: Met.
0.4. Alignment with the NIST AI RMF or an equivalent framework.
Level: L2. Model: Platform.
Applicability: Applicable; the methodology has already been defined.
Evidence: Crosswalk between the NIST AI RMF and TozheBot controls.
Status: Partial.
Action: Create a crosswalk (the NIST AI RMF template from previously discussed materials may be used).
0.5. Process for monitoring regulatory changes (e.g., the EU AI Act, Federal Law No. 152-FZ).
Level: L2. Model: Platform.
Applicability: Applicable to the Russian and EU markets.
Evidence: Internal information security policy, approved on October 10, 2026, by the Technical Director of Neurosell (Ilya Sergeyevich Rastorguev). Regulatory changes are reviewed on a monthly basis.
Status: Met.
0.6. Risk management at the tenant-agent level.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable. Clients can create agents with varying access levels within a project; the platform must ensure that an agent’s configuration does not exceed the project’s defined risk profile.
Evidence: A mechanism for restricting agent configuration at the project level. The platform never grants access to data outside of a user’s tenant; the architecture for handling any data—even when agents are not in use—is filtered at the tenant level. When creating or modifying an agent, a user may select the tenant on which that agent operates.
Status: Met.
Category 2. User Input Validation
This category is primarily addressed by the OGL-Mini library, which features a three-tier pipeline—Heuristics → Mini-classifier → PII—with a latency ranging from 10 to 300 ms. The heuristics filter out zero-width characters, homoglyphs, control tokens, and jailbreak patterns, while the classifier is trained on the OWASP LLM01 S1–S9 categories and over 14 types of agent-based attacks.
2.1.3. All inputs capable of influencing the model's behavior are considered untrusted and are vetted by a prompt injection classifier.
Level: L1. Model: Platform.
Applicability: Fully applicable. OGL-Mini inspects all prompts prior to LLM processing, regardless of the agent or project created by the client.
Evidence: OGL-Mini source code (heuristics and classifier stages); logs containing fields for safety/risk status, processing stage, and latency. The system operates in a "soft" mode: initial detections result in the request being flagged as "unsafe," while subsequent detections lead to a complete restriction of access. These checks are active across all connectors, widgets, the operator dashboard, tool invocations, and RAG document queries.
Status: Met.
2.1.3. All inputs capable of influencing the model's behavior are considered untrusted and are vetted by a prompt injection classifier.
Level: L1. Model: Platform.
Applicability: Fully applicable. OGL-Mini inspects all prompts prior to LLM processing, regardless of the agent or project created by the client.
Evidence: OGL-Mini source code (heuristics and classifier stages); logs containing fields for safety/risk status, processing stage, and latency. The system operates in a "soft" mode: initial detections result in the request being flagged as "unsafe," while subsequent detections lead to a complete restriction of access. These checks are active across all connectors, widgets, the operator dashboard, tool invocations, and RAG document queries.
Status: Met.
2.1.4. Detection and blocking of attempts to override instructions.
Level: L2. Model: Platform.
Applicability: Applicable; OGL-Mini detects both goal hijacking and instruction overrides.
Evidence: Agentic synthetic dataset (22,500 examples) and validation metrics. Further details on the operation of the classifiers can be found in the library's repository.
Status: Met.
2.1.5. Adaptive protection against novel prompt injection techniques.
Level: L3. Model: Platform.
Applicability: Partially applicable. While heuristics and a model are in place, a formal process for updating rules is still required.
Evidence: OGL-Mini update procedure and model versioning.
Status: Partial.
Action item: Establish an SLA for updates in response to the emergence of new attack techniques.
2.2.1. Basic input sanitization.
Level: L1. Model: Platform.
Applicability: Applicable. Evidence: heuristics and the OGL-Mini classifier.
Status: Met.
2.3.1. Schema-based input validation.
Level: L1. Model: Platform.
Applicability: Applicable at the API level.
Evidence: Request schemas (OpenAPI / JSON Schema). Schemas are published in the API documentation:
Status: Met.
2.3.2. Type checking and length constraint validation.
Level: L2. Model: Platform.
Applicability: Applicable.
Evidence: Limit configuration. Base limits include a 4,000-character cap per message; data types are enforced at the language level (TypeScript) and via strict typing in PostgreSQL, supplemented by schema validators for input and output data. Users can define additional limits, such as the number of messages per day and the number of messages stored in an agent’s chat history.
Status: Met.
2.4.1. Content filtering for prohibited material.
Level: L1. Model: Platform + Tenant.
Applicability: Applicable. The platform provides a base filter, and clients can implement stricter policies within their specific projects.
Evidence: Core protection policies prohibit the use of illegal content—including requests related to dangerous activities, sexually explicit material, weapons, explosives, and other restricted categories. Administrators can further configure content filtering at the agent level.
Status: Met.
2.4.1. Content filtering for prohibited material.
Level: L1. Model: Platform + Tenant.
Applicability: Applicable. The platform provides a base filter, and clients can implement stricter policies within their specific projects.
Evidence: Core protection policies prohibit the use of illegal content—including requests related to dangerous activities, sexually explicit material, weapons, explosives, and other restricted categories. Administrators can further configure content filtering at the agent level.
Status: Met.
Category 4. Infrastructure, Configuration & Deployment Security
A key contribution here comes from QuarkDash: a hybrid post-quantum protocol (Ring-LWE + ChaCha20/Gimli) that features forward secrecy, replay protection, and automatic key rotation—all without disrupting active sessions. Also significant is the project-level isolation described in your architecture.
4.1.1. Isolation of containers and execution environments.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: The orchestrator is configured within a tenant context and cannot process a request without being bound to a specific tenant, as each tenant authorizes requests using JWTs and API keys. The schemas are published in the API documentation:
Status: Met.
4.1.2. Restriction of runtime privileges.
Level: L2. Model: Platform.
Applicability: Applicable.
Evidence: Manifests include a `securityContext`; agents operate only with a predefined list of permitted tools and are architecturally incapable of independently adding new tools or MCP servers. Furthermore, they are isolated from direct internet access. Privileges are configured by the user when connecting tools by defining "scopes" for specific services. Additionally, permissions can be restricted for individual users (based on roles and tenants) and for specific API keys (based on tenants, selected data collections, and CRUD scopes).
Status: Met.
4.2.1. AI hardware security (zeroing GPU memory between tenants).
Level: L2. Model: Platform.
Applicability: Applicable if GPUs are used.
Evidence: For GPU memory operations, data is isolated using "Shared-GPU" technologies, which provide isolation at the containerization and memory-virtualization levels within a single vRAM space.
Status: Met.
4.3.1. Encryption of data at rest and in transit.
Level: L1. Model: Platform.
Applicability: Applicable. QuarkDash covers the transmission and storage of sensitive fields; notably, field-level encryption does not interfere with validation or knowledge base search functionality.
Evidence: The QuarkDash protocol offers robust cryptographic strength while maintaining high performance. All critical data—including agent configurations, dialogues, user information, logs, and knowledge base content—is encrypted using the QuarkDash protocol, which incorporates dynamic key rotation. More details on the protocol:
Status: Met.
4.3.2. Key rotation with consideration for active sessions.
Level: L2. Model: Platform.
Applicability: Applicable; rotation does not disrupt sessions.
Evidence: Rotation procedure and encryption logging. Key rotation occurs dynamically every 24 hours. Keys are not stored directly; instead, the system retains data such as salts and other parameters used to initialize sessions via Argon2. The rotation interval may be extended for data that is accessed less frequently. Furthermore, even if an old key were compromised, it could not be used to decrypt the data, thanks to built-in protections against timing attacks. More details on the protocol:
Status: Met.
4.4.1. Secrets management.
Level: L1. Model: Platform + Tenant.
Applicability: Applicable. The platform stores secrets in a secure vault, while clients manage the secrets for their own integrations within the scope of their projects.
Evidence: Vault/secrets manager (a separate, isolated system based on a custom key manager developed specifically for QuarkDash) and automated scanning for secrets within the codebase. Keys are unique to each tenant.
Status: Met. 4.5.1. Post-quantum readiness.
Level: L3. Model: Platform.
Applicability: Applicable. QuarkDash mitigates the "store now, decrypt later" risk.
Evidence: QuarkDash architectural description. More details on the protocol:
Status: Met.
4.6.1. Project-level isolation as a security boundary.
Level: L2. Model: Platform.
Applicability: Applicable and critical. Clients create agents within projects; project isolation serves as a fundamental boundary that cannot be compromised by the configuration of an individual agent.
Evidence: The architecture ensures that all data is isolated within a tenant and cannot be exposed to another tenant. It is impossible for a client to misconfigure the tenant when creating or modifying an agent, as the system enforces a single, centralized point for tenant selection within the interface; the tenant is automatically assigned whenever any assets—including agents—are created. Agents lack the functionality to switch tenants and do not have access to custom tools that would enable such an action.
Status: Met.
Category 5. Access Control & Identity for AI Components & Users
A distinction is important here: the platform sets an upper limit on the available tools and resources, while the client, within the scope of a project, chooses which of these permitted tools to assign to a specific agent.
5.1.1. Authentication of all actions initiated by an agent.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: The agent operates by initiating requests through a pre-connected interface (e.g., an internal sandbox, or a widget for a website, Telegram, or Discord in the case of public-facing agents) and interacts exclusively with tools and MCP (Model Context Protocol) servers that have been pre-connected and configured by the user. The agent lacks the authority to add or remove tools; its interaction with tools is strictly governed by an additional system prompt provided by the client (or by predefined system prompts for built-in system tools). Both input and output data are validated using the OGL-Mini library. For all tools, the data schema—including values and types—is strictly validated. In certain instances, authorization is managed via credentials (such as OAuth tokens) encrypted through QuarkDash, which are scoped to specific permissions and defined validity periods.
Status: Met.
5.1.2. Granular authorization for tool access.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable; a core requirement for TozheBot. Clients define agents with a strictly constrained list of tools within the scope of a project; the platform must ensure that the agent cannot invoke any tool outside of this designated set.
Evidence: Agent registry, permissions matrix, and a hard-coded tool list mechanism.
Status: Partial.
5.2.1. Principle of least privilege for agents.
Level: L1. Model: Platform + Tenant.
Applicability: Applicable. By default, an agent must not be granted access to tools that are not required for the execution of its assigned tasks. Evidence: By default, an agent has no tools connected; the user selects the list of tools for the agent to use at any given time.
Status: Met
5.3.1. Attribute-Based Access Control (ABAC).
Level: L2. Model: Platform.
Applicability: Applicable. Access rules are based on tenant, role, project, and risk level.
Evidence: Attribute-based model.
Status: Partial.
Action: Document the attribute model and enforcement points.
5.4.1. Unique agent identification.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Agent ID included in logs and traces.
Status: Met.
5.5.1. Management of changes to agent permissions.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable. Users can modify an agent's toolset and access level; all changes must be logged, and any escalation of privileges must require confirmation.
Evidence: Audit log of agent configuration changes.
Status: Gap.
Action: Implement logging for permission changes and a confirmation policy for privilege escalation.
Category 6. Supply Chain Security for Models, Frameworks & Data
6.1.1. Component Inventory (AI-SBOM).
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: AI-SBOM (models, OGL-Mini, QuarkDash, dependencies).
Status: Partial.
Action: Compile an SBOM in a machine-readable format (CycloneDX).
6.2.1. Integrity Verification for Loaded Models.
Level: L2. Model: Platform.
Applicability: Applicable.
Evidence: Model hashes and signatures. When new model versions are loaded, their checksums are verified prior to deployment. If the checksums do not match, the previous version of the model is retained until the hashes align.
Status: Met.
6.3.1. Evaluation of Third-Party MCP Servers and Tools.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable if clients connect their own tools or MCP servers.
Evidence: A registry of MCP servers with associated risk assessments, along with an onboarding/approval procedure. All MCP servers undergo manual testing before being deployed to the production environment; this includes vulnerability scanning, and all inputs and outputs are validated via OGL-Mini. Only official, vendor-provided third-party MCP servers are used.
Status: Met.
Category 7. Model Behavior, Output Control & Safety Assurance
7.1.1. Validation of model outputs against a schema.
Level: L1. Model: Platform.
Applicability: Applicable to structured responses.
Evidence: Output schemas, validation code.
Status: Partial.
To be supplemented: Specify for which response types the schema is enabled.
7.2.1. Guardrails against harmful outputs.
Level: L2. Model: Platform.
Applicability: Applicable.
Evidence: Output security policies. Potential leaks of keys or sensitive data are blocked at the output stage via OGL-Mini, covering risks identified in the OWASP 2025/2026 guidelines for agentic systems.
Status: Met.
7.3.1. Hallucination detection.
Level: L2. Model: Platform.
Applicability: Applicable; documentation mentions guardrails against hallucinations that do not block legitimate requests.
Evidence: Detection is performed using data classifiers, heuristics, and JSON validators—particularly when data is intended for transmission to a subsequent tool or API endpoint.
Status: Met.
7.4.1. Mandatory escalation as a safeguard.
Level: L1. Model: Platform.
Applicability: Applicable. If the model attempts to "connect to an operator," the escalation is mandatory rather than optional.
Evidence: Code for the `escalate_to_human` tool, escalation logs.
Status: Met.
Category 8. Memory, Embeddings & Vector Database Security
8.1.1. Isolation of memory and vector stores between tenants.
Level: L1. Model: Platform.
Applicability: Applicable and critical. Clients operate within separate projects, and the RAG index of one project must not be accessible to an agent belonging to another project.
Evidence: RAG isolation scheme by project, access policies.
Status: Met.
8.2.1. Protection against vector database poisoning.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable. OGL-Mini filters input data prior to indexing; however, clients upload their own documents within the scope of their respective projects.
Evidence: Ingestion procedure, filters. In the event of suspected data poisoning, a security log entry is generated for the user to facilitate subsequent data cleanup.
Status: Met.
8.3.1. Prevention of inversion attacks via embeddings.
Level: L2. Model: Platform.
Applicability: Applicable.
Evidence: Restrictions on the output of vector representations, rate limiting, encryption of vector representations within the knowledge base, and tenant-level isolation.
Status: Met.
Category 9. Autonomous Orchestration & Agentic Action Security
This category is one of the most important for TozheBot. Key controls include: a sandbox for tools, execution budgets, mandatory escalation, and autonomy limitations at both the project and agent levels.
9.1.1. Limiting the depth and scope of agent planning.
Level: L1. Model: Platform + Tenant.
Applicability: Applicable.
Evidence: Limits on recursion and the number of steps (maximum 10 steps; circuit breaker).
Status: Met.
9.2.1. Blocking privileged and irreversible actions pending explicit human approval.
Level: L1. Model: Platform.
Applicability: Applicable. Mandatory escalation to an operator serves as an architectural safeguard.
Evidence: `escalate_to_human` tool code, escalation logs.
Status: Met.
9.3.1. Isolation of tool execution (sandbox).
Level: L1. Model: Platform.
Applicability: Applicable. Tools are executed in an isolated environment; the list of available tools is strictly defined at the project level.
Evidence: Sandbox configuration, detailed information in the documentation.
Status: Met.
9.4.1. Detection of agent looping.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Agent cycle detector (circuit breaker), limits on individual operations, including escalation to a human if the agent becomes stuck (an optional feature in agent settings).
Status: Met.
9.5.1. Identification and logging of agent actions.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Agent ID + action log.
Status: Met.
9.7.1. Limiting agent autonomy at the project level.
Level: L2. Model: Platform + Tenant. Applicability: Applicable and specific to TozheBot. Clients create agents with varying levels of autonomy within a project; the platform must ensure that these autonomy levels cannot be bypassed via configuration.
Evidence: An autonomy-level model (with autonomy rules and strict limits on tool usage defined on the platform), with enforcement handled at the platform level. Scheduled tasks and proactive actions are also configured separately.
Status: Met.
Category 10. Adversarial Robustness & Attack Resistance
10.1.1. Basic alignment testing.
Level: L1. Model: Platform.
Applicability: Not applicable.
Evidence: Users must conduct testing themselves, given the broad scope of use cases and the large number of potential configurations.
Status: Gap.
10.2.1. Robustness against adversarial examples.
Level: L2. Model: Platform.
Applicability: Applicable. OGL-Mini is trained on modern obfuscation techniques, including base64, homoglyphs, zero-width characters, and control tokens.
Evidence: "Modern Obfuscation" dataset (14,000 examples).
Status: Met.
10.3.1. Protection against model extraction.
Level: L2. Model: Platform.
Applicability: Applicable.
Evidence: API rate limiting; input and output processing via OGL-Mini.
Status: Met.
10.4.1. Detection of poisoned input data during inference.
Level: L2. Model: Platform.
Applicability: Applicable. OGL-Mini PII stage and classifier.
Evidence: Risk/stage logs.
Status: Met.
Category 11. Privacy Protection & Personal Data Management
11.1.1. Data anonymization and minimization.
Level: L1. Model: Platform.
Applicability: Applicable. The OGL-Mini PII stage masks PII.
Evidence: PII stage code, examples of masking.
Status: Met.
11.2.1. Data deletion upon request (right to be forgotten).
Level: L2. Model: Platform + Tenant.
Applicability: Applicable.
Evidence: Procedure for deletion from the database, RAG index, and backups. Deletion can be initiated by the user (automatically) or upon request (manually, within 48 hours of the request).
Status: Met.
11.3.1. Consent management.
Level: L1. Model: Platform + Tenant.
Applicability: Applicable.
Evidence: Consent model. Described in the documentation.
Status: Met.
11.4.1. Purpose limitation.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable.
Evidence: Data usage policy. Described in the documentation.
Status: Met.
Category 12. Monitoring, Logging & Anomaly Detection
12.1.1. Basic logging of interactions with the model.
Level: L1. Model: Platform.
Applicability: Applicable. OGL-Mini returns safe/risk, label, stage, and latency.
Evidence: Logs are generated in the control panel, within the analytics and security (monitoring) sections.
Status: Met.
12.1.2. Privacy in logs (PII redaction).
Level: L2. Model: Platform.
Applicability: Applicable.
Evidence: Log redaction policy.
Status: Partial.
12.2.1. Real-time detection of prompt injection and jailbreak attempts.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Alerts based on OGL-Mini. The threshold is set at 0.85; the first detection does not block the request, while subsequent detections block the dialogue.
Status: Met.
12.3.1. Model drift monitoring.
Level: L2. Model: Platform.
Applicability: Not implemented.
Evidence: Drift metrics.
Status: Gap.
12.4.1. SIEM integration.
Level: L2. Model: Platform.
Applicability: Not implemented.
Evidence: Event export to SIEM.
Status: Gap.
12.5.1. Secure log storage with access control.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Retention and access policy defined within the tenant; data is encrypted via the QuarkDash protocol.
Status: Partial.
12.6.1. Documented AI incident response plan.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: AI Incident Response Playbook. Described separately in the documentation.
Status: Met.
12.7.1. Anomaly monitoring at the project and agent levels.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable and specific to a multi-tenant agent system. Clients create various agents, and anomalous behavior by any single agent must not go unnoticed.
Evidence: Alerting rules at the project and agent levels.
Status: Partial.
Category 13. Human Oversight, Accountability & Governance
13.1.1. Kill-switch and agent forced-stop mechanism.
Level: L1. Model: Platform + Tenant.
Applicability: Applicable. The platform provides a technical mechanism; the client has the authority to stop an agent within their project.
Evidence: Implementation of a one-click kill-switch via the control panel or a single API request; access policy.
Status: Met.
13.2.1. Human-in-the-loop checkpoints for high-risk decisions.
Level: L1. Model: Platform.
Applicability: Applicable. `escalate_to_human` serves as a mandatory safeguard.
Evidence: Code and escalation logs.
Status: Met.
13.3.1. Chain of accountability and auditability of actions.
Level: L1. Model: Platform.
Applicability: Applicable.
Evidence: Logs containing operator ID, agent ID, and model decisions.
Status: Met.
13.4.1. Transparency of agent configuration for the client.
Level: L2. Model: Platform + Tenant.
Applicability: Applicable. The client must be able to see which tools and what level of access have been granted to each agent within their project.
Evidence: The agent control panel allows for the export of configurations.
Status: Met.