When you send a question to an AI agent, “encrypted” does not yet explain who can read it. Follow the data through the phone, relay, agent computer, model and tools. That journey helps you choose a setup matching your confidentiality needs.
Where the conversation ends
Pacerelle uses the Signal protocol for encrypted exchanges between devices and agents. A message is decrypted on the agent machine because the program must read it to respond. The relay can route the content without receiving its plaintext.
TLS transport encryption remains useful but protects a different boundary: the network connection. End-to-end encryption keeps content unreadable to the intermediary itself. Recipient devices and the agent program still see the message.
What remains visible to the relay
The Pacerelle security documentation separates encrypted content from service metadata. The relay knows account information, conversation membership, message times and sizes, and agent connection state.
Saying it “sees nothing” would therefore be inaccurate. Consider what agent names and descriptions reveal as well. Authorized group members receive the content, and encryption cannot prevent a recipient from copying what they read.
Verify the program's identity
A verification code compares the identity published by the program with the identity shown in the application. For a configured Python client, publish prekeys and display the code on the agent machine:
client.publish_prekey_bundle()
print(client.get_verification_code())This fragment requires an existing configured client; see the quickstart. Open agent verification in Pacerelle and compare the full code with the terminal through a trusted channel.
A code sent only through the conversation is not an independent comparison. Matching codes establish consistency of the compared identities, not that the program is bug-free or the computer uncompromised. Investigate unexpected changes before continuing.
Understand Double Ratchet boundaries
Signal's Double Ratchet evolves message keys. Protection of earlier messages and recovery after compromise depend on conditions including deleting old keys and incorporating fresh secret exchanges. It does not promise universal deletion of every stored message copy.
Files, groups and retained history also involve their own key mechanisms. Pacerelle encrypts attachments separately, and retained history uses archive keys. Examine retention and backups rather than inferring their protection from the Double Ratchet name alone.
Follow data after decryption
If the agent calls a hosted model, the provider receives whatever your code forwards. Even with local inference, logs, screenshots, temporary files and backups may retain content. The Python SDK store includes private keys and pending plaintext and does not itself encrypt the file at rest.
Protect the state directory with operating-system permissions, limit copies and use one process per store. Different SDKs and the MCP server have different storage mechanisms; consult the production guide rather than assuming they are interchangeable.
Four useful checks
- The agent identity matches the program you intend to contact.
- Conversation recipients are appropriate for the shared information.
- Models and tools forward data only to intended services.
- Local state, history and backups have explicit retention and access rules.
These checks preserve the real value of encryption without treating it as protection for the entire workstation or control over agent actions. For the latter, also use bounded permissions.
Verify your agent
Compare its identity and trace your data before sharing sensitive information.