Security

superagnt connects to your messaging channels, tools, credentials, and workflows so an AI operator can act on your behalf. We treat security as a core product requirement and design controls around protecting accounts, workspaces, connected accounts, credentials, Customer Data, and the operator itself.

This page summarizes our current security practices. It is not a guarantee that any system is immune from risk, and it may change as our infrastructure and product mature.

Security is shared between superagnt and each customer. superagnt is responsible for securing the platform we operate. Customers are responsible for how they configure workspaces, users, connected channels, connected accounts, operator permissions, and instructions.

• »Use least-privilege access for teammates, connected accounts, OAuth scopes, and channel permissions.
• »Rotate tokens and revoke connections promptly when team members leave, workflows change, or compromise is suspected.
• »Review the operator's permissions, tool access, and instructions before letting it act in production.
• »Do not send highly sensitive or regulated data unless your agreement and configuration explicitly support that use case.

Web app access is authenticated through our identity provider and scoped to workspaces and organizations. Connections to messaging channels and tools use scoped credentials issued through each provider's authorization flow.

• »Workspace membership controls user access to resources in the web app.
• »Connected accounts are scoped by workspace context and can be revoked or reconnected.
• »Server-side routes validate session tokens, workspace membership, and request context before performing privileged actions.
• »Administrative access is limited to authorized operators and protected by separate credentials and operational controls.

superagnt may store OAuth tokens, channel credentials, webhook secrets, and other credentials you provide or authorize so the service can operate. We design credential handling to minimize exposure and use credentials only for the purpose you configure.

• »Secrets are stored using managed infrastructure and are not meant to be exposed in client-side code or public responses.
• »Sensitive credentials are passed to upstream services only when required to complete the requested action.
• »We recommend using dedicated service accounts and least-privilege scopes for connected services.
• »Customers should revoke connected accounts and rotate external credentials when access is no longer needed.

We use technical and organizational safeguards designed to protect Customer Data during transmission, processing, and storage. Data is transmitted over encrypted HTTPS connections. Data at rest is protected by the security controls of our managed infrastructure providers.

Access to production systems and Customer Data is limited to authorized personnel and service providers with a business need. We use logs, monitoring, and operational procedures to detect and investigate suspicious activity.

The superagnt operator can read context and call tools, channels, and connected services according to its configuration. Because it may act autonomously, customers should treat operator configuration as production and review its permissions before granting access.

• »Grant the operator only the connected accounts and scopes it actually needs.
• »Require approval for high-impact, destructive, or externally visible actions.
• »Inspect and test workflows before enabling high-volume automation.
• »Monitor actions, credits, and logs for unexpected behavior.

We rely on managed cloud, database, payment, identity, and infrastructure providers with mature security programs. We apply application-level controls for authentication, authorization, input validation, rate limiting, logging, and error handling where appropriate.

• »Production configuration is separated from local development and staging environments.
• »Privileged routes use explicit authentication contracts and are separated by audience and purpose.
• »Billing, secrets, and privileged mutations are handled server-side rather than through unauthenticated client access.
• »We avoid exposing internal provider identifiers, secrets, raw credentials, or service-role access in customer-visible surfaces.

We monitor service health, operational metrics, logs, and security-relevant events to detect reliability issues, abuse, and suspicious activity. When we identify a security incident, we investigate, contain, remediate, and notify affected customers as required by law and contract.

Customers should promptly notify us if they suspect unauthorized access to a superagnt account, workspace, connected account, channel, or Customer Data.

We welcome responsible reports of potential vulnerabilities. Please include a clear description, affected URLs or endpoints, reproduction steps, impact, and any relevant screenshots or logs. Do not access, modify, delete, exfiltrate, or disrupt data that is not yours.

Do not perform denial-of-service testing, social engineering, spam, physical attacks, destructive testing, or testing against third-party systems without authorization. We will review reports and prioritize fixes based on risk.

Before using superagnt in production, we recommend reviewing these baseline controls for your organization.

• »Use unique accounts for each teammate and remove members who no longer need access.
• »Connect messaging channels and tools with least-privilege scopes, and disconnect ones you no longer use.
• »Require approval for the operator's high-impact and externally visible actions.
• »Set conservative scopes on third-party connected accounts and service accounts.
• »Review the operator's permissions and instructions before enabling automation.
• »Monitor usage and billing for unexpected spikes or unfamiliar activity.

Security documentation, data processing terms, vendor questionnaires, or enterprise security reviews may be available for customers evaluating paid or higher-risk deployments. Contact us with your requirements and intended use case.

We may update this Security page as our controls, providers, architecture, and product capabilities change. Material updates will be reflected by the last updated date above.