Trust Center

Security

The controls below are implemented in the product and its infrastructure today. Where a control is a managed capability of our infrastructure providers rather than something WKIL operates directly, we say so.

• Authentication and accounts

  In place

  Accounts are created and authenticated through a managed authentication service. Credentials are never stored in application tables, and sessions are issued as signed tokens.

• Role-based workspace access

  In place

  Permissions follow workspace roles, and role decisions are made server-side. A browser client cannot grant itself elevated access.

• Row-level access enforcement

  In place

  Access to application data is enforced at the data layer on every query, not by interface logic alone.

• Tenant-level data access controls

  In place

  Customer records are separated by ownership and workspace membership, enforced at the data layer. This is logical separation within shared managed infrastructure, not physically isolated infrastructure per customer.

• Encryption in transit

  In place

  All traffic to WKIL is served over HTTPS with TLS. Plain HTTP requests are redirected.

• Encryption at rest

  In place

  The managed database and object storage encrypt data at rest as a capability of our infrastructure providers. WKIL relies on that provider capability and does not operate its own storage encryption layer.

• Server-side secrets management

  In place

  API keys, service credentials and model-provider keys are held as server-side configuration and are not exposed to the browser.

• Authenticated privileged operations

  In place

  Privileged operations run server-side behind authentication and role checks.

• Dependency management

  In place

  Application dependencies are scanned for known vulnerabilities and upgraded when advisories affect the stack.

• Logging and run history

  In place

  The application and its infrastructure produce operational logs, and agent activity is recorded as run history that workspace owners can review.

• Backups

  In place

  Database backups are a managed capability of our infrastructure provider. Backup and recovery parameters are confirmed with enterprise customers as part of the engagement.

• Consolidated security monitoring and alerting

  In implementation

  Operational monitoring exists at the infrastructure layer. A consolidated security-monitoring and alerting programme is being implemented.

• Documented secure development and vulnerability-management policies

  In implementation

  Code review, staged releases and dependency remediation are how we work today. Writing these practices down as formal, reviewable policies is in progress.

• Production and internal access policy

  In implementation

  Production access is limited to a small number of authorised engineers. A documented access-control policy with formal joiner/mover/leaver procedures is being prepared.

Report a suspected vulnerability to [email protected]. Please include reproduction steps and give us a reasonable opportunity to remediate before public disclosure.

What we publish and what we share under NDA

We deliberately keep two layers. Publishing sensitive implementation detail would not make WKIL more secure — it would make it easier to attack.

• Public security overview

  In place

  The control descriptions on this page: what exists, what is being implemented, and how customers control their agents.

• Detailed enterprise review

  Shared with qualified customers under NDA where available

  Deeper security, architecture, privacy and procurement information for a specific evaluation. Where additional evaluation materials are available and appropriate to the request, they may be provided to qualified enterprise customers under NDA.

AI Governance

WKIL is an AI agent platform, so the most important question is not only how data is stored but what agents are allowed to do. These are product controls that customers configure in their own workspace.

• Agent ownership

  In place

  Every agent belongs to an owner inside a customer workspace. Ownership determines who can view, change and run it.

• Workspace roles

  In place

  Workspace membership and roles decide who can create agents, edit them, connect systems or view results. Role checks are enforced server-side.

• Explicit tool and system access

  In place

  An agent can only reach a connected application after that connection has been explicitly authorised. Connecting a system is a deliberate act, not a default.

• Activation and deactivation

  In place

  Agents can be switched off. Deactivating an agent stops it from running while its configuration and history remain available for review.

• Run history

  In place

  Agent runs are recorded so owners can review what an agent did, with which inputs, and what it produced.

• Human approval steps

  In place

  Approval steps can be configured so that a sensitive action is prepared by the agent and executed only after a person approves it. This is a configuration choice — approval is not automatically applied to every workflow.

• Agent versioning and rollback

  In implementation

  Structured version history with rollback across agent types is on the product roadmap.

• Automated output guardrails

  In implementation

  Automated content guardrails and abuse monitoring across agent output are being developed. Today, control comes primarily from scoping permissions and requiring human approval for sensitive actions.

These are product controls that let your organisation decide what its agents may do, and how much autonomy each one is given.

Human Oversight

We design around a simple separation, and we recommend that customers apply it deliberately when they scope an agent.

