Pillar · Trust Center

Trust is not a badge.
It's an architecture.

When you hand company data to an AI, "trust us" isn't enough. No marketing on this page: where your data lives, who can reach it, and what the agent cannot do.

Fear 01 solved

It won't make things up

The widget speaks only from your knowledge base; the agent's answers are tied to sources too. It won't invent a reason for an empty result — it says "none" is "none." Strict-KB grounding is not a mode, it's the default trust promise.

Fear 02 solved

No action without approval

Every tool call passes a code-level policy engine BEFORE it runs. This is not a prompt rule — prompt injection cannot override it. Risky actions fall to your approval.

Your data never trains models

Your knowledge base, chats and agent tasks are never used to train any AI model. Traffic to AI providers is routed through our own gateway to enterprise, no-training API endpoints.

Tenant-isolated architecture

Every tenant's data is tagged with its own identity; every API request and vector search passes a tenant filter. Your knowledge base, memory and agent playbooks are never shared with another customer.

The agent is never unsupervised

Every tool call passes a code-level policy engine before it runs: approval thresholds, domain allow-lists, and a "never-silent" action class. This is not a prompt rule — prompt injection cannot override it.

Consent-based memory (GDPR/KVKK)

Personalization and memory are opt-in. Everything the agent learns about you is visible in the panel — profile, history summaries and learned rules can be deleted with one click.

Agent security model

What the agent cannot do

Everyone selling an autonomous agent tells you what it can do. We also write what it cannot:

  • Cannot send an email/HTTP request outside the allow-list
  • Cannot run "never-silent" actions without approval — even in full-autonomy mode
  • Cannot even see tools in a disabled capability tier
  • Cannot read/exfiltrate vault secret values — the tool layer uses them, the LLM never sees them
  • Cannot access another tenant's data
policy.py · from production code
# Decides EXECUTE | APPROVE | DENY for EVERY
# tool call, BEFORE it runs. This is where
# enforcement lives — NOT in the LLM prompt
# (a prompt is not a security boundary).

Decision order:
 (1) capability gate  tier enabled?
 (2) allow-list       target listed?
 (3) risk class       argument-aware
 (4) hard floor       never-silent -> APPROVE
 (5) autonomy ceiling risk <= ceiling -> run
Agent approval card: schedule_task (low) — an action awaits your approval — Approve / Reject
A real screen, not a mockup: even a "low"-risk task comes to you for approval — Approve / Reject. The policy engine decides; nothing runs until you approve. (Turkish-first product UI.)
Data handling

Where and how your data is protected

Hosting

Servers hosted in the EU (Germany). All traffic encrypted end-to-end via Cloudflare.

Secret vault

Your API keys and connector credentials are stored encrypted (Fernet). Secret values never reach the LLM and are masked in logs.

Access security

Two-factor authentication (2FA), role-based access control (RBAC), session security and failed-login protection are standard.

External-content quarantine

Untrusted/external content that reaches the agent passes a dual-LLM quarantine: the quarantine model extracts only goal-relevant facts and strips hidden instructions (prompt injection), so external content can't hijack the agent.

Continuity

The database runs in a high-availability cluster (automatic failover within seconds); the app is multi-node. Regular backups with restore drills; 24/7 health checks wired to alerts.

Accountability

Agent actions and crawl decisions are logged: which tool, why, with whose approval — fully traceable.

GDPR / KVKK

Personal data: consent, visibility, deletion

  • Consent-based memory: user memory, history summaries and personal briefing run only with explicit consent; the tenant admin and the user can each turn them off.
  • Visibility: the profile the agent learns, "What it follows" and "Learned Rules" are clearly listed in the panel — no black box.
  • Right to erasure: memory records are deleted with one click; on account closure data is permanently purged.
  • User-scoped separation: personal suggestions are shown only to the relevant user; team members don't see each other's personal context.
Sub-processors

Who we work with

We use a limited number of sub-processors to deliver the service. The main ones:

Sub-processorPurposeData
Contabo (Germany, EU)Server hostingAll application data (on encrypted disk)
CloudflareCDN, TLS, DDoS protectionTraffic (encrypted in transit)
AI providers (Anthropic, OpenAI, Google, Together — via our gateway)Model inferenceQuery context (no-training endpoints)
ResendTransactional emailEmail address, notification content
Soniox / ElevenLabsVoice AI (only on plans with voice enabled)Audio stream (per session)
Honesty note: Independent certifications (SOC 2 / ISO 27001) are on our roadmap — we do not hold them yet. This page only claims what is true today. For the current, full list: Privacy Policy.
Responsible disclosure

Think you found a security issue? Write to us directly — we respond within 48 hours.

[email protected]

Questions? Ask us directly.

If your security team has a checklist, we'll gladly answer it — including DPA and data-handling details.

Schedule a security call
We're happy to talk to your technical team