5.1. Platform security
Platform Security
Our Approach to Security
Security is one of the core principles of TozheBot's architecture. The platform uses a multi-layered approach to protecting data, isolating projects, controlling AI agent interactions, and recording security-related events.
Our security architecture combines several complementary mechanisms:
- User and project isolation — access control for tenants, agents, and platform resources.
- Agent permission management — restrictions on which tools and knowledge bases each agent can access.
- ML-based interaction security — detection of potentially malicious instructions and personally identifiable information (PII) using OGL-Mini.
- Cryptographic data protection — encryption of supported data fields using QuarkDash.
- Security monitoring — recording security mechanism activations and potentially suspicious events.
- Personal data auditing — logging designated data operations to support internal controls and reporting.
These mechanisms are designed to work together. Access controls define permitted actions, ML-based security helps identify threats, encryption protects data contents, and monitoring and auditing provide visibility into recorded events.
1. User, Project, and Agent Isolation
Users and Projects
TozheBot organizes resources into projects, also known as tenants. Each user receives access to projects according to their assigned role and permissions.
Access control mechanisms consider user roles, permission scopes, and project ownership of resources. Data operations use access checks at the collection and server-logic levels.
This helps separate the working environments of different teams and restrict access to data outside an authorized project.
Agent Isolation
Each agent within a project has its own configuration and assigned resources. An agent's access permissions are not automatically granted to other agents.
This makes it possible to create specialized agents for different tasks, such as customer support, documentation assistance, or ticket processing, while restricting their access according to their intended purpose.
Tool Access Control
Tools allow agents to interact with external systems and perform designated actions.
TozheBot stores tool configurations and their associations with agents. Execution supports built-in tools, webhooks, and integrations with external systems, including CRM and MCP tools.
An agent should only operate with tools that are connected and authorized for it. When configuring integrations, we recommend granting the minimum permissions required in the external systems.
Knowledge Base Access Control
Agents use their assigned knowledge bases to retrieve context and generate responses. Configuring available sources helps separate information between agents and use cases.
Principle of least privilege: each user and agent should receive only the resources and permissions necessary to perform its intended tasks.
2. ML-Based Security for AI Agent Interactions
To provide an additional layer of protection for agent interactions, TozheBot uses its own security layer based on OGL-Mini (Open Guard Layer).
Repository and technical documentation:
OGL-Mini is a hybrid security mechanism for AI applications that combines heuristic checks, ML-based content classification, and ML-based PII detection.
Detecting Potential Threats
The security layer is designed to identify content associated with threats such as:
- Prompt injection — attempts to change an agent's behavior through untrusted instructions.
- Jailbreak attempts — attempts to bypass the model's intended restrictions.
- Suspicious instructions — content that may indicate an attempt to manipulate an agent.
- Personal data — information that may require additional protection before being sent to a model.
- Certain obfuscated attacks — for example, instructions using unusual formatting or text obfuscation, where these patterns are recognized by the deployed security model.
Incoming Message Inspection
The agent message handlers, widget, and connected channels invoke checks on incoming text. These checks combine heuristic threat detection with ML-based risk assessment when the model is successfully loaded and available.
The inspection result can include detected flags, a risk score, and processed text. Security events may be recorded in the security log and associated with the conversation history.
In the current implementation, this mechanism operates in soft mode: detecting a potential threat does not, by itself, mean the request will be blocked.
PII Detection and Masking
The platform implements detection of several types of personal data using regular expressions and OGL-Mini integration.
Heuristic checks cover email addresses, phone numbers, Telegram identifiers, certain document numbers, and payment card numbers. The ML model may supplement these checks within the data classes it supports.
Detected values can be replaced with temporary placeholders, such as [EMAIL_1] or [PHONE_1], before the processed message is sent to the language model. In applicable scenarios, the original values may be restored after the response has been generated.
Masking reduces the likelihood of sending original personal data to the model, but it does not guarantee the detection of all sensitive information. Any information stored using post-quantum encryption (see below).
It is also important to note that original messages and some text fragments may be retained in conversation history or security logs. Masking data before sending it to a model does not automatically remove the original values from storage or logs. But all data is stored in encrypted mode.
3. Cryptographic Data Protection
TozheBot uses its own cryptographic protocol, QuarkDash, to encrypt supported data fields.
Repository and technical documentation:
QuarkDash is a hybrid cryptographic protocol designed with a post-quantum approach. Its implementation includes mechanisms for key-material exchange, key derivation, encryption, and integrity verification.
What Post-Quantum Means
Post-quantum cryptography addresses threats associated with the potential capabilities of future quantum computers. One important risk scenario involves collecting encrypted data today in an attempt to decrypt it in the future.
QuarkDash was designed with these threats in mind.
Field-Level Encryption
TozheBot implements a shared encrypted field mechanism that enables encryption and decryption for fields explicitly configured to use it. When these fields are written, the application processes their values through the cryptographic layer and stores an encrypted representation. When the values are read, they are decrypted for authorized application processing.
Key Management
The platform includes a key manager that supports key-material versions and scheduled rotation.
Key material is not stored directly in the keyring record. Instead, the keyring stores salts and version metadata, while keys are derived again from a master secret and the corresponding parameters. Access to the technical key store is restricted through server-side logic.
Key Rotation and Re-encryption
Key rotation is supported by the key manager. The platform tracks key versions and the status of background re-encryption tasks.
When required, data encrypted with an older key version can be gradually re-encrypted using the active version. This allows data migration without requiring every record to be re-encrypted in a single operation.
4. Security Event Monitoring
TozheBot has a dedicated mechanism for recording security events. Events are stored in the technical collection.
Depending on the event type, a record may contain the event category, severity level, associated project, reason for the detection, risk assessment, and additional metadata.
The platform defines event categories associated with:
- Potential prompt injection detection.
- Personal data detection.
- Request rate-limit violations.
- Suspicious login activity.
- CSRF protection violations.
Using Security Events
The security log helps teams:
- Analyze security mechanism activations.
- Identify recurring suspicious request patterns.
- Associate events with a project and conversation.
- Determine whether security settings or detection rules need adjustment.
- Investigate and review incidents internally.
Access to security log viewing is restricted by administrative permissions. Like any logs, security records must be protected against unauthorized access, and their retention periods should be controlled.
Some events contain fragments of the original text. As a result, the security log itself may contain sensitive information and must be handled according to data minimization principles. But all original data is encrypted by default.
5. Personal Data Auditing
TozheBot implements a dedicated audit log for operations involving personal data. It is intended to support internal oversight of data processing and the preparation of reports.
The design takes into account the requirements of Russia's Federal Law No. 152-FZ on Personal Data and the EU General Data Protection Regulation (GDPR), where the relevant legislation applies to the processing activity.
What Is Recorded
For configured collections containing personal data, the platform provides event logging for record creation, modification, and deletion.
An audit record may contain:
- Event date and time.
- Operation type.
- Collection name and record identifier.
- The user who initiated the operation, where identifiable.
- Associated project.
- Categories of personal data being processed.
- Purpose of processing.
- Legal basis for processing.
- Applicable regulatory frameworks.
- Available technical request metadata, such as IP address and User-Agent.
The fields recorded depend on the operation type and collection configuration. The current audit hooks should not be interpreted as proof that every read of personal data - or every operation across all system components - is automatically logged.
Audit Export
The platform supports exporting audit logs to CSV for reporting and further analysis.
Export access is restricted to project administrators and global administrators, subject to their permission scope. Exports may include information about operations, legal bases, data categories, and associated projects.
Exported files may contain sensitive information and should therefore be stored and transferred according to internal security policies.
Legal Requirements and Compliance Limitations
Having a technical audit log helps support certain internal control activities, but it does not, by itself, establish full compliance with Federal Law No. 152-FZ or GDPR.
Compliance also depends on legal grounds for processing, providing required privacy information, managing consent where necessary, retention and deletion periods, handling data subject requests, international data transfers, contractual arrangements, and organizational measures.
Technical logs should be treated as one component of a broader personal data governance program, not as a substitute for legal and organizational controls.
6. Recommendations for Secure Configuration
To reduce risks when using TozheBot, we recommend:
- Grant users access only to the projects they need.
- Restrict each agent to the tools and knowledge bases required for its tasks.
- Use least-privilege credentials for external integrations wherever possible.
- Avoid allowing agents to perform critical actions without the necessary checks and confirmations.
- Review security events and investigate recurring incidents.
- Do not include passwords, API keys, or other secrets in agent instructions or publicly accessible knowledge bases.
- Restrict access to audit logs, exported files, and other materials containing personal data.
- Define and regularly review data and log retention periods.
- Regularly review user permissions, connected integrations, and agent configurations.
7. Limitations and Responsibilities
AI system security depends not only on the platform but also on agent configuration, connected services, the models being used, the data being processed, and the permissions granted to tools.
ML-based security may produce false positives and false negatives. Fallback heuristic checks may not provide the same detection capabilities as a loaded ML model. Detecting a threat also does not mean that the request will automatically be blocked in every scenario.
Monitoring and auditing make it possible to analyze recorded events, but logging coverage depends on which operations are connected to the relevant mechanisms.
For use cases with elevated security requirements, we recommend independent implementation audits, penetration testing, infrastructure configuration reviews, and assessments of backup and incident response procedures.
If you need a support with security - please, contact us.
Conclusion
TozheBot uses a layered approach to protecting data and AI agent interactions. It combines user and project isolation, agent permission management, ML-based security powered by OGL-Mini, cryptographic protection of configured fields using QuarkDash, key-version management, security event monitoring, and auditing of designated personal data operations.
Our goal is to provide infrastructure in which AI agent permissions can be restricted, sensitive data can be protected by the mechanisms available, and security-related events can be recorded and analyzed.
Security is not a single feature or model. It is a combination of technical safeguards, correct configuration, and continuous oversight.