Leave one workflow and your number. The AI identifies itself, asks a few focused questions and prepares a structured brief.
A voice agent adds new attack surfaces in the prompt, the output, the caller's identity and the actions it can take.
Each line below names what is actually checked, not what sounds reassuring in a brochure.
Data processing, consent, retention and access requirements are scoped for review in each deployment rather than treated as one blanket promise. Tenant isolation is enforced throughout: one customer's conversations never reach another customer's agent.
Every call reaches the agent through DRING Security first. Integrations start read-only, and a tool gains write access only with explicit sign-off.
Related: Quality and testing · Agent Factory · Line protection
A voice agent takes instructions from the person on the call by design. An attacker tries to turn that against it.
A direct override: "ignore your instructions," mid-call.
Instructions hidden inside tool or web data: a CRM note, an order record or a webpage carrying text written for the agent, not the person reading it.
Staff impersonation: a caller claims to be an employee or the account holder to unlock actions meant only for a verified identity.
Refund or transaction pressure: a request outside policy, repeated or escalated, hoping persistence works where a direct ask would not.
Refuses out-of-scope instructions. Nothing said on the call changes its operating instructions.
Treats tool output as data, not commands. Instruction-like content coming back from a tool is ignored, not executed.
Verifies identity before privileged actions. An unverified claim is refused and logged for review.
Requires authorization for high-risk transactions. No refund, transfer or discount clears on request alone.
Offers a human handover instead of improvising an exception.
| Attack | What the caller tries | What stops it |
|---|---|---|
| Override | Ignore your instructions, follow new rules | Instructions stay fixed all call, logged |
| Injected tool result | Hides commands inside a CRM note | Tool output is read, never executed |
| Spoofed identity | Claims staff, supervisor or account holder | Checked against verification, not the claim |
| Out-of-policy transaction | Pushes refund, transfer or discount repeatedly | Needs explicit authorization, no exceptions |
| Data request | Asks to hear another customer's data | Not reachable; tenant isolation blocks it |
| Policy trap | Leads toward an improvised promise | Every reply checked against policy first |
Every attempt is logged and reviewed.
Overrides, injected content and traps, from a living library.
Automated checks plus human review flag any disagreement.
Replies and high-risk actions are checked before release.
Results sit beside quality metrics; nothing ships untested.
Defense in layers, not in the model. The protection does not rest on one model behaving well. It sits in several layers around the model, the attack scenarios are rerun regularly against different models, and every conversation passes an automatic security analysis afterward.
One regression suite. Every rule a customer gives us joins that agent's single regression suite. A new rule ships only when every existing rule still passes beside it, so a fix in one place cannot quietly break another.
The same detect, stop and log logic guards the line itself. Repeated SIP attempts, spoofed caller IDs and robocall bursts stop at the carrier edge; verified callers pass.
For the full telephony architecture, replicated SIP edge, media cluster, active and standby paths, see SIP trunks & carrier peering and line protection.
Data moves through a fixed, monitored path on every call, encrypted at every step.
Data is encrypted in transit with TLS 1.2 or higher and encrypted at rest. Tenant isolation, role-based access and automated monitoring apply across the pipeline.
Where KVKK, GDPR or local data rules require it, the language model (LLM), speech recognition (STT) and speech synthesis (TTS) run on local, on-premise models, served by the model providers, by our local partners or from DRING's own servers. Telephony is served from local servers in the country of service, in line with that country's regulations.
Message content, call recordings, post-call analytics, account data and website analytics each carry a default retention period, followed by deletion or anonymization. The periods and the rules that override them by contract are set out in the privacy policy, which is the single source for them. Clients may request earlier deletion of any data type at any time.
DRING acts as a Meta WhatsApp Tech Provider and as a data processor on behalf of clients, who remain the data controllers. WhatsApp data is never used for advertising. For request paths, applicable rights and deployment-specific notices, write to info@dring.ai and review the privacy policy and the KVKK notice.
With the data controls agreed for your operation, reviewed transcripts and outcome signals can improve that tenant's own agent, tests and release plan. Tenant isolation is enforced; customer conversations are not used to improve another customer's agent.
No. Integrations start read-only, and any write action requires explicit sign-off per tool.
Processing and transfer arrangements are documented per deployment, with applicable safeguards reviewed as part of the security and privacy process. Where KVKK, GDPR or local rules require it, LLM, STT and TTS run on local, on-premise models and telephony on local servers in the country of service.
Yes, clients may request earlier deletion of any data type at any time.
No. The agent's instructions and policy are fixed for the call and cannot be changed by anything a caller says. Every release is tested against instruction override, injected content and other prompt injection scenarios before it ships. See prompt defense for detail.
Walk through the data and governance requirements for your workflow. Send the form and DRING calls you in two minutes, says it is an AI and asks about your workflow.