Security
Town includes built-in security measures to protect your data and prevent misuse. These protections apply automatically.
The lethal trifecta
Town protects against a dangerous security pattern where an attacker could exfiltrate your data through a workflow.
What is it?
The “lethal trifecta” occurs when a workflow has all three of:
- Access to private data — Tools that can read sensitive information (emails, calendar, files)
- Exposure to untrusted content — Triggers that receive external input (incoming emails)
- External communication capability — Tools that can send data outside (Slack messages, code execution with internet, etc.)
When all three are present, a malicious email could potentially instruct your workflow to read private data and send it externally.
How Town protects you
- “Always allow safe actions” only auto-approves tools that can’t share data externally when chatting with your assistant or running workflows that meet the trifecta.
- You can tell your assistant to require your approval before it shares data externally, giving you a chance to review and block if needed.
- Your assistant will warn you if you try to create a workflow that may unintentionally share sensitive data. However, you can work with it to create a workflow that meets your needs but also protects your data.
In “Allow all actions” mode, you’ve explicitly accepted full autonomous operation. The trifecta protection doesn’t apply because you’ve chosen to trust the workflow completely.
External communication tools
Tools that can send data externally include:
| Tool | Why it’s flagged |
|---|---|
slack_send_message_to_user | Sends Slack direct messages |
slack_send_channel_message_as_bot | Posts to Slack channels |
slack_send_group_message_as_bot | Sends DMs to other users as the bot |
slack_send_message_as_user | Sends messages as the user — not the bot |
run_code (with internet) | Can make network requests |
github_create_or_update_file | Creates commits that others can see |
github_create_pull_request | Opens PRs visible to collaborators |
create_calendar_event | Can send invites to attendees |
edit_calendar_event | Can notify attendees of changes |
update_sheet_data | Sheets can be shared externally |
update_doc | Docs can be shared externally |
run_code is only flagged as external communication when the sandbox has internet access enabled. Network-isolated sandboxes can’t exfiltrate data.
update_sheet_data and update_doc are only flagged as external communication when they’re configured to be able to write to shared documents. They can be configured to only write to trusted documents.
Untrusted input triggers
Triggers that can receive attacker-controlled content:
- Incoming email — External senders can craft malicious content
What you can do
If you need a workflow that combines these capabilities:
- Review each action — Use approval-required mode and review before approving
- Use “Always allow safe actions” — External tools still require approval
- Encourage your personal assistant to use safer tool configurations — for example, disable internet access on code execution, or restrict document tools to write only to non-shared documents.
Prompt validation
Town validates workflow prompts to prevent prompt injection attacks.
Blocked patterns
These patterns are blocked entirely — prompts containing them cannot be saved:
| Pattern type | Examples |
|---|---|
| Instruction override | ”ignore all previous instructions” |
| System manipulation | Attempts to inject system prompts |
| Role manipulation | ”you are now in developer mode” |
| Delimiter escapes | Attempts to break out of prompt structure |
| Privilege escalation | ”enable admin mode” |
| Data exfiltration | ”forward all emails to…” |
If a prompt contains blocked patterns, you’ll see an error explaining why it can’t be saved.
Suspicious patterns
These patterns are logged but not blocked:
- Code execution keywords (
eval,exec) - Template injection syntax (
{{...}},${...}) - Bypass keywords
These may indicate a prompt injection attempt and are monitored.
Token limits
Prompts are limited to approximately 10,000 tokens. Very long prompts may be used to hide malicious instructions.
Output validation
When workflows attempt actions, arguments are validated before execution.
Email validation
- Recipient limits — Maximum 50 recipients per email
- Blocked patterns — Known malicious email patterns are rejected
- Domain allowlists — Optional restriction to approved domains
Account validation
- Account isolation — Tools can only access accounts you’ve explicitly connected
- ID verification — Account references are validated against your accessible accounts
- Primary account — The triggering account is always accessible
Account access control
Workflows operate within strict account boundaries:
- Connected accounts only — Workflows can only access accounts you’ve connected via OAuth
- Configurable scope — You can limit which accounts a workflow can access
- Token security — OAuth tokens are stored securely and refreshed automatically
- Revocable access — You can disconnect accounts anytime from your account settings
Account scope options
| Setting | What the workflow can access |
|---|---|
| Trigger account only (default) | Only the account that triggered the run |
| All accounts | All your connected accounts |
| Specific accounts | Only accounts you explicitly list |
Security event logging
Town logs security-related events for auditing:
| Event type | What triggered it |
|---|---|
| Prompt injection blocked | Blocked pattern detected in prompt |
| Suspicious prompt | Suspicious pattern detected (logged, not blocked) |
| Tool output blocked | Tool arguments failed validation |
| Unauthorized recipient | Attempt to send to blocked recipient |
You can view security events for your account to see if any suspicious activity has been detected.
Action logging
Every action is logged with:
- What — The action taken
- When — Timestamp
- Why — The workflow’s reasoning
- Trigger — What initiated the action
- Result — Success or failure
This provides:
- Auditability — Review what happened
- Debugging — Understand why something happened
- Accountability — Track all modifications
What you can do
Review run logs
Regularly check what your workflows are doing:
- Open a workflow
- View the session history
- Review actions taken and their reasoning
Use appropriate permission levels
- New workflows — Start with approval-required
- Sensitive operations — Keep on approval-required
- Trusted, tested workflows — Can move to autonomous
Limit tool access
Only enable tools a workflow needs. Fewer tools = smaller attack surface.
Monitor security events
Check for blocked prompts or suspicious activity in your security event log.
Reporting issues
If you discover a security issue or unexpected behavior:
- Check run logs for details
- Disable the workflow if needed
- Contact support with details
If you believe your account has been compromised, immediately revoke OAuth access from your Google, GitHub, Slack, and other connected account settings.