API Key Security and Connection Safety

Your API keys and credentials are among the most sensitive assets in your automation stack. Chase Agents is designed with multiple layers of protection to ensure those credentials are never exposed, and that connections cannot be used to reach internal network infrastructure.

Encrypted Credential Storage

All API keys and tokens stored in Chase Agents are encrypted at rest in the credential vault. They are never displayed in plain text after you save them; you can see that a credential has been configured, but you cannot retrieve the raw value through the UI. This prevents credentials from being accidentally exposed in screenshots, screen recordings, or shared links.

Blacklisted Connection URLs

When you create a connection, Chase Agents validates the target URL against a list of disallowed destinations. The platform blocks connections to localhost, 127.0.0.1, and the IPv6 loopback address, private IP ranges including 192.168.x.x, 10.x.x.x, and 172.16.x.x through 172.31.x.x, link-local addresses in the 169.254.x.x range, mDNS domains ending in .local, generic internal network domains ending in .internal, and the file protocol. This prevents server-side request forgery (SSRF) attacks where an automation could be used to probe internal infrastructure.

Workspace API Keys

Chase Agents issues workspace API keys that external systems and MCP clients use to authenticate with your workspace. These keys grant access to your workspace's MCP tools and should be treated like passwords. Store them in a secrets manager rather than in source code, environment variables committed to version control, or plaintext configuration files.

If a workspace API key is compromised, rotate it immediately from the workspace settings panel. The old key is invalidated immediately and any systems using it will need to be updated with the new value. Rotation does not affect your automations or agent configurations; it only affects external clients that authenticate using the workspace key.

Template Variable Best Practices

Use template variables for any credential value that appears in automation step configurations. Never paste raw API keys directly into step code or parameter fields. Even though step definitions are not publicly accessible, using template variables provides two additional benefits: when you need to rotate a credential you only need to update it in one place (the vault) rather than finding and updating every automation that uses it; and your step definitions remain clean and auditable without embedded secrets.

Principle of Least Privilege for Connections

When creating API keys for your connections, request only the permissions the connection actually needs. If an automation only reads from a database, use a read-only database credential. If an automation only creates calendar events, use an OAuth scope limited to calendar write access. Over-permissioned credentials increase the blast radius if a key is ever compromised.

Sharing Connections Safely

Use connection access types deliberately. WorkspaceWide connections are convenient but mean all workspace members and automations can use those credentials. For sensitive connections such as production databases or payment processors, consider using Personal or SpecificTeamMembers access types to limit who can build automations with that connection. Workspace admins can audit which connections are configured and their access types from the workspace settings panel.

Reporting Security Issues

If you discover a security vulnerability in Chase Agents, please report it to charles@chaseagents.com. Do not disclose security vulnerabilities publicly until Chase Agents has had a reasonable opportunity to investigate and address the issue. For non-security questions about data handling or compliance, the same address is the appropriate contact.