AI Ethics & Guardrails

• Scoped by default. An agent can only see, say, and do what its definition explicitly grants. Capability is configured, not inferred.
• Auditable end to end. Every wake (one bounded execution) emits a strict event sequence, and the rendered system prompt is hashed and recorded. We can answer "why did the agent do that" with a transcript, not a guess.
• Human in command. Material actions are approval-gated. Customers can take over a conversation at any time; staff can override an agent at any time.
• No training on your data. Customer business data never trains a Voltade model, and we contract with our model providers to ensure they don't either.
• Honest about limits. AI agents are useful, not infallible. We don't ship anything we wouldn't run on our own business.

The Services use the following large language models. The list is current as of the page's "Last updated" date.

• Anthropic Claude — primary reasoning and generation model for AI Assessment, Help Centre chat, Volty, and Custom AI Agents. Anthropic's commercial API is configured with zero-retention defaults; submitted data is not used to train Anthropic models.
• OpenAI — reasoning, vision (Volty drive extraction), and embedding generation (text-embedding-3-small for Help Centre semantic search). OpenAI API content is not used to train OpenAI models.
• Google (Gemini) — reasoning and grounded web-search results in Volty. Google paid-API content is not used to train Google models under Google's paid-API terms.
• DeepSeek, Moonshot (Kimi), Xiaomi (MiMo), Z.AI, and models routed via OpenRouter — reasoning models available to Volty for cost-tier selection.
• ElevenLabs — voice synthesis for voice-enabled Custom AI Agents. Not used by Volty.

In Volty, all model calls route through a hosted model gateway we operate — a deployment of the open-source Bifrost project (github.com/maximhq/bifrost) configured with a per-organisation virtual key, model-selection ranking, cost metering, and failover to the next-ranked model on provider failure. Full jurisdictional detail on providers, including the PDPA §26 basis for cross-border model routing, is in the Privacy Policy §5.

We may add or replace model providers as the field evolves. Material changes are reflected in this page and, where they affect data handling, in the Privacy Policy.

We do use anonymised, aggregated diagnostics — for example "the average wake takes 4.2 turns, the 95th percentile is 11" — to improve reliability. These never include customer message content, contact details, or any reconstructible business information.

Custom AI Agents have three monotonic audience tiers: contact, staff, admin — least to most trusted. Every tool and command declares the minimum tier it requires. The visibility rule is enforced in two places: the agent's instruction file (so the agent doesn't even know about commands above its tier) and at runtime (so a tool call that slipped through the prompt would be rejected anyway).

Custom AI Agents run inside a bash sandbox over a virtual filesystem materialised at the start of each wake. The shell knows cat, ls, grep, echo >>, and a small set of Voltade-specific CLI verbs. There is no SQL access, no arbitrary HTTP, no internal IDs to memorise, no opaque APIs.

Each path the agent reads or writes is a service call in disguise — a typed projection of a permitted operation. Reads are scope-checked by organisation; writes are audit-logged; cross-tenant access is impossible by construction, not by convention.

Volty replaces the bash-over-VFS surface with the typed operation registry described in §3.3. Each wake is bounded, durable, and serialised per conversation via a lease; wakes are resumable from journalled save-points if a process restarts mid-execution. The same principle holds: nothing runs that the registry does not declare.

The system prompt is computed once at the start of a wake and held byte-identical across every turn. A SHA-256 hash of the rendered prompt is recorded on the wake's start event. Mid-wake file writes persist, but they only appear in the next turn's tool results — never in the system prompt. The invariant holds identically for Custom AI Agents and for Volty wakes.

This matters for three reasons:

• Determinism — same trigger → same prompt bytes → same hash. Retries don't quietly produce a different agent.
• Reproducibility — disputed actions can be reproduced under the exact prompt that produced them.
• Cache safety — provider prefix caches stay valid, so cost and latency don't balloon mid-session.

Every wake emits a strict event sequence: agent_start → turn_start → llm_call → message_* → tool_execution_* → turn_end → agent_end. Observers attach at well-defined points; nothing important happens between events.

We maintain operational logs sufficient to reconstruct what an agent did. For any action an agent took, we can answer:

