Introduction
Sana Agents is fully committed to data security and privacy, and we proactively launch new capabilities to strengthen agent security as new and emerging attack patterns appear. This article outlines the evolving risks associated with AI agents, the recent security features we’ve introduced to mitigate them, best practices for users to reduce AI-related risks, and how workspace owners can configure guardrails in Sana to further strengthen their defenses by enabling these features.
It’s important to emphasize that these new features are not a response to any incident, nor do they indicate that the platform was previously insecure. They reflect our commitment to continuous improvement and proactive hardening of the product, further reducing potential risk as the external threat landscape evolves.
Risks associated with AI agents
Sana Agents can connect to external tools such as databases, CRMs, and ticketing systems. This is extremely powerful, but it also introduces security risks related to prompt injection and potential misuse of connected systems.
OWASP (the Open Worldwide Application Security Project) defines prompt injection as: “A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways. These inputs can affect the model even if they are imperceptible to humans, therefore prompt injections do not need to be human-visible/readable, as long as the content is parsed by the model.”
In practice, prompt injection and LLM hallucinations can introduce several related risks that end users should have a basic understanding of in order to help mitigate these risks:
Risk | Description | Example |
Data exfiltration | Agent is tricked into reading sensitive data and sending it to an attacker through an external system |
|
Misuse of integrations | Agent performs actions the user never explicitly requested |
|
Influencing decisions | Agent’s answer is biased/manipulated without obvious data leakage |
|
How Sana mitigates security risks
Similar to how an email system can never be 100% phishing‑proof, an AI system can never be completely insulated from threats. Instead, we assume that any content an agent reads could be malicious and design controls around that assumption, continuously introducing new features that strengthen our security through multiple layers of defense:
Model-level detection and behavior constraints
Platform-level permission boundaries and guardrails
Human approval for write/external actions (human-in-the-loop)
Read more about each of these layers and recent feature developed below.
Model and detection improvements
We continuously monitor and update the models available to the agent based on their ability to detect and counter prompt injection and related attacks. This includes updating model configurations and instructions as new attack patterns emerge.
We run comprehensive tests to monitor our ability to detect prompt injection attacks. These tests help us identify weaknesses and improve our defenses over time.
We inform the user if the Agent has encountered a prompt injection attack. This helps the user identify and avoid attack attempts.
Integration and permission controls
Admins can control what integrations are available to workspace users based on their risk profile. This allows organizations to limit access to only the systems that are necessary for a given team or use case, reducing the blast radius if an agent is ever misled.
Only admins can set up access to remote MCP servers. For each MCP server, admins can: control what type of tools are allowed (e.g. read-only vs read/write) and decide which users and/or user groups are allowed to connect to the MCP server.
Admins can control what email domains and calendar domains are allowed. Admins can restrict which email domains agents can send emails and calendar invites to. This prevents agents from contacting arbitrary external addresses, even if prompted maliciously. Requests to blocked domains are stopped at the platform level, and users see a clear message that the action is not allowed due to admin restrictions.
Human-in-the-loop
We provide a way to review the agent’s reasoning. Since Sana already surfaces intermediate reasoning and tool plans before actions are executed, users have a chance to spot and correct suspicious or unexpected behavior before it has an effect.
We require human-in-the-loop confirmation for all agent tools that perform write operations or interact with external parties. Before Sana executes actions such as sending an email, updating a CRM etc, the user can review what the agent intends to do and approve or deny it. This extra step significantly reduces the chance that a hidden prompt can cause unintended changes or leak data without a human noticing.
Best practices for users to avoid attacks:
Sana’s technical controls work best when combined with good operational practices. The recommendations below are aimed at admins and end users.
During human-in-the-loop review
When you see a human-in-the-loop artifact (for example, a draft email, a proposed CRM update, or a plan with upcoming tool calls), always:
Compare the original request with the agent’s output.
Check that what Sana is about to do or say directly answers your question or task, without introducing unrelated steps by clicking on the thinking model to see what the agent is doing.
Verify that the output aligns with the intent of the request.
If the agent proposes actions that are broader or riskier than you intended (for example, “also email this to your entire customer list”), stop and adjust.
Ensure no unexpected or additional actions are suggested.
Given the non-deterministic and sometimes hallucination-prone nature of AI, Sana can make mistakes. Watch for:
Extra recipients in emails
Additional records being modified or created
Unusual status changes or deletions
If something looks surprising or out of context, treat it as a potential issue, not as a helpful suggestion.
Application and integration hygiene
Only connect Sana to applications that you trust.
Every new integration increases the range of actions an agent can take. Make sure the connected systems are governed and monitored in line with your security policies.
Only enable email and calendar domains that you trust.
Make sure that you trust the domains you include in the “Email and calendar tool settings” to make sure that users can only send emails and calendar invites to users they trust. To begin with we recommend allowing your internal domain and gradually adding external domains such as trusted customers you regularly interact with.
Be extra careful when connecting to MCP servers.
MCP servers can expose highly flexible, custom tools. Before allowing access from Sana:
Review what data and actions the MCP tools provide.
Prefer read-only access when possible.
Restrict access to specific users or groups who truly need it.
Read more about security risks and best practices for MCPs in our dedicated help center article for it here.
How admins can set up guardrails in Sana:
Enable and disable integrations:
To reduce the risk of risks associated with integrations, workspace admins can define which user and/or group of users that should have access to an individual integration to make sure it is only available to trusted users. Admins can set this up by:
1. Go into the admin workspace settings
2. Enter the Integrations tab and locate the “Enable and disable integrations section”
3. Click on the integration you with to configure and a popup will appear.
4. Make it available to the entire workspace by clicking on the checkbox “Everyone at [Workspace Name] or enable it to only specific users and/or groups of users by searching and selecting them, see example below. Click Save when ready.
Enable and disable allowed email and calendar domains:
To reduce the risk of sending sensitive data from Sana to external systems, workspace admins can define a list of approved domains for email and calendar invites. Once configured, users can only send emails and invites through Sana’s integrations to those domains; attempts to use any other domain will fail. Admins can set this up by:
1. Go into the admin workspace settings
2. Enter the Integrations tab and locate the “Email and Calendar Tool Settings” section
3. Fill in the domains you trust and click “Save Configuration”
Frequently asked questions
Q: Why did we update this now, was our data not secure before?
A: Customer data has always remained protected and this update is part of our proactive security posture as we are strengthening agent security in response to new and emerging attack patterns.
Q: How can we ensure we're 100% protected from attacks?
A: No AI system can be 100% protected, just like no email system is 100% phishing-proof. What we can do is achieve high assurance through layered controls and iteratively launch new security features as the landscape evolves. Sana combines multiple layers of defense:
Model-level detection and behavior constraints
Platform-level permission boundaries
Admin guardrails (trusted domains, MCP server access, integration scoping)
Human approval for write/external action (human-in-the-loop)
Q: What are domains we should trust and what what are other organizations normally doing?
A: We recommend starting with client's internal domain only, then gradually adding a list of trusted partners that you regularly interact with, e.g. customers.
Q: What happens when the agent tries to interact with a blocked domain?
A: When the agent attempts an action involving a blocked domain, the request is stopped at the platform level. The agent's reasoning will show the domain is not allowed, and the user will receive a clear message that the action cannot be performed due to admin restrictions.
Data handling & privacy
Sana Agents is fully committed to data security and privacy. All data accessed by Sana Agents is encrypted both in transit and at rest. Sana does not train any underlying language models on your data, ensuring the privacy of your information. Sana Agents is ISO 27001 certified; and SOC 2 and GDPR compliant, and adheres to the highest standards of data security. More information available in our Data Processing Addendum, Privacy Notice and Agents Security Whitepaper.