• Delegate

  Low-risk, reversible work — drafting, summarising, classifying, retrieving, preparing a record — can run without a person in the loop.

• Prepare

  Work with external or financial consequences can be fully prepared by the agent and left ready for a person to check: an outbound message, a quote, a data change.

• Approve

  Actions that commit the organisation — sending on its behalf, changing records in a system of record, spending money — should require explicit human approval before execution.

The platform supports this separation; it does not impose it. Whether a given workflow includes an approval step is decided by the customer when the agent is configured.

Data Handling

Storage and processing are different things, and we keep them apart in this description on purpose.

• Data stored by WKIL

  In place

  Account and workspace records, agent configurations, conversations and run history, uploaded files and company knowledge, and support and enquiry records submitted through our forms.

• Data processed during an agent run

  In place

  The input you submit, the context assembled for the agent, the parameters of the tools it calls and the result it produces. Some of this is transient; what is retained is retained as run history.

• Data sent to connected applications

  In place

  When an agent uses a connector you authorised, the request and its parameters reach that application, and its response returns to the run. That application remains governed by your own agreement with its provider.

• Data sent to AI model providers

  Legal review

  To generate a response, the prompt and the context supplied to the agent are transmitted through an AI gateway to the selected model provider. Model providers are third parties operating under their own terms. We are reviewing and formalising those terms as part of our privacy programme, and until that review is complete we will not make claims about model-provider training or retention on your behalf.

• Logs and operational data

  In place

  Request metadata, error information and delivery records are produced by the application and its infrastructure providers for reliability and support.

• Backups

  In place

  Backups are held by our managed infrastructure provider. Deleted records may persist in backup copies until those copies age out on the provider's cycle.

Access & Permissions

Who can reach what, on your side and on ours.

• Customer-side access

  In place

  Access is determined by workspace membership and role, enforced by server-side checks and database policies rather than by hiding interface elements.

• Connector authorisation

  In place

  Each connected system is authorised individually and can be disconnected, which removes the agent's ability to reach it.

• WKIL support access

  In implementation

  Support may need to access customer records to investigate a reported issue. Access is limited to authorised personnel. A documented support-access policy, including access logging, is being prepared.

Data Retention & Deletion

WKIL supports data deletion requests, while formal retention schedules across data categories are being documented.

• Deletion on request

  In place

  Customers can request deletion of their account, workspace or specific records by contacting [email protected]. Deleting a parent record removes the dependent records linked to it.

• Retention schedules

  In implementation

  Formal retention schedules across data categories, with technical enforcement, are being documented as part of the privacy programme and will be published here once confirmed.

• Backups after deletion

  In place

  Deleted data may remain in provider-managed backup copies until those copies age out on the provider's schedule.

Data Locations

Storage location and processing location are two different questions, and we answer each one precisely.

• Storage

  In implementation

  Application data is stored in managed cloud infrastructure operated by our providers. We are documenting the exact storage regions as part of the privacy programme.

• Processing

  In place

  Content is delivered through a global edge network and model requests are processed by third-party model providers. Processing may therefore occur outside the country in which your organisation is based.

• Residency commitments

  In place

  WKIL does not currently offer a verified data-residency guarantee for any specific country or region. If residency is a requirement for your evaluation, raise it with us directly rather than assuming a location.

Subprocessors

A subprocessor is a provider that processes personal data on WKIL's behalf. That is a narrower group than our integration catalogue: a connector you authorise to your own account is normally your vendor, not ours.

• Categories we rely on

  In place

  Cloud application hosting and managed database, edge delivery, AI model access through a gateway, transactional email and product analytics.

• Published register with named entities

  Legal review

  A subprocessor register naming each provider, its contracting entity, purpose, region and transfer mechanism has been drafted internally and is under legal review. We will publish it once verified rather than posting an unverified list now.

• Change notification commitment

  In implementation

  A formal notification commitment for subprocessor changes will be defined together with the published register and Enterprise agreements.

International Data Transfers

WKIL serves organisations across the Gulf, Türkiye and Europe using global cloud and model infrastructure, so cross-border processing is a real question rather than a theoretical one.

• Current position

  In place

  Cross-border processing occurs. We are mapping every transfer as part of the privacy programme.

