Security — Klaut AI

1. How we think about security

Klaut runs an enterprise AI practice. Our clients hand us access to operational systems, employee data, and decision-grade workflows. That access is the asset; the trust it implies is the product. We treat security as a first-order engineering concern, not a compliance line item.

This page describes the safeguards that apply to data we hold and process, the assumptions behind them, and the places where we deliberately stop short of claims we cannot back up. It is referenced by, and operates as part of, our Privacy Policy.

2. The scope this page covers

The public sites at klaut.id and compass.klaut.id.
The Compass application at compass-app.klaut.id and the data it processes for clients.
Internal systems used to run client engagements: communications, document handling, code repositories, and AI tooling.

Client-owned systems, the third-party platforms a client connects into Compass, and the model providers used inside a delivered solution are governed by their own security postures, which we evaluate during procurement and document inside each engagement.

3. Infrastructure

Hosting and edge. Sites and the Compass application are deployed on Vercel, fronted by Cloudflare for DNS, CDN, and edge protection. TLS is mandatory on every public endpoint, with HSTS enabled. We do not serve HTTP traffic on our production domains.

Domain and DNS. klaut.id and its subdomains run under DNSSEC-aware configuration through Cloudflare. Record changes are restricted to a named administrator account with hardware-key second factor.

Email. Outbound transactional and engagement email is delivered through Postmark with SPF, DKIM, and DMARC enforced on the klaut.id domain. We do not relay through generic SMTP services for client-facing communication.

Analytics. Vercel Web Analytics provides aggregate site analytics with no advertising trackers and no session replay. There is no third-party JavaScript on the public sites beyond Vercel-issued tags.

4. The Compass privacy architecture

The Compass platform was designed around a single security and privacy assumption: three audiences see three views of the same underlying data, and the boundary between them is enforced at the data layer rather than at the UI.

The employee sees their own performance, mistakes, lessons, and skill score in full.
The manager sees team-level trends and the limited individual data the deployment scope authorises — typically gap categories and direction of change, not raw activity recordings.
HR sees aggregate workforce capability and trust signals. HR cannot drill from an aggregate to an individual through any product path.

This is enforced through:

Row-level access policies in the Compass data model, evaluated server-side on every read.
Separate API surfaces for the employee, manager, and HR views, each constrained to the data the role is permitted to see.
An audit trail that records when a permitted boundary-crossing event occurs (for example, an employee-initiated export of their own record), and refuses the request otherwise.

Privacy boundaries are part of the product, not a configuration step the client can disable. A client cannot toggle a switch to grant HR individual-level access; doing so would require reconfiguring the data model itself, which is not a customer-facing operation.

5. Data handling

In transit. All client and platform data moves over TLS 1.2 or higher between user devices, our edges, our applications, and our data stores.

At rest. Production data stores use provider-managed encryption at rest. Backups inherit the same encryption posture.

Secrets. Credentials and API keys for production systems are held in a managed secret store, never in source code, and rotated when a holder changes role or when a vendor signals exposure. Production secrets are not stored on personal devices.

Backups and recovery. Compass production data is backed up on a daily basis with a documented restore procedure. Backups are encrypted, retained for thirty days unless a longer period is contractually agreed, and tested by restore drill at least quarterly.

Logging. Application and access logs are captured for security and operational purposes, retained for ninety days at the platform level, and reviewed when an incident or anomaly is identified.

6. Access control

Internal access. Production access is limited to the named operators who require it. Authentication is enforced through identity provider with mandatory second factor. Shared accounts and shared credentials are prohibited.

Client access. Compass user authentication runs through the client's identity provider where the deployment supports SSO; standalone deployments use credentialed accounts with second-factor enforcement available. Account provisioning and deprovisioning is the client's responsibility under the deployment scope.

Least privilege. Role assignments inside Compass and inside our internal tooling follow least privilege. Elevated access is granted for a defined task, recorded, and removed when the task is complete.

7. AI governance inside delivered solutions

Where Klaut deploys a model — inside Compass or inside a client engagement — the model selection is treated as a security decision, not only a performance decision. Each deployed model is evaluated against:

