Generative AI is becoming a common feature of modern email platforms. AI assistants can draft and revise messages, summarize conversations, translate content, extract information, classify incoming mail, and help users manage increasingly complex communication. These capabilities can improve productivity, but they also introduce questions that conventional email architecture was not designed to answer. Who controls the AI service connected to an email account? Which provider is permitted to process communication data? What information may be submitted, and under what conditions? And as AI-generated messages become more convincing, how can recipients determine whether an email genuinely comes from the identity it claims to represent?
The last question is becoming especially important because generative AI is changing the nature of Business Email Compromise (BEC). Attackers can use AI to create polished, highly personalized messages that imitate the language, tone, business context, and communication habits of executives, suppliers, customers, or colleagues. A fraudulent message may therefore contain none of the obvious warning signs on which traditional security checks and human readers have relied. The challenge is no longer only whether an email looks suspicious. It is whether the identity behind the message can be trusted.
ZTmail doesn’t tie AI services to the App. Users can bring their own AI service API keys, so AI is no longer a built-in fixed dependency on the product, it is a configurable service. The user or organization can select an AI provider that fits its requirements instead of being forced to rely on one model, vendor, or processing environment. This distinction matters because expectations vary concerning model quality, language support, cost, privacy, geographic processing, regulatory obligations, and the retention of submitted data.
A user-owned key can support many practical email functions. An AI service may draft or revise a message, summarize a long conversation, translate content, extract structured information, classify incoming mail, or help identify the main decisions and follow-up actions in a discussion. The same email platform may support different providers for different tasks, allowing users to select a service according to the sensitivity and purpose of the information involved.
For organizations, the API key also creates a clearer control point. Administrators may determine which providers are approved, which users or departments can access them, what permissions are granted, and what information may be submitted. An organization might permit AI-assisted drafting for ordinary business correspondence while applying stricter rules to confidential documents, customer records, financial information, or intellectual property. The API key does not solve every data-governance problem, but it makes the relationship between the email platform and the AI service more explicit and manageable.
It also preserves an important separation of responsibilities. The AI API key authorizes access to an intelligence service; it does not make that service the owner of the mailbox, the email account, or the user’s cryptographic identity. AI can be granted permission to perform a defined task without becoming an unrestricted and permanent custodian of readable communication.
Choosing AI services on your own does not establish trust in the messages that users send or receive. AI can help create a message that is clear, fluent, and contextually appropriate, but it cannot independently prove that the sender is who they claim to be. The quality of generated language is not evidence of identity. A message can be perfectly written and still be fraudulent.
AI-based detection can help estimate whether a message appears abnormal, but probability is not the same as proof. A legitimate message can be unusual, while a carefully prepared fraudulent message may appear entirely normal. As attackers and defenders both adopt AI, relying only on better content inspection risks creating an endless contest between more convincing deception and more sophisticated pattern recognition.
The underlying question is therefore different: can the recipient verify the identity behind the message? This is where digital signatures and cryptographic identity become important. In an S/MIME message, a digital signature is created using the sender’s private key associated with a certificate. When the certificate chain is valid and trusted, the recipient can verify the relationship between the message and the claimed identity and can detect whether the signed content has been altered after signing.
A digital signature does not make a sender trustworthy by itself, and it does not eliminate every possible form of fraud. It does provide evidence that cannot be established through a familiar display name, writing style, logo, or visual similarity alone. That evidence is particularly valuable when AI-generated messages make appearance-based judgments less reliable.
The user interface must make this evidence understandable. If certificate information remains hidden in technical menus, recipients may continue to rely on names, addresses, and writing style. ZTmail App can instead display validated identity information, signature status, identity-validation level, and relevant organization details at the point where a user decides whether to trust a message or act on its request.
For enterprises, the same information can support automated policy: ZTmail S/MIME Automation Gateway use S/MIME certificate validity, signature status, organizational identity, or trust-domain information as additional signals for routing, release, quarantine, or approval decisions. Cryptographic identity therefore complements existing content- and behavior-based controls; it does not need to replace them.
The AI API key and the cryptographic key solve different problems. The AI API key determines which intelligence service a user or organization chooses and how that service is authorized within the email workflow. The cryptographic key supports digital signatures, encryption, identity verification, and access to protected communication. One controls access to intelligence; the other supports trust and protection.
The two-key model is most useful when the functions are connected but not confusing. During composition, an authorized AI service may help draft, revise, summarize, translate, or classify a message. The user can review the result and decide whether it should be sent. After approval, cryptographic mechanisms can apply the final digital signature and encryption controls. The message then enters a protected lifecycle in which its identity can be validated, and its content can remain confidential during transmission, storage, and later access.
This separation also preserves the proper role of AI. An AI assistant should help people work with information, but it should not become the authority for deciding whether a sender is trusted. Trust decisions require evidence that remain independent of how persuasive generated text may appear. Cryptography supplies that independent trust foundation, while the AI service remains a controlled productivity tool.
The value of the two-key model is therefore greater than the value of either key considered separately. AI without cryptographic trust can make email faster and more convenient while leaving identity questions unresolved. Cryptography without intelligent assistance can provide strong protection but can't improve email processing efficiency. Together, the two technologies can make email more efficient, more trustworthy.
The two-key architecture will only become practical if it is supported by automation. S/MIME has long provided mature mechanisms for signing and encryption, but certificate issuance, renewal, key handling, recipient configuration, recovery, and policy management can be difficult for ordinary users and large organizations alike. Automation should remove this operational burden without removing user or organizational control.
The same principle applies to AI integration. An email platform should make it straightforward to configure an approved AI provider, use the appropriate API key, define permissions, and apply the service to specific tasks. At the same time, it should make cryptographic status visible and make signing, encryption, identity verification, and key management dependable parts of the normal workflow. Security should not depend on users remembering a series of technical steps every time they send or receive a message.
Different environments may require different implementations. Individuals and smaller organizations may use an application that combines AI assistance with automated S/MIME protection. Larger enterprises may use gateway-based infrastructure that supports centralized administration, policy enforcement, integration with existing email systems, and organization-wide certificate and encryption management. The delivery model may vary, but the principle remains the same: intelligence should operate within a trusted communication framework.
The future of intelligent email will not be defined by AI alone. AI can improve how users create, understand, and manage communication, but it cannot independently establish the identity behind a message. As generative AI makes BEC attacks more convincing, content and behavior analysis may become less reliable when used without an independent source of identity assurance.
A user-owned AI API key addresses the question of control over intelligence. A cryptographic key addresses the questions of identity, integrity, confidentiality, and protected access. The two keys are not interchangeable, but they are complementary. The first enables AI to improve email productivity; the second provides the trust and protection that AI cannot create on its own.
When these capabilities work together, AI can become more than an isolated feature. It can operate within an email architecture where users choose their intelligence services, organizations control access, recipients can evaluate verifiable identity, and messages remain protected by encrypted after they are sent. That is the basis for a more capable and more secure system of intelligent email.
Click here to read PDF edition (digital signature and timestamp with global trust and global legal effect, all rights reserved, plagiarism is prohibited! Please indicate when reprinting: Reprinted from ZoTrus CEO Blog)