• Transfer mechanisms

  Legal review

  The appropriate contractual mechanism for each transfer — including EU Standard Contractual Clauses and the Türkiye standard-contract forms — depends on the processing-role determination for each activity. That determination is with legal review and no mechanism is presented as concluded.

Privacy & Data Protection

A summary for evaluators. The Privacy Policy remains the authoritative legal document, and this section does not replace it.

• What we may process

  In place

  Account information, agent inputs, uploaded or connected company knowledge, data returned by connectors you authorise, agent outputs, operational logs, and support or enquiry information you send us.

• Why

  In place

  To provide and operate the platform, run the agents you configure, keep the service reliable and secure, respond to support and enterprise enquiries, and meet legal obligations.

• Processing roles

  Legal review

  WKIL's role differs by activity: administering an account is not the same processing activity as running an agent over customer content. We are completing a role assessment per activity and will not publish a blanket statement that WKIL is 'always a processor' or 'always a controller' before legal review concludes.

• Your privacy requests

  In place

  Access, correction and deletion requests are handled by our team at [email protected].

Privacy & Regulatory Programmes

The programmes below are actively being implemented and internally assessed. Final legal validation is pending in each case.

• GDPR — European Union

  In implementation

  Processing inventory, role assessment per activity, transfer mapping and processor arrangements are being prepared. Implementation and internal assessment are underway. Final legal validation is pending.

• PDPL — Saudi Arabia

  In implementation

  Current-state inventory, processing and transfer questions, and the contractual requirements for enterprise engagements are being worked through. Implementation and internal assessment are underway. Final legal validation is pending.

• KVKK — Türkiye, Law No. 6698

  In implementation

  Applicable processing activities, international-transfer questions and the contractual forms that will apply once processing roles are determined are under assessment. Implementation and internal assessment are underway. Final legal validation is pending.

Incident Management

How we work when something goes wrong, described as the practices we follow today.

• Identification and escalation

  In place

  Suspected incidents — whether raised internally, by a customer or through [email protected] — are escalated to the engineering team responsible for the affected system.

• Investigation and containment

  In place

  We establish scope and impact, contain the issue, and apply a fix or mitigation before returning the affected service to normal operation.

• Customer communication

  In place

  When an incident may affect a customer, WKIL communicates directly with the affected organisation based on the nature, scope and impact of the incident.

• Incident response documentation

  In implementation

  Formal documentation of the incident-response process, with defined roles and severity levels, is being completed as part of the security programme. Detailed procedures remain internal.

Business Continuity

Resilience as it stands today, described at the level we can evidence.

• Managed, redundant infrastructure

  In place

  The application runs on managed cloud infrastructure with a globally distributed delivery layer and a managed database with provider-operated backups.

• Continuity and recovery planning

  In implementation

  Business continuity and disaster-recovery procedures are being formalised and documented.

Enterprise Agreements

Enterprise engagements often require contractual documentation beyond our standard Terms.

• Contracting approach

  In place

  Enterprise contractual documentation is agreed with our team as part of the engagement rather than published as standard templates.

• Negotiated contracting

  In place

  Contractual documentation appropriate to the engagement — including data-processing terms and security commitments — is agreed as part of Enterprise contracting with our team.

• Transfer terms

  Legal review

  Contractual transfer mechanisms follow the processing-role determination currently under legal review.

Enterprise Trust Package

Qualified enterprise customers may request additional security, architecture, privacy and procurement information. The WKIL team will confirm the materials available for the relevant evaluation.

• Security and privacy questionnaire support
• Architecture and data-flow information relevant to your review
• How agent permissions, approvals and run history apply to your intended use case
• Status of the privacy and regulatory programmes described above
• Contractual documentation appropriate to your engagement

Requests are qualified before any material is shared. Where additional evaluation materials are available and appropriate to the request, they may be provided to qualified enterprise customers under NDA.

Enterprise documents & due-diligence request

If your security, privacy, legal or procurement team needs specific material — a DPA, technical and organisational measures, subprocessor information, data residency, or a security questionnaire response — select it here. Nothing is sent automatically: the WKIL team reviews each request and confirms which materials are appropriate and whether an NDA is required.

Related material

Public documents and background reading referenced from this page.

• Privacy Policy
• Terms of Service
• AI agent permissions
• Human in the loop
• Enterprise