The sensitivity of the data the model will process.
The vendor's training-use clause and whether the deployment route preserves data exclusion from training.
The vendor's retention policy for inputs and outputs.
The legal and regulatory exposure of the workload.

The result is documented inside the engagement, including which models are approved for which classes of data and which routes are explicitly disallowed. Where the right answer is a self-hosted model in a client-controlled environment, we deploy that.

8. Vendor and sub-processor management

The current list of sub-processors used in delivering services is maintained on request. Material additions to that list for active Compass deployments are notified to the client at least thirty days before they take effect, with the right to object in writing.

We evaluate new vendors against documented security and privacy criteria before they handle production data. We require contractual data-handling commitments at least as strong as those we make to our clients.

9. Personnel

Klaut operates as a small, named team. Each person who handles client data signs a written confidentiality undertaking. Personnel who handle production credentials are required to keep their work devices full-disk-encrypted, use a managed password manager, and run vendor-current operating systems.

Where Klaut engages an external collaborator — a fractional technical resource, a specialist consultant, a vendor implementation contact — that person is brought under the same confidentiality and data-handling obligations through a written agreement before access is granted.

10. Software development

Source code for the public sites and the Compass application is held in a managed code platform with branch protection on production branches, mandatory review on changes affecting authentication, authorisation, or data access, and dependency scanning enabled on every build. We do not commit secrets or production data into source control.

11. Incident response

We treat an incident as any event that compromises or appears likely to compromise the confidentiality, integrity, or availability of data we hold. Our response process has four stages:

Contain. Stop the active vector. Revoke compromised credentials. Take affected systems offline if containment requires it.
Assess. Determine what data was reachable, who was affected, what the realistic exposure is.
Notify. Communicate honestly with affected clients on a timeline that meets, at minimum, the requirements of UU PDP and any applicable cross-border framework. Notification includes what happened, what we know, what we do not yet know, and what we are doing.
Resolve. Remediate the underlying cause. Document the incident. Update the safeguards that did not catch it.

We do not minimise incidents in disclosure. The credibility we lose by understating an incident is larger than the credibility we lose by reporting one accurately.

12. Customer responsibilities

Security is a shared responsibility. Our clients are responsible for:

Provisioning Compass accounts to the right employees, and removing access promptly when an employee changes role or leaves.
Configuring their identity provider securely where Compass uses SSO.
Protecting credentials for their connected systems (the customer service platform, internal databases, and so on) that Compass observes under the deployment scope.
Not using Compass outside the agreed scope or in ways that breach Section 7 of the Terms of Service.
Reporting suspected security issues promptly through the channels in Section 13.

13. Vulnerability disclosure

If you believe you have found a security vulnerability affecting klaut.id, compass.klaut.id, or compass-app.klaut.id, write to hello@klaut.id with "Security disclosure" in the subject. Include enough detail for us to reproduce the issue. We acknowledge within three business days.

We commit to:

Investigating reports made in good faith.
Not pursuing legal action against researchers who comply with this section.
Crediting reporters who request credit, once a fix is in place.

We ask researchers to:

Limit testing to the surfaces named above.
Not access, modify, or delete data that does not belong to you.
Not run automated scans at a rate that interferes with normal operation.
Give us a reasonable window to fix and disclose before publishing details.

14. Compliance posture

Klaut operates in line with the requirements of Indonesia's Personal Data Protection Law (UU No. 27 Tahun 2022), Indonesia's Electronic Information and Transactions Law (UU No. 11 Tahun 2008 as amended), and, where the client and the data make it applicable, GDPR, UK GDPR, and the analogous laws of other jurisdictions in which our clients operate.

We do not currently hold ISO 27001 or SOC 2 certification. Our posture is built to be evaluated against the substance of those frameworks during a client procurement review. Where a client requires a specific certification as a precondition of engagement, that requirement is discussed in the Foundation phase and either built into the engagement plan or addressed as a known gap.

15. Changes

We update this page when our practice changes or when a relevant framework changes. The current version, with its effective date, is posted here. Material changes affecting active clients are notified by email to the named client contact under the engagement letter.

16. Contact

Security questions, vulnerability reports, and incident notifications all route to hello@klaut.id. Mark the subject line accordingly.

Klaut AI · Jakarta, Indonesia