Documentation Index
Fetch the complete documentation index at: https://koreai-v2-home-nav.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Security and trust
The Agent Platform 2.0 is built with security, privacy, and compliance as foundational requirements. This page describes our security practices, compliance posture, data handling policies, and how to report vulnerabilities.Security practices overview
Infrastructure security
- Encryption in transit: All data transmitted between clients, services, and external integrations uses TLS 1.2 or higher. Internal service-to-service communication is encrypted.
- Encryption at rest: All stored data, including session state, knowledge base content, credentials, and audit logs, is encrypted at rest using industry-standard encryption.
- Network isolation: Platform services run in isolated network segments with strict ingress and egress controls. Tenant data is logically isolated at the application and database layers.
- Secret management: API keys, LLM credentials, MCP server credentials, and other secrets are encrypted before storage and are never exposed in logs, traces, or API responses.
Application security
- Authentication: The platform supports email/password authentication with optional multi-factor authentication (MFA), as well as enterprise SSO via SAML 2.0 and OpenID Connect (OIDC).
- Authorization: Role-based access control (RBAC) enforces permissions at the organization, tenant, and project levels. Every API request is scoped to a tenant, and cross-tenant data access is prevented at the application layer.
- Input validation: All API inputs are validated and sanitized before processing. Payload size limits are enforced at service boundaries.
- Dependency management: Third-party dependencies are scanned for known vulnerabilities on a regular schedule, with critical patches applied within 48 hours of disclosure.
Operational security
- Audit logging: Administrative actions (member changes, configuration updates, deployments) are recorded in an immutable audit log scoped to each tenant.
- Monitoring and alerting: Platform services are monitored 24/7 with automated alerting for anomalies, error rate spikes, and resource exhaustion.
- Incident response: A documented incident response process governs detection, containment, communication, and post-incident review. See Status and service health for details.
Compliance
SOC 2 Type II
The Agent Platform 2.0 maintains SOC 2 Type II compliance, independently audited against the Trust Services Criteria for security, availability, and confidentiality. Audit reports are available to customers under NDA upon request.GDPR
The platform is designed to comply with the General Data Protection Regulation (GDPR):- Data minimization: The platform collects and retains only the data necessary for service operation. Configurable retention periods allow tenants to control how long conversation data is stored.
- Right to erasure: Tenant administrators can initiate data deletion requests that cascade through all platform services, removing user data from active stores, cold storage, knowledge base indexes, and backups within the documented processing window.
- Data portability: Tenant data can be exported in standard formats through the API.
- Data Processing Agreement (DPA): A DPA is available for customers who require a formal agreement governing data processing activities. Contact your account team or privacy@ablplatform.com to request a DPA.
Additional frameworks
The platform’s security controls are aligned with:- ISO 27001 information security management practices
- CCPA (California Consumer Privacy Act) data privacy requirements
- HIPAA readiness for customers processing protected health information (available on Enterprise plans with a Business Associate Agreement)
Data handling and privacy
Tenant data isolation
Every piece of data in the platform is scoped to a tenant. Database queries always include tenant identifiers, and cross-tenant access returns a 404 response (not 403) to avoid leaking resource existence. This isolation is enforced at the application layer across all services.Conversation data
- Active sessions are held in memory with configurable idle timeouts.
- Session state is persisted to durable storage with encryption at rest and automatic expiration via TTL.
- Conversation history is compressed before storage to reduce footprint.
- Retention periods are configurable per tenant (default: 7 days). Data beyond the retention period is automatically purged.
LLM data handling
- Prompt data sent to LLM providers follows the data processing terms of each provider. The platform does not send tenant data to LLM providers for model training.
- LLM credentials (API keys, OAuth tokens) are encrypted before storage and decrypted only at the point of use.
- Token usage is tracked per tenant and project for billing and policy enforcement, but prompt content is not stored in usage metrics.
Knowledge base data
- Uploaded documents are processed through the ingestion pipeline (parsing, chunking, embedding) and stored in tenant-scoped indexes.
- Source documents can be deleted through the API, which removes the document, its chunks, and associated embeddings.
- Connector credentials for third-party data sources (Google Drive, Confluence, SharePoint) are encrypted at rest.
PII handling
- GATHER fields can be marked as
sensitive, enabling automatic PII masking (redact,mask, orreplace) outside the collection context. - Transient fields are automatically cleared after the gather phase completes, preventing PII from persisting in session state.
- Guardrails can be configured with built-in PII detection to block or redact personally identifiable information from agent inputs and outputs.
Responsible disclosure
We value the security research community and welcome reports of potential vulnerabilities.Reporting a vulnerability
If you discover a security vulnerability in the Agent Platform 2.0:- Email security@ablplatform.com with a detailed description of the vulnerability.
- Include:
- Steps to reproduce the issue
- The potential impact
- Any proof-of-concept code or screenshots
- Your contact information for follow-up
- Do not publicly disclose the vulnerability until we have confirmed the fix and coordinated a disclosure timeline.
Our commitment
- We acknowledge receipt of vulnerability reports within 2 business days.
- We provide an initial assessment within 5 business days.
- We work with reporters to understand and resolve the issue, and we credit reporters (with permission) in our security advisories.
- We do not pursue legal action against researchers who follow responsible disclosure practices.
Data processing agreement (DPA)
A Data Processing Agreement is available for customers who require a formal contract governing how the platform processes personal data on their behalf. The DPA covers:- Scope and purpose of data processing
- Data subject rights and obligations
- Sub-processor management and notification
- Data breach notification procedures
- Data transfer mechanisms (for cross-border data flows)
- Data deletion and return upon contract termination