• What triggered it — customer message, scheduled heartbeat, staff @-mention, or operator command.
• Why it was allowed — which audience tier was in effect, which tools were visible.
• How the decision formed — the system prompt (recorded by SHA-256 hash and reproducible from the trigger), the tool calls considered, and the data sources read.

This applies equally to actions that succeeded and to actions that were blocked. Customers on enterprise plans can request the audit trail for any specific interaction.

Agents do not act unilaterally on material decisions. Specific guarantees:

• Approval gates — tools that send rich cards, book calendar slots, or draft outbound emails can be configured to queue for staff review before dispatch.
• Escalation — when a customer asks for a human, when the agent encounters a request outside its skill set, or when policy thresholds are crossed (e.g. refunds above an agreed limit), the agent reassigns the conversation to a named staff member and pauses.
• Override — staff can take over any conversation at any time. The next inbound message routes to the human inbox, not the agent.
• Kill switch — administrators can pause an agent definition organisation-wide; in-flight wakes complete their current turn and exit cleanly.

Agents have durable memory scopes, each backed by a typed column and budget-capped:

• Agent memory — self-knowledge ("always confirm refund window before quoting an amount").
• Contact memory — per-customer facts ("prefers SMS over email").
• Staff memory — per-(agent, staff) context ("@billing-lead handles refund overrides above $100").
• Volty adds a fourth scope — the org drive. A shared, organisation-scoped knowledge base of staff-authored documents (policies, FAQs, processes), agent-drafted proposals awaiting staff approval, and agent-imported drafts from your website (via an operator-triggered website-import operation).

Memory writes go through a change-proposals pipeline: low-confidence or sensitive learnings are routed to pending and reviewed by a human before being committed. In Volty specifically, free-text memory patches are propose-only indefinitely; auto-apply is reserved for a closed allowlist of low-risk structured fields; and distill-origin learnings (from post-hoc reflection) are never auto-applied. Customers can inspect, edit, and delete contact memory and drive entries at any time from within the product.

We send the minimum context required for the agent to act on a task. Connected systems are read on demand, not wholesale-mirrored to the model. We do not send raw payment card numbers, government identification numbers, or fields you've explicitly marked as redacted.

Inbound customer messages are treated as untrusted input, not instructions. The agent's instruction file makes this explicit. Capability scoping (section 3) is the structural defence: even a successful prompt-injection cannot give the agent a tool it didn't already have.

Specific protections:

• Customer-driven wakes always run at the contact tier — the lowest privilege.
• System prompts are frozen for the duration of a wake; injected text in a later turn cannot rewrite the agent's role.
• High-impact tools require either a higher tier or an approval gate.
• Public website forms (AI Assessment, contact, demo) are protected by Cloudflare Turnstile and a Singapore/Malaysia geo allow-list to suppress automated abuse.

• No autonomous payments. Agents draft transactions; humans approve them.
• No identity claims. Agents do not claim to be human and do not impersonate named staff.
• No regulated decisions. Agents do not make standalone credit, insurance, medical, or legal decisions. They draft, summarise, and route — they don't decide.
• No covert manipulation. We will not build agents whose purpose is to mislead consumers, suppress disclosures, or evade legitimate regulator oversight.
• No mass disinformation. We will not build or operate agents whose primary purpose is generating political disinformation or coordinated inauthentic behaviour.
• No surveillance of staff. Voltade agents are not configured to monitor employees or track keystrokes.

Operating an agent comes with obligations the platform cannot enforce for you. As the operator, you agree to:

• Treat AI output as drafted, not decided. Keep a qualified human reviewer in the loop for any material business decision.
• Configure approval gates and escalation thresholds appropriate to your business — we provide defaults, but only you know your policies.
• Disclose AI involvement to your customers where law requires it (for example, automated decision-making notices under the PDPA).
• Maintain your own audit records as required by your regulator.
• Only feed agents data you have a lawful basis to process.

If you believe a Voltade agent has caused harm, made an error you can't reproduce, or behaved outside the limits described on this page, contact us at [email protected]. For active production incidents, call +65 8892 1055 — we triage 24/7. Security-specific reports can also use the contact channel published in the Trust